How'd you like to listen to dot net Rocks with no ads? Easy?
Become a patron For just five dollars a month you get access to a private
RSS feed where all the shows have no ads. Twenty dollars a month will
get you that and a special dot net Rocks patron mug. Sign up now
at Patreon dot dot net rocks dot com. Hey Carlin Richard here. As
you may have heard, NDC is back offering their incredible in person conferences around
the world, and we'd like to tell you about them. NDC Copenhagen is
happening August twenty seventh through the thirty first. Go to NDC Copenhagen dot com
for more information. NDC Porto is happening October sixteenth through the twentieth. Go
to Dcporto dot com to register and check out the full lineup of conferences at
NDC Conferences dot com. Hey there, this is Jeff Fritz, the purple
blazer guy from Microsoft, letting you in on a little secret about my friend
Carl Franklin. You know, the guy who started dot net Rocks, the
first podcast about dot net in two thousand and two. The guy who's been
teaching Blazer on YouTube since twenty twenty. Yeah that Carl Franklin. Well,
Carl's joined up with the folks from Code in a Castle to teach a week
long hands on Blazer class at Are you ready to get this? At a
castle slash villa in Tuscany. It's sort of a luxury vacation with Blazer learning
built in. Carl's calling it the Blazer master Class. You'll learn Blazer from
the ground up, finishing the week with the ability to build and deploy Blazer
applications. Since the training happens for only four hours in the morning over six
days, you can bring your significant other, your partner with you and you
should right This part of Italy is absolutely beautiful. There's so much to see
and do and in Larry and Marco from Code into Castle are organizing daily activities
both at the castle and in the area. The castle is in the Marema,
a less touristed region of Tuscany, offering both classic Tuscan hill country as
well as easy access to the Etruscan Riviera, with sublime local food, wine
and olive oil around every corner. Breakfast is included every day. There will
be two communal dinners at the Castle book ending the experience and most other meals
and all activities are included. And did I mention you'll learn Blazer in person
from Carl Franklin. Listen, space is limited and for very good reason.
This is quality training in a beautiful setting. Go to code in Acastle dot
com slash Blazer twenty twenty three. That's bla z o R two zero two
three to take advantage of this amazing opportunity to join Carl in Tuscany for an
unforgettable week of led dulce vita while advancing your programming skills in this important new
technology. Hey guess what it's doing at Rocks. I'm Carl Franklin and I'mmateur
Campbell, And you're here again. Isn't that cool? They're here again?
They show up. This keeps happening. I don't know, I don't know
why. I'm beginning to get an idea why. Yeah, maybe how you
been, mister Campbell? How's how's moving going? I'm packing mostly right,
And the problem, of course, is that we're not moving into a new
place. We're moving into a place that we've already furnished. So we have
entirely too much of everything. Not the least of which is a downsize.
So twenty something years have been in this house. It's a lot of purging.
Yard sale. Um no, not a yard sale kind of guy.
You know. That's the thing. I admit. I will Facebook Marketplace like
good bits of electronics and things that we but it's only good for free.
Yeah, if you as soon as there's a price forget it, you're wasting
your time. Yeah. But if you want to get rid of something on
a weekend quickly, you can stick it in the driveway and throw it on
Facebook Marketplace. It will be gone in an hour. And if you say
you want ten bucks for it, somebody's going to offer you too. Well,
they won't even do that. All they'll do is waste time after that.
If you give it away, it's gone and that's fine unless there's something
nice, in which case they go, oh it's a scam. So is
there any if there are any dot net rocks listeners in your area, can
they contact you and see what you got? Do you have a list somewhere?
I don't really have a list. Which kind of stuff comes along and
it goes out the door pretty quickly, but yeah, okay, yeah,
it's not that organized. Too much stuff, man, too much stop and
but a lot of what's happening right now is and you know, my wife
will enough to know that she purchased a particular size of plastic bin with locking
lids and stacking mounts. Oh yeah. And so we are our packaging up
the things that need to stay into these bins. We have measured off the
space in the garage up on the coast, and so we know how many
bins were allowed to have and we're sort of making it fit to the space.
And so I keep doing runs in the truck up there and continuing to
pile up a monolith, you know, something out of pink floids the wall,
and eventually will be done. Wait a minute, that's part of what
we're talking about monoliths today, right with Leila? You like that? All
right? Well, before we get Leila on, let's uh do better,
no framework, because I got something really kind of interesting to share, all
right. So this is a story reported by the verge right. Millions in
quotes of sensitive US military emails were reportedly sent to the country of Mali to
a typo right for over ten years, millions of I won't read the whole
thing but here's the gist. For over ten years, millions of emails associated
with the US military having getting sent to Molly, a West African country allied
with Russia, due to a typo. According to a report from The Financial
Times, instead of appending the military's dot mil domain to their recipient's email address,
people frequently type dot mL, the country identifier for Mali. I mean,
presumably all these emails bounce. Well, here's the story. So this
guy, a Dutch entrepreneur, Johannes Zubier probably something like that, contracted to
manage Molly's domain, tells the Financial Times. This has been happening for over
a decade, despite his repeated attempts to warn the US government, and when
he began noticing requests for non existent domains like Army dot mL and Navy dot
mL, he set up a system to catch the misdirected emails, which was
quote rapidly overwhelmed and stopped collecting messages. He reportedly intercepted a hundred and seventeen
thousand misdirected emails, some of which contained sensitive information. Oh my goodness,
yep, that's a good one. Attention to detail, kids, it's really
important. Well, and any I mean again, I guess they mostly bounced.
Yeah, but the real the real point, I think he's at the
end of this story where it's like that now the Defense Department has set it
up so that when any dot mL domain email address tries to said to dot
mL, they get a message that says, you need to verify this.
Right. Yeah, I just don't understand why somebody would send army to Army
dot m IL and then get a bounce notice and then keep sending it.
Well, who knows what they did? Well, who knows they did.
There's a lot of people working in the military. Yeah, you're right,
right, and and I me I mentioned some of those emails are, hey,
want to meet for lunch? Right? Could be yeah, I'm just
guessing, yeah, but there was some sensitive stuff. Anyway, It's very
important to pay attention to details, sanitize your inputs. That's the moral of
the story. Pretty funny, all right, So who's talking to us today?
Richard Grabby comment to show seventeen seventy, which is back in December twenty
one, when we talk to our friend Paul you can do it's about building
microservices with Dapper Ye and Sean Kieran wrote this great comment and literally DAPR dapper,
dapr. Yes, because too many product names. Life's hard. Yeah.
Yeah, so it's about eighteen months ago. Sean wrote this great comedy
says thanks for another great show. I don't know how you managed to keep
coming up with them awesome work. I enjoyed listening to Paul talk about Dapper.
It's a really interesting technology and it seems to have great hosting support too.
And Paul mentioned a Dapper makes service discovery easier, which is great to
hear. But the words service discovery in quotes also makes me shy away a
little, as it seems to be a bag full of unnecessary complexity that comes
along with the modern approach to microservices. And I'm with him, Like Jeffry
speaking, I think discovery seems vaguely silly. It's like I kind of know
where I want to call, Why do I need to discover it? Until
you're dealing with uncoupled failover solutions, right. The whole idea that rather than
saying, hey, when you need this service, call here, it's like,
when you need the service, ask for this most of the time would
be the thing we always thought it would be. But I could also have
a backup one there and I can upgrade, I could you know, change
things around without having to recompile other code. Right. This is all that
sort of uncoupling approach, which but I agree that service discovery could be easily
abused. They're used to. It reminds me of the old XML web services
days. Didn't wasn't there a discovery Yeah, but protocol I mean even going
back to ASMX right for crying out loud, like we've always had this idea
of we want to ask by name for something, not by location. I
just remember they did a demo where you could search like zip code services and
all the web code, all the web services that provide zip codes would come
up with endpoints, right. And that was the silly one. That the
one where it's like I just want to call out into the Internet for a
service to do something, and it's like, I'm pretty sure you should never
do that. Never ever do that. It's just not a good idea.
The Internet is not filled with your friends. That's that's what's out there.
That was just you know, to prove prove it could be done, I
suppose, yeah, and again didn't make it a good idea, But within
a service architecture, to be able to be to request a particular class of
service and not care that it's any given instance in any given location. It's
kind of like the Swagger idea, right, that's all insane uncoupling. Yeah,
yeah, now A Shan does gone to say he got involved with service
buses back in two thousand and eight, so he's obviously an old schooler when
he started with end Service Bush, which we know and love well. But
he also switched over to Rebus, which I don't think we've ever talked about,
developed by mog Heller Chrys No, we have none, I don't think
no. And but then also mentions things like mass Transit, easynet QE Brighter,
like there is a bunch of solutions there. There's no two ways about
it. It makes this key point he says, when you build with these
systems, you're making true He calls them true Microsoft services, which I think
is a bit optimistic. But it is the idea that here is a platform
that encourages you go down the path of separate services that could be worked together
by it worked on different developers, deployed independently, can support multiple versions running
on the same service. At the same time in production without having to worry
about it, and that the way they do communication is schema base like it's
all those sort of core ideas and today's Then then you have the abstraction of
transport, so it might be Rabbit MQ or SMS or a service bus today
or even Amazons SQS like, there's lots of different ways to do stuff,
and that's the key to the power of all these service bus architectures that you
don't have to commit to any given stack in changing those things is not that
big of a deal anyway. I thought it was a nice love letter about
service buses, but it's also I think a luxury for a lot of folks,
Like it takes a very significant set of decision making to decide we're going
to implement a set of applications. Is really what we're talking about, an
overall solution suite in a service boss model, And I don't think we're going
to talk about that today because I think most people don't start there. I
think most folks build an application and get to a place where they now are
told, you know, if only we'd build this as microservice as everything will
be good. Tear it all down start over, which I've come to appreciate
the main advantage of that approach is that it means you'll be left alone for
six months while you admired your reartic. All I really want to do is
stop coming to this meeting. If I say this, can I stop coming
to this meeting? See in six months? That's what it works. Hey,
John, thank you so much for your comment I thought was super relevant
to our show today. And a copy of music cobuy is on its way
to you. And if you'd like a copy of music Code Buy, write
a comment on the website at dot at rocks dot com or on the facebooks.
We publish every show there and if you comment there and I ready on
the show, we'll send you a copy of music Go Buy. And you
know you can follow us on Twitter. That's fine. But the real fun
is happening over on Mastodon right now. I'm Carl Franklin at Techup dot social
and I'm Rich Campbell at Mastodon dot social. And it's the real fun happening
at Mastadon. I think it's or is it now happening at threads? No,
it's happening at Macedon right now. For me, anyway. Yeah,
I don't know. Are you on threads yet? I had to sign up
with it. I'm one of the hundred million in five days. Yeah,
me too. It's because we all had Instagram accounts, right, so it's
not a big deal to flip across. I never had all that many Instagram
followers anyway. Yeah, so we'll see. If your Instagram grids, then
your thread's gonna be good. And you're Instagram not good, Your threads are
not going to be so good. And yeah, are we really trying to
Are we really looking to Zuckerberg to be the safe here of anything? No?
Actually, no, thanks, No, not at all. Yeah,
I've already given her on all. I got a blue Sky account to me,
and I'm gonna try that with my friends. Yeah. Yeah, all
right, Well, anyway, let's bring on Layla Porter. Laila is a
developer advocate of VMware serving the dot net community. She makes videos and live
codes on YouTube. She's a Microsoft MVP, a GitHub Star Progress Ninja,
and the founder of the hashtag Women of dot Net initiative. Layla loves sharing
knowledge whilst having fun. No question is stupid and beginners are always welcome and
you are always welcome here on dot net Rocks Laylah, welcome back. Hello,
thank you for having me back. Yeah, you know it's English.
When you hear the word whilst, you can pull that word off. Nobody
else can put can drop a whilst and mean it. I can't say just
while unless I'm whiling away the time. Otherwise it's that's a while without an
h that's a whole other w that's it. So you know that's the only
time you'll hear me say while. Ye fair, fair enough, appreciate it.
The last time we talked was at NDC somewhere, wasn't it. I
don't know. This is my third appearance like that. Oh we did the
dot net Foundation show, all right, Yeah, that was just an interesting
time, as I recall. Quite yes, interesting, I have not.
I mean, I the Foundation is still out there. Things seem a little
more peaceful, which not much of an achievement, but I I mean,
if there's anything I can say about the Foundations, like, I appreciate the
focus on the open source leaders project leaders these days. I think it's wise
and uh and something really and something important going on in our industry right now.
But we'll that was womanly man like over almost three years ago, so
we'll probably due for dragon some foundation folks in it a loop and having a
conversation. Well, I just got some new directors, three new directors now,
so now as did I. So what's on your mind today, Leila?
Wow, there's a lot of things on my mind. But I guess
the past two years, because it's been two years now since I joined VMware,
it's been thinking about micro services. So you're talking about all of that
just now was very relevant and that was a really steep learning curve and I
can only imagine how steep it is for folks who are actually doing the thing
and moving across to microservices. So I thought we could have a little chat
about that and how I don't like microservices and would urge people to shy away
unless they absolutely, really really have to. You are not alone. In
fact, the sentiment from our most recent guests is do you really need this?
Yeah? Yeah, it is sort of the I'm not gonna say it's
a lashback, but anything that it falls into that one right way category gets
pushed back on and with good reason. Yeah, and usually by the people
that try it, and it just seems to complicate things and slow things down
and that it does. Yeah, the question is does it get you anything?
Like I have certainly worked on service bus architectured applications because they were complex
enough, with enough different stacks and enough different development teams that that conscious up
coupling to work on the work through a bus became essential. Otherwise this gigantic
multimodal app resonated with each other. We couldn't ship anything. But not that
many applications are like that. Well, buses incus are a good idea even
if you don't have a big or complex thing. I mean, that's just
a it's an asynchronous tool. Yeah, if that if that's if that's something
you need. Yeah, but where are you coming at this from? Laila?
Who are the frustrated devs? I found that at work a lot of
the people I was speaking to were advocating hard for microservices. So it's something
that I really had to look into and learn more about architecting. And the
more I looked into it and the more I spoke to people, the more
I saw that people were getting really drowned in the complexity of it. All
right, And I think, as you say, there were some loud voices
saying there's a particular way of doing something and it's a one size fits all,
But really, when you're getting up to that scale and that type of
enterprise application, it's really bespoke and I think it has to be a pragmatic
approach. And there was far too much dogma for my liking. Yeah,
yeah, it isn't that a double whammy. It's not only that microservices the
way, but this form of microservices is the way. And most of the
customers that I speak to are if we're lucky, they're on dot Net framework
with a spaghetti tangle of code. A lot of them are still on Classic
ASP and yeah, they have hundreds of applications, internal applications running on Classic
And how do you get them from going from that mindset to this big deal
of microservices? And do they need it? That's the big question. Yeah,
is there a litmus test? Is there a few questions you can ask
yourself to determine whether this is a good idea or not. My general thing
is if you can't answer yes straight away, then the answer is no.
That's kind of my going on it. If I say do you think you
need microservices and they go, well, we heard it's a good idea.
Blah blah. I stop them there because we heard or my CTO thinks it's
a good idea, we want it, or the worst thing is resume development,
resume driven development. I hear that a lot. We want to try
it, and then the complexity that it adds is just not worth it.
Also, if the teams aren't big enough, that's a big issue. I
think you need to have a big enough development team to be able to pull
it off. Otherwise everyone's going to be run ragged trying to manage this service
or that service. I've seen customers layla that feel that they need to do
it to sort of be ready for the inevitability that their application is going to
become the next Facebook or the next Twitter or some sort of like Uber popular,
you know, when in fact it's it's just another company, you know.
Yeah, and I hear that a lot as well. We want to
be read a funny thing and being that the Twitters and the facebooks didn't do
that and were successful and then retro fitted into it, which is far more
realistic. Yeah, And I think there's really good design decisions that one can
make at the beginning of application development or through application development that will enable that
transition at a later date, and that's what I advocate for. I think
architecting your applications in a way such as that when you need to if way
down the road that you actually need to go distributed or part distributed, it
will be easier. And that's what I've try to sort of teach. Nowadays,
I think you've sort of dropped a yagny on me yet another he ain't
gonna need it. Oh, you ain't gonna ye, It's right, you
ain't gonna need it. I remember that one. Yeah, yeah, hey,
you know I had to double check. But Classic ESP only when out
of long term support in December of twenty one. Really yeah, wow.
Now the original version was nineteen ninety six, so it's twenty That was twenty
five years. But you know, to me, and I think to all
of us, when you said that, it's like, it's crazy that anybody's
still be using Classic ESP. But it's like it's only JET. I mean,
it's only it's been it's fully out of support for the past almost two
years. But still okay, talk about spaghetti code wow man, and nightmares
about that stuff. I mean, the enterprise architect in me thinks about that
for a moment and would point them at power apps because odds are that's the
kind of software they're building internally, our forms over data apps, and and
I would want to go to the domain experts and say, hey, you're
tired of using this, let me set you up with this tool and sort
of go from there. I certainly don't think microservices from there. The idea
of looking at classic ASP app and going, you know, when it fix
this microservices, Oh my god, that's like the new title of a horror
movie. Honestly, that's awful, and that I do hear it. It's
such a Titanic leaps. It's just stunning. You're literally talking about nothing but
code behind Yeah, right, Like one of ISP's big limitations was the lack
of architecture, Like it was so hard to separate concerns at all in there.
And now you're going into something that you've already pointed this out. Microservices
serves lay well when the teams are big and plentiful, and that we need
a lot of architecture so these folks can work together. That makes a lot
of sense. Odds are the folks operating maintaining these ASP apps are one or
two people that have ever touched that app probably ever. Yeah, we heard
horror stories, didn't we, Richard, about people who followed a particular like
very granular architecture for services. Everything was a service. And this was a
very well known author that had this book and was consulting and they ended up
but it ended up costing them millions of dollars because it was not only a
waste of time, but it slowed everything down and there was no way to
make it go faster, just completely over architected. Yeah, and I've heard
stories now of companies going backwards that they're taking out their microservices and reconsolidating applications
just because it's it's just wildly out of control, right, And I think
it's just the developer experience when you start going into these these big systems that
are distributed is awful. You don't always know where the errors are coming from
unless you've put in great documentation that your testing is up to scratch. And
I mean we all know that when you've got a PM or a CTO breathing
down your neck and saying we need this yesterday, right, that some of
those things are I'll put on a back burner and oh, I'll get to
that and I'll implement that at some stage when it all quietens down, and
then it never advocates implemented. Yeah, and you need all that. The
point here is that the ceremony around all of this is important to it.
It is it can't be can't be optional. And I don't hear you saying
that there should be no separation of concerns, because there clearly has to be.
But you need just enough to make it work and and don't you know,
don't go overboard. That's it. And then finding that balance is kind
of hard. But it seems like, you know, I can think of
maybe three or four silos that a big application would want to be in,
right, you know, reporting services is maybe you know, communication, email,
that kind of stuff that. Yeah, But then I also find that
I don't know if I'm going to get hate mail over this, But some
of the DDD people have sort of contributed to this, you know, but
domain driven meaning you know, all right, let's you know, find our
domains and circle them out and these are going to map to services. What
do you what do you think of that? Am I crazy? Well?
I'm really glad you brought that up, Carl, because one of the things
I keep coming up against is everything to do with micro services seems to lead
you to DDD, and I think that is a completely different way of thinking.
And I like to say I steal just enough DDD to be dangerous,
but I actually think I still just enough DDD to get on and code what
I need to code. And the main thing I take away from DDD is
just high cohesion lease coupling. That's the main thing I take away, which
I think is any sort of principle, well, is the main principle that
you want to think about when you are designing your application and thinking about that
separation of concerns? And again you're you're talking about a certain threshold of complexity
to even be concerned about that. The app is big enough that it needs
a separation of concerns. Yes, I would say it has to have that
critical mass for you to actually be worried about modularizing it and going down the
modular monolith, which I'm a big fan of and it's a great term it
and that really does feel like the wild West when I've been researching the right
way, and I do that in finger quotes. To do a modular monolith.
There are so many different opinions, there's no real guidelines. I found
that was a really under talked about area. There was very little information on
that, a few YouTube videos, a few people speaking loudly about it,
but then it always had that DDD overtone or DDD undertone, I should say,
And I didn't want to go that way. So the past I don't
know, eight months, I've been researching on how to do that, trial
and error and coming up with an interesting way to architect it. And it's
all just big chunks, And I think that's trying to keep the complexity as
low as possible, but make it in such a way that you can break
off these little satellites of applications if you need to, if you need that
scale. Well, I appreciate the term that you're breaking off. So you're
already coming from the angle of you have built a monolith, because that's the
default, right that we tend to just keep adding things to that our applications
need over time, and eventually eventually you have a problem. But the always
question is like, what's the problem. Is it resonance, Like it's a
big deal to make a change to anything. Is it affects so many other
things. Or I often being the scaling guy, ran into the scaling problem
where it's like, it is very costly to scale this monolith just because one
set of services and it needs to run many more instances. That makes sense.
You know, your asynchronous things becomes services and they those things can scale
up and down. That's needed. That makes sense to me. So chipping
pieces out of the monolith is that the fair term I would say. So
I really like to think of them as satellites. And the one I always
use as an example is like a notification service. You can have that in
your monolith. But let's just say you're you want to bulks and emails or
something like that. You may have that sporadically and you don't need it all
the time. So it's a perfect thing to shove onto and as your function
or an aw as lambda and just have that scale as and when you need
it. But if you have that as a module in your modular monolith,
it's just so easy to as you say, Richard, chip that off,
throw it into something else and connect to that with ease and have your system
still a monolith. You haven't got that added complexity of everything's distributed, and
I think that's the middle ground where I think most companies and most applications need
to sit. But there seems to be these this polar divide, and these
two camps know we're sitting in this big ball of mud monolith over here because
we don't want to go that route, and we love it. That's it
in a mud pick, so happy right here. And then we have the
distribute distribute everything camp over there where every little tiny thing is a service and
now we've got minimal APIs and there's like a million minimal API applications and are
both of these lies? I mean, really, nobody has one monolith.
There's always some services extraneous, and nobody has a perfect set of micro services.
There's always at least some ball of mud somewhere. Oh it's hidden,
calling a ball of go. Yes, more than mud, it's like and
it's it's you shouldn't be embarrassed that you have one. The only question is
do you know where yours is? Right? Do you know where your ball
of go is? Because if you don't, that's a concern, that's a
big problem, right right. All the reason this world is people who have
who know where their balls of mud are and people who are lying. Hey,
guys, let's take a break. We'll continue this great discussion with Lalah
Porter after these very important messages, and we're back. It's doting at Rocks.
I'm Carl Franklin. That's my friend Richard Campbell, and this is our
friend Lala Porter and she's she's quoting blasphemy here, blasphemy. I'm shocked,
get shocked and awed and horrified. No microservices or maybe only one. Yeah,
just a couple of couples. Fine, you know, microservices the word
itself implies that the whole thing just get split up into all these little pieces.
And that's you know, when you say, oh, we have a
couple of microservices, then people look at your crosside. What do you mean
a couple of microservices? Call them Bob and Doug. Yeah, and they
sit in the corner. Yeah, I like your satellites. We have these
satellites. That's that is a good term specific things. And I know that
there is an architecture term that they call it a citadel, but I don't.
That doesn't resonate with me. And so I've really hung onto this for
the past few years, this idea of the satellites orbiting my monolith. And
I do want to say that when I say monolith, people think it's like
a negative thing, right, right. They get really touchy about it,
like we've got a monolith, but you know, we're looking to distribute it.
We want to spread it out, like people are going to judge them
because they've got a monolith, or that they're outdated. Yeah, yeah,
And I don't. It's like the word legacy. There's nothing wrong with a
well architected and well maintained legacy applications, especially if it's making money. Oh
yeah, yeah, crying all the way to the bank. Yep, it's
written in VB. Shut up. So I just I think there's all this
negativity around this space and there doesn't need to be. And I think monoliths
are definitely where every application should start, and I think there needs to be
a well considered, good plan for how that application is going to grow.
And I think it comes down to people, and it's not the code,
it's always the people. And what I mean by that is you have the
visionary, the architect, and they do it all or beautifully and the application
is st with best intentions. Because I'm sure no one out there has gone
out to architect a big ball of mud or a spaghetti tangle. I can't
think of anyone who would intentionally architect something like that. So I believe people
are going with good intentions. But how does one but keeping all the services
together in a deployment is actually efficient. Yes, it's fast, it interrupts
well, it deploys easily. Like there's a lot of reasons to do that.
I didn't make a mistake. That was the sensible thing to do until
something changes, absolutely, And I think it's where things go wrong is when
that architect leaves or they retire, or you get the new hires in and
they're not on boarded correctly, or there is no design document or style guide.
And I think that's very when too much of that architecture was in that
person's head. That's it, and it's that what is it the bus prevention
theory, hit by a bus thing for some term, or can't take a
vacation, or when you take two weeks off, a whole bunch of stuff
just stops until you get back, or worse, it carries on without your
vision and oversight. And now you've got whole new services that are duplicating things.
You've got this, and I'm talking about service services within an application,
not microservices. So you've maybe got some different new interfaces, or people are
doing weird things with dependencies, and you just get this this. Well,
concerns are getting tangled, there's no separation. We're getting this cross contamination of
those clear boundaries that should be in place. And I think this comes down
to something I only recently discovered, and that that's like architecture tests. I
don't know that was a thing until I started researching this, and it seems
like a silly thing not to realize that it was there. But you can
put in a whole load of architecture tests that makes sure that the architecture you
put into your application as being adhered to, and that can be like different
projects aren't referencing projects they shouldn't be. And it just seems so logical to
me. In all the years I've done TDD and testing, this has never
come up. If you never once unit tests to validate your adhering to an
architectural press, Yeah, well it's a good idea and I'd never heard of
it. I'm trying to conceptualize how that even works. Well, there's a
framework coworld architecture dot net. I believe, I think that's the name of
it. I could be wrong, don't quote me on that, but it
is a series of unit tests that check for architecture parents and I had never
seen it, And when you start looking into it, it makes perfect sense.
And how what assembly can reference what assembly? You can get quite in
depth with it. Okay, I get it. So you're using reflection a
lot to figure out how these things are coupled or decoupled or not coupled,
and what calls what and making a code map and yeah, okay, yeah,
that makes sense. And it doesn't seem like something that you would write
tests for. Maybe you would just tell it what the guidelines are, what
are and it would run a test and say, okay, here are your
problems as I see them. Yeah. Cool. I thought it was pretty
cool because something that I've come up against when I was in engineering was that
there was so many different places to do the same thing. I worked on
a dot net framework app that was fifteen years old, and you didn't know
where to add something in because it could be in one of a number of
places, and there were I don't know ten twelve different projects within this application,
and you didn't know where anything was going to go. And that is
where so many applications are because they all sort of grow over time. And
that's the whole point. It's a development process. It doesn't just magic up
overnight. So you know, people don't hang around jobs that long. So
how do you do this and how do you keep that? And it's I
think there's three places that you can. You can start looking at adherence to
your architecture, and that's visual looks, so getting someone to do a code
review and going to check it. You can have sort of tests in place,
and you can also have you know, compar wild time testing on that.
So there's all these different levels that you can have to make sure that
adherence is being met. And it just made sense to me, but I've
never seen it done in practice. I'd love to know who's doing this in
practice. Yeah, something something to fall around on. I did find the
GitHub repository for net arc test. That's the one, yeah, based on
the Java art test. Yeah. Yeah, and just that exactly idea of
essentially writing assertions that say here's our architectural rules. I mean, I don't
want to say that you just want to pop warnings, but certainly when you're
writing code, especially new to a project, to have it come back and
say, hey, we have an architectural requirement around this, and this code
violates it. So at least you know you're pressing against edges that nobody wants
your press against. And it's also documentation because someone can come and read those
tests, and you know that's the first step of a documentation for your application
and your style guide. You're describing intent at that point. And even the
best part is when your architect goes on vacation, they could be sitting on
a beach and looking at the results of these tests and then send an email
that says, hey, what are you guys doing? Stop it? Yeah.
Yeah. So it was really interesting to start delving into this world and
it really felt like the wild West. And my teammates they're all Spring advocates,
so they're very into the distributed systems, very into all of this enterprise
architecture. I think Spring has been far ahead of dot net in that respect
of pushing that and offering the libraries that support that kind of architecture. So
learning from them, and some of them are really big DDD advocates, so
trying to to dissect what I want from from what they say and the stuff
that I don't which is too far in the DDD realm um. It has
been really interesting, but it's something I don't hear spoken about. It is
the tea camps stay away from monoliths or stay away from distributed systems, and
there's never this in between, which I think is why people should be.
I really really strongly feel that it's I mean, ultimately just to try and
make more maintainable projects. Yeah, you have to have a new acronym here
jed jeed just enough distribution, that's it. That's a great acronym. I
like that. Oh okay, I don't like it so much now, No,
not my favorite. To join my foundation, it's fifty acronym right there.
But it was interesting going through the modular monoliths and how you can start
implementing so many of these good patterns such as the asynchronous communication. You can
have all of this message brokers implemented into your modular monoliths, so you can
have all these modules and how are they speaking to each other by a service
bus. So it's interesting that you were bringing up that because that was something
that I worked really hard when I was building out a workshop on that used
a modular monolith to get them messaging in that sublayer really really clearly defined so
that people coming into those modules knew that each module could only communicate a cross
a module via the asynchronous messaging, which was really a fun challenge to architect
and think about how things were going to go and getting away from that synchronous
I am waiting for a response mindset, yeah, yeah, and just trying
to think, well, what does need immediate response? Well, anything user
related and that's all going to be external, and basically anything internal doesn't need
an immediate response, so you can offload all of that. Even though that
even though the difference between immediate and this is milliseconds, it's perception, it's
it's yeah's yeah, And it's also an architectural uncompelling yeah, that the returns
come from a separate stream than the outputs. Um. I am deeply disturbed
that we've spoken in this launched and you have not said Kubernetes, like,
what's up? I did, but I try to avoid that very serious,
right, I mean, there's another angle to this microservices push, which is
it is also soling product right, and that's annoying too, Like there's other
set of motivations around this and I and I mean as much as I'm making
fun on the whole Kubernetes angles, like I am talking to more folks who
are rehabilitating brownfield monoliths with Kubernetes, that that's a form of encapsulation. It's
creating new security parameters, it's making them clean up messy bits of the code.
The process of getting it to run well in a container tends to make
the product better. They act better in the long run because it does start
to separate out how we do state management, how we do storage, like
all of those things are good, but it doesn't You're doing it because you
want the software to be more reliable, not because somebody told you containers would
save your life. And I've recently been shown this cool architecture by one of
the solution engineers at work because VMware Tanzu the bit but I wipe for is
all about cubanetis and that kind of system. I don't really delve that deep
into it. I'm very much still on the code site. But the type
of thing that you can do with CUBANETI, especially with the edge, is
fascinating. So I learned a whole new way of architecting systems that is still
monolithic but relies on Cubanetis as a way for engineers to easily distribute their code
to edge locations and manage it centrally. And I've recently learned about a customer
that has thousands of edge locations all running on VMS and they have to manually
go and update each release on that, And I'd never thought about that aspect
of it and coming background to how you can centrally manage that and get things
that are low to no code locally because a lot of these edge locations don't
have people who are technical at them, and they may not have constant Internet,
so having something that can self heal and manage itself is really really important.
And I've never appreciated that aspect of kubernetties. I always thought it was
the oh, let's go to microservices, let's do this, it's the latest
buzzword. But to see how it can work in that type of situation and
make a DevOps engineer's life that much easier and automated had never occurred. To
me. So that was a fascinating thing to learn. And I feel like
I'm learning so much these past two years from a difference from being an API
developer coming over to this whole new world of really big enterprise development. It's
been a steep learning curven and I really appreciate people who are in those engineering
teams trying to figure this out. Well. I think important part here is
reckonizing EDGE doesn't mean the client machine. EDGE might be the CDN closest to
the client machine, absolutely, Like that's just to getting into this idea that
there's more places than the client and the server to deploy software too, and
that you want to sort of unified strategy for saying, Okay, I'm going
to push this compute closer to the customer, but not on the customer's machine.
And I think it's a it's a hard idea to deal with. And
you know, folks who've only ever thought about CDNs, think about static images
and files that way, and now you're talking about units of compute that could
be there where you don't know necessarily what you're going to do, but you
they havent you have control over it. It's it's not exposed to as much
security risk, but it is performant. Making changes is inconsequential, right,
I mean simple, Well, the mockery of containers has been Hey, I
took a fairly complicated set of services in the back end of my server and
made them far more complicated, right, Like, just broke them into so
many more pieces. So it's just so much more to manage not getting into
this. Hey, it's not all sitting in the same server anymore. It's
pushed to all these other places as well, and that was impossible when it
was stuck in one location. These are very much opts problems that a lot
of developers. I don't think you spend enough time just being aware of what
we're trying to do to create good performance for customers those asynchronous bits, because
the customers is not directly affected by them, mean it doesn't matter that we
added latency by pushing that stuff to the edge, and the data is going
to sink later because the customer's done, they feel they've entered their order,
they've done their workload, whatever they wanted to do, and eventually, again
measured in seconds, the data sink back to the primary repository, wherever that
may be. These are complicated problems and you don't get to decide of an
advance. Which you're doing here is building architecture to make those options possible.
But don't do it if it's not going to happened, because it's not simple.
No, it's that complexity versus the outcome. And it's something that I
always try to stress is everything you add to your application is going to add
complexity. You were talking about service discovery. I speak about service discovery.
I've got it in workshops. It's good because you know your applications can self
register. You don't have to worry about it. It's all dynamic and it's
hands off. But hey, it's an added layer of complexity. And it's
very easy just to go out Willie Nearly and add all these new services,
these funky things, these features do all your resume driven development. And then
now you have this horrifically complex application that even the architects don't know what's going
on, and it just gets less and less and you get that distributed big
bowl of mud. I mean, I wonder if you have to have a
service failure right where the app's been deployed with this is the service we call
and then for whatever reason, that service is down and the back of one
is up. But because we didn't use the service discovery, we didn't even
know it was there, so we're out. Before you finally justify adding that
overall ongoing cost and complexity of service discovery, yes, yeah, it's like
you need to feel the pain and have that experience before we value that complexity.
Right, So if we now got pain driven developed, we've always had
that, Yeah, well you know your resume driven models. They I've always
wanted to build one of these, not that we need one of these.
So part of that, you know, that pain piece is recognizing this can
cause outages, and so we're going to incur this cost willingly you think about
all the people that are affected by that. Right, It's not the developments
more difficult. The deployment's more complicated. OPTS needs to know about it,
to know when these services shift, make sure the security contexts are right,
like, it's a lot of people involved going forward. Testings more complicated like
that, nothing's free for adding that capability in exchange for avoiding a possible outage
effectively. But also the other one, the other scenario that I've seen is
we can't deploy because we need those other guys to update to this new version,
to this new service too, before we can deploy where what we did
bus is properly. We don't need to and that's why you have no Well,
that's the worst case scenario which you see people do, which is that
distributed big ball of mud. Yes, so they go from the monolith to
that rather than the monolith to the modular monolith to the micro services, and
it's the worst place to be. I have the distributed ball of mud.
It's not just a ball of mud, it's all of mudd, and multiple
times that. Leila, what is next for you? What's in your inbox?
Ah? Well, I've got quite a lot of events coming up.
I can't imagine. Yeah, just hanging out with people like you two in
the meat space, which is always fun. There's quite a few events.
Are we all doing INDC Porto, I think we are, Yes, Copenhagen,
we're all doing Copenhagen, Yeah. And we're all doing dev Intersection yeah,
yes, and that Richard and I are at dev Reach and Poland I'm
basically doing a world tool with you. Richard. I think you're bombing around
together pretty much. Are you going to run down to dev Reach after after
Poland as well. Yeah, you'll probably get on the same flights. Oh
yeah, because there's already three of us on that flight. Yeah, and
we're yeah, we're splitting with like splitting shows like this. But you know,
you get into situations you do. So yeah, I'm I'm working on
the old YouTube content. I've just been on some cool courses learning how to
do new awesome stuff with video streaming keeps getting cooler. That's great. Yes,
that streaming is a weird place. I've sort of put a pause on
that for a little while, but I do love it. I love just
the live coding. So yeah, just doing a whole lot of load of
stuff and always learning, was trying to cram more knowledge into this cranium.
Awesome. Well that's great, Layla, thanks so much for spending this hour
with us. It's been fantastic. Thank you for having me. All Right,
We'll see you next time. I'm dot net Racks. Dot net Rocks
is brought to you by Franklin's Net and produced by Pop Studios, a full
service audio, video and post production facility located physically in New London, Connecticut,
and of course in the cloud online at pwop dot com. Visit our
website at dt n et r ocks dot com for RSS feeds, downloads,
mobile apps, comments, and access to the full archives going back to show
number one, recorded in September two thousand and two. And make sure you
check out our sponsors. They keep us in business. Now, go write
some code CNX time, got amcoring