In this episode of Adventures in .NET, guest David Dieruf joins the panel to discuss .NET microservices. They clear up the confusion about what microservices are and how to use them?

Hello, and welcome to another episode of adventuresin.net. I'm Sean Klibber, your host. And with me today is just your other cohost, Wai Lu. Hey, Wai. How you doing today?

I have one, Wylu. Doing pretty good. Yeah. We actually have a 3 day weekend where I'm at. I don't think you do.

No. What the what what holiday is it? It's it's Labor Day as we record here. So Uh-huh. Monday, I've got Monday off.

So 3 day weekend. The weather's supposed to be, like, 95 degrees today, which is really hot for for September here. Sweet. Man, nice. It's getting warm here though, I think.

So Yeah. You're you're just moving into get ready for spring? I think it's September. It's spring. That's yeah.

Mhmm. Yes. So I started spring now. I mean, so Okay. Alright.

Cool. Alright. Our guest today, straight from Kentucky, is David Duruf. Hey, David. Hi, guys.

Hi. How are you doing? Good. Good. Glad to have you, Joe.

Thanks for having me. Yeah. No problem. No problem. So I think, first, before we get started, why don't you tell us and the listeners a little bit about yourself, you know, what you do, how you get started in development in .net?

Sure. So back way back in the day, longer than I'm going to admit, way back in the day, and, you know, technology has just kind of been in my blood. I I got started a long time ago. So my best friend and I were big into jets. Right?

And at that time, we were thinking about we wanted to fly jets. We were dreaming. There was a game that we found that you could install on 2 computers, PCs, and network them together. You can't see it, but I'm quoting. Network them together over serial.

And you could fly against one another, dogfight. But it turns out that, like, the sound card and all that stuff, you had to set up all the jumpers, you know, you had to break open the machine and get everything right. We did it. We got it to work. And to tell you the truth, like, that between that and, for some reason, databasing for me, like, that did it.

That just couldn't drew me in. And so I was very young then. And then, very early on into the dot net space, the database seemed like classic ASP and access database. Like, writing a website that picked data out of a database, I changed it. I put it back in.

I mean, that just blew my mind. Yeah. Yeah. I remember doing doing the same thing, you know, with access and active server pages, you know, moving in right before that, just dealing with flat files is what I dealt with before that. So, yeah, Being able to actually have a have a real database was was was so nice.

And it it just kinda happened. I ended up my dad at his work got me a Windows 3 dot 1 machine. There was, like, a, I guess, 46, possibly 386, and it was just on from there. I think it's I think it's funny how, like, when you're when you're little, it's features that really kind of impress you. I think for me, it was like it was it was the Internet, actually.

I think I I I was one of the first people, actually, that I knew actually that got a 30 three k modem or something like that. Oh, 336 cable. I remember that. And I and I remember, like, logging into, like, b s BBSs, I think bulletin boards, they were called. And, yeah, being able to type and see what be able to communicate with other people, it was just like it was just revolutionary for me, you know?

Like, So You know, guys, I am so old. I am so old. You know? You're talking 33 k. I started out 300 God.

You know? Then then the big jump to 1200 God. It was like, well that was, you're you're you reminded me of, like, the days of what around here, at least, it was copy copy serve. Yeah. And then it was AOL dialing in, you know, on AOL.

And, you know, my mom would pick up the phone. It's like, I don't care. You just yelled my connection. Like, here in the city, you got all these, like, CDs from AOL where you get we gave you, like, 60 days free or something like that. Funny.

I can pick it on. Out. Yeah. Every week you get one. You know, I think they're still around.

Yeah? Are they still around? I'm pretty sure, like are. Like, my, in fact, my my wife's parents, they turned up with an AOL address. And I I just, like, learned it the other day.

Like an email. Yeah. Still works. But that, like yeah. And and, like, learning about NFTP and then being able to take your HTML and, you know, put it up there, and it's like, I got my website, you know Yes.

Out there and all that. Like, yeah, man, that was a lot of fun. Good old days. Yeah. I remember seeing my first, you know, in a book, in a magazine somewhere, HTTP colon slash slash something something.

I went, what's that for? No clue. I've never seen that before. Yeah. So so it was, that was, for me, that was the beginning of it.

And then it just kinda grew and grew. I, I took a bit of a detour in my what would have been my college years. So, like, this is this is a good moment. I dropped out of college. I moved to San Diego, because that's what you do when you move out of college.

Drop out of college. I could write code. So got a job doing some shady things for cash, writing code for search engines and hacking search engines and such. This is before the days of Google. This is when metadata was, like, you know, the thing.

Yeah. Kinda worked my way up a little bit over the years, couple of years, then the bubble burst. And you're in Southern California when the bubble burst and, like, dude, like, Wednesday, you're at work. Thursday, your development team's sitting on the beach because everybody's fired. Right?

It's just done. Mhmm. And so at that that time, I said, I'm gonna do what I've always wanted to do. And there were there were kinda 2 interests in my life, computers and cars. I could take apart a car like nobody's business.

My dad taught me, and I could write some code pretty darn good. So I got a job on a race team and started building race cars. Wow. Had to stretch resume a little bit. Was it open wheel or what class?

Yeah. Yeah. It was. So I started out in, it was it was it was all in America. And, I, open wheel series called Formula Atlantic.

Oh, De Boss used to race that. And then so that's kind of the minor league to the big cars at the time was ChampCar. That was where you aspired. So I did that for a couple of years, moved up to the big cars, and the ChampCar ChampCar and IndyCar well, they didn't join. 1 bought the other, really.

And so I switched over to sports cars and did, like, Le Mans type cars and the the America Le Mans series and, got into endurance racing and all that stuff. So, anyway, that, like, that was it it's weird because that was a turn, you know, towards, like, nothing but hardware, you would say. Because my job on the team was all the sensors, all the wiring, making some of it, maintaining it, the radios on the car, the telemetry off the car, building the timing stand, you know, analyzing some of the data, rough or very, very light, analysis of data. You know, you're just engulfed, right, in technology, in, like, the bare bones of technology, and squeezing every possible moment you can out of it doing that. It's so much fun.

It's so hard. But it's got moved back. Somehow, you got moved back to programming? Well, to tell you the truth, like, I was always I was always dead set. Even working, you know, getting the hardware and learning about the sensors and, you know, taking digital or, analog data off sensors, bringing them into a CAN bus, and then, you know, storing them on a computer, all that stuff.

I was always trying to write code to do something. And as you got into the more advanced systems, like, we we built this ALMS car that we inherited the data system from the Honda Formula 1 team, because it was a Honda chassis. It was a Honda engine, actually. And it and so the Formula 1 team had folded. And so they sent us all the boxes of their stuff because Honda was all about this ALMS car.

And I got a really sweet McLaren system for the for the car, and they kinda let me go. And it had an API. And, oh my gosh. I had a lot of fun writing code, doing analysis, crunching data, just, you know, doing all kinds of fun little things for, you know, looking at trends in the data, popping up messages, looking at tire pressure sensors, and watching for you know, trying to automate things like that. So like the code piece for me, it's always been there.

What language is this? C sharp. Oh. Somewhat surprisingly, probably, because that was like dot net framework, but it was totally c sharp. Yeah.

So we just have a computer inside the car, whatever? Yeah. Yeah. I mean, that that's the thing. Like, the the you know, you well, in a race car, even in a street car, you know, you you obviously have the the physical aspects of a driver and the mechanics, you know, setting up the car, setting up the geometry, the aerodynamics.

You know, obviously, those are all very physical things on the car. Then you put a sensor on just about everything or or as much as the series will allow you to to put on the car. And the trick is taking the sensor data getting the sensor data off, getting it, you know, clean in a good place, and then being able to combine it together. Use your analysis software to combine it together to actually say, you know, based on what all of these load sensors, these wheel speeds, the the bars the the load on the bars, put all that together in a trace and find the understeer, the oversteer in the car. You know?

And really good engineers can do stuff like that. So it's like writing software to try to help you zero in on those moments and find those things very quickly is invaluable. A very I never could get it, but this obviously, this is this is just begging for machine learning here. It's some, like, big data kinds of thing. Anyways, that that the race car world, it it was so much fun.

I loved it. But, unfortunately, I, I moved not unfortunately, but I moved on. Because the tough thing is a team usually lasts about 5 years. And then you're gonna either gonna move to another team or find some sort of flying job to do or something like that. And you do that a couple of times, and it just gets old.

And I was getting old. So, so anyway, that's, So when did you actually, you know, start having, you know, development as a career? You know, actually Oh, hardcore development? It's it's been a long time. The funny the so, like, the thing is, until so after I left racing and I went to I actually just consulted locally for a while.

That was definitely hardcore programming, consulting and all that. Then I I got a job at Pivotal. And Pivotal was the largest company I'd ever worked for. At the time, it was about 2,000 people. And that was like enterprise to me.

But then at Pivotal, I was introduced to, you know, Fortune 50 companies. That's pretty much all we worked with was Fortune 50 companies. And it was like a shock. Right? So, like, when you say hardcore development, I I have all these things flash in my head because I'm like I'm thinking of all those folks that I I talked to even today in this Fortune 50 companies that just live, eat, sleep, and breathe all these applications.

And then I think about the startups, right, that are, like, on the cutting edge trying to do all the super awesome, right now, Kubernetes stuff. And, you know, really trying to push the limits in automation and and code first and all that. And it's like, I've always had my hand in that some way. It's just a question of whether I understood, like, the proper name for it or not. Right?

But I've always kind of just it's just kinda come to me. And where do you work at now? So Pivotal was acquired by VMware at the beginning of this year, 2020. So we they started a new line of business at VMware called Tanzu. So that is basically what Pivotal was with application development with a application platform, cloud based application platform, using Cloud Foundry, and then we're moving to very quickly to Kubernetes focus.

You know, I'm just in the middle of all that. I'm a bit of a, I guess, a developer advocate is the correct word these days. I guess it was DevOps for a while, but now it's changed developer advocate. So anything to do with dotnet on our platform, modern applications using dotnet, Windows is still in there, but quite honestly, it's kind of going away for me a little bit. That's my focus today.

Yeah. I think some people might be surprised to to learn that VMware has dotnet, you know, in some of their applications. No. I don't think they're primarily a dot net product. Right?

No. No. Oh, no. But but now see, that's the thing. Like, VMware I'm sure when you guys think of VMware, you think of infrastructure.

Right? You think of VMs. Right? And that sort of thing. And so that the the the the roots of the company doing infrastructure and virtualizing hardware and that sort of thing, they have a very heavy base of Windows there.

A lot of customers running Windows. But those are like Windows desktops. Right? Virtual Windows desktops and that kind of stuff. The Windows applications are first, they they still have a heck of a lot of that as well.

Our focus is but we're actually bringing an entirely new dynamic to VMware. Because imagine a world where not only they're so good at doing infrastructure and virtual machines and such, but they also are good at running, like Kubernetes clusters, which then opens the door to let's talk to developers. Right? Infrastructure is almost, well, it's not secondary, but it's a separate conversation, and it's been abstracted so well with Kubernetes. Like, let's just talk about how you're gonna get applications to production.

Right? And that's it's a shift for VMware. It's a very new shift for VMware, but one that that is becoming more and more natural. Alright. So I think our our main topic for today, we're here we're gonna cover microservices.

So how'd you get into microservices? Or let's first start way at the beginning because we've had a few episodes that have kinda touched on microservices, but it's still, you know, kinda fuzzy in a lot of people's minds. What is a microservice? When when do you call it a microservice, and when is it not a microservice? So let's start there.

Okay. And, actually, let's you know what? Let's try to do a use case here. Right? Because I I can try to describe all these, you know, abstract and nebulous kinds of things, but let's just take a use case of payment processing.

Right? A payment processing system. This one is top of mind because it's a project that I'm helping out with. So you have in, it's actually somewhat modern. But let's say you have this payment processing system where you have merchants that they process payments.

Right? They take customers' credit card numbers and process payments. Then they have, you know, customers, payers, and then you have a transaction engine in there. So in, like, dot net framework, you're gonna build all this. It's going to be probably either one large solution with a couple of projects in there, but it's gonna be pretty tightly coupled, all of these different projects.

Right? And when you wanna go to deliver when you wanna go to deploy something, it's going to be basically one large DLL or maybe a couple of DLLs that are really tightly coupled to one another. Right? As you can imagine, deployment going to production and things, it's a event doing something like that because you're basically republishing the entire application every time. Right?

That's the the monolith side of things. So we wanna take this and we wanna break this apart. Right? And we wanna make this the reason we wanna break it apart is because we need to be able to iterate on these individual things without making production such an event. We wanna be able to put in little features here and there, publish those little features, and not affect anything else.

Now in doing that so this is the shift from a monolith to a microservice. In doing that, I'm gonna take 2 assumptions here. 1 is microservices is harder. It's it's harder to do than, like, a monolith. Meaning, if I wanna do a monolithic application, I can have it in one visual studio, and I can kinda do my whole thing.

Right? Develop everything. I've got connections between projects. If I change something here, my squiggly lines are gonna show up in my other project because Visual Studio is gonna tell me I've made some bad mistake there or whatever. It's it's pretty intuitive.

You know? When you move to microservices, they're decoupled from another. They don't know about one another, like, you know, sitting in Visual Studio or something. So if you make a change over here, you could easily break something over there. And you have a bunch of projects, a bunch of things out there that you have to maintain.

Right? Not just this one thing. So it's harder. The second thing is we are now going to connect all these applications over the wire. So we need a really great network here.

Right? Because we're about to add double, triple our traffic on the network by these all these microservices running independently. Alright? So we'll we'll we'll understand those two things. So our payment processing, system, we're going to break it apart into microservices.

So first, we're going to say we're gonna do a domain exercise here. Right? And we're gonna say, what matters to the business? Process being able to sign on merchants, the merchants being able to track their customer information and their customer payments, and being able to trans process payments. Those are kind of the the 3 big ones there.

So those are our domains. So that's actually gonna become our microservices. Right? We're gonna have 3 here. Then the, merchant side of it, we're gonna create a microservice where you can do everything.

We're going to take the tables in the database that have to do with merchants, and we're gonna break them out of the database and create our own little database. And and we're gonna call it the the number 1. Right? Alright. So the so the boundary of a microservice isn't as as far down as, like, each endpoint to an API.

It's gonna be all those API endpoints that are grouped together for, like, a single responsibility. Responsibility is a good word to use there because the thing is when you're going to microservices assuming we're gonna do this right, because I've seen a lot of bad decisions out there. You know? Thinking a microservice is going to be a single table of the database. Right?

That's that's the correlation that you're gonna do. Things like that. Bad idea. Because when you go to microservices, if you're gonna do it right, you're going to involve the business. Right?

It's not just gonna be developers sitting at the table saying, here's how we're gonna design this thing. You're gonna bring in the business, and they're gonna sit on the other side of the table, and you're going to create you're gonna have a language. Right? It's like as I'm talking to my my business counterpart and I say customer, it means the same thing to them that it does to me. Or in the payment world, when I say, like, a payment gateway or a transaction, in the programming world, a transaction can mean 50 different things.

Right? But to a business person that's not technical and you say transaction, what does it mean to them? Is the right word payment instead of transaction? Right? So it's that kind of deal.

It's that kind of dynamic. That is your domain. It's that that entity of work, that responsibility. That is your microservice. So it sounds like then that I'm I'm just trying to visualize that example.

So it sounds like each microservice is almost like it's its own application with its own data layer and its own domain. Yep. Okay. So So that that like, we've just gone through this this this this, development team that I'm working with. I I really wanted to get, like, deep hands on with these guys because they're it's just, you know, I enjoy doing it.

I wanna help them get to some modern places, and I'm learning a lot along the way. And so one of the things is consider, a merchant has an address. Right? And a customer has an address as well. So there's one address table in the database that's holding all this information.

But when you break these things apart, what do you do? Because both of them need to know about address. But if you create some utility, like utility project that both of them are using, utility DLL package, sorry, that both of them are using. Whenever you update that utility package, they have to redeploy. And everybody else that's using that utility, bad idea.

Right? In the microservice needs to be within its domain, is the right words, or completely encompassed in its own thing. So it's okay. Both of them might have a different definition of what an address is. 1 of them might care about two lines of address and a city, state, and a region, and longitude and latitude and other things.

And one might only care about, you know, little bits and pieces, a ZIP code and an at you know, line 1 of the address and city and state. So both of them hold address, but they have different meanings about what an address really is. So kind of a duplication there. Yeah. So would they share that database table, or does each microservice get its own data layer and Yeah.

So this is, so we're very much entering, you know, the specific use case kind of realm here. Right? Because if you're reading a book about microservices and things, this is where it would get really generic and not really answer you because it's gonna be very specific to your situation. I would say in this situation Everything there. The direction that we're going right now and I'm I'm I'm feeling this out a little bit.

But the direction we're going right now is we've we've introduced the notion of models and DTOs. Right? The the data data transaction operations DTOs. DTOs. We've introduced the notion of both of those.

What your DTO, you own the table of that information in the database. Right? So you maybe own the address table in the database. The other one has a model of an address because you don't actually own the table in the database, but you need to know what an address is. You need to have a definition of what the address is in there.

So it it gets messy there, I will admit. Right? And you kinda have to feel out the right way to do that. But this goes back to also, like and it's classic in a classic microservice, every microservice has their own database and grouping of tables, relationships of tables, and nobody else ever accesses those tables but that microservice. If you wanna learn about an address, you gotta go to that microservice and get the information out.

So in that respect, everybody would have their own address table. Does that make any sense? So would the would the architecture of each market service be pretty much the same as just a normal application? Like, with a with a, you know, web layer, maybe a business layer? Layers, all that stuff.

Sure. Yeah. Okay. So it's just basically different applications communicating with each other then. Now typically, though, in a microservice, you're never gonna have a UI.

Right? API is Okay. The interface. A microservice, at least to me, a microservice is an API. Your UI so your UI is gonna encompass, you know, all these domains.

Right? Because that's the the accumulation of, I wanna now create a product, an interface to do this product. And so it's going to talk to all these different microservices, all these different APIs to gain the information and then display it up onto somebody. That's making sense. Yeah.

It's making more sense to me, actually. So yeah. So I'm thinking to put together, you know, a a set of microservices in Visual Studio. You would you could do it with each one's its own little project as long as you don't reference make any references from one project to another. Is that right?

Yeah. So this is where this is where you're gonna make some really bad mistakes, and you're gonna make really bad choices, really, should I say? Oh, no. You're here. Yeah.

I know. Your interconnectivity between the 2. I'm gonna try to profess what I believe are the right ways. And that is you're going to create packages, and you're gonna distribute those packages over some system. If you're using it, like, privately, Azure DevOps has a very nice artifact distribution, artifact repository.

It's NuGet based. Right? And all that. You can use NuGet straight up to privately I'm pretty sure you can use it privately or publicly if you want. But, yeah, your microservice is actually going to be actually, for me, a microservice is a project in an overall solution.

And the solution has the API microservice, has a unit test, and has an integration test project within. That's the bare minimum for me. And then the solution encompass all of that and the API bit of that, the the DLL out of there, that's your distributable, for, you know, others to use. But remember, over an API over a microservice, you're connecting to it, over HTTP. Right?

You're not bringing that DLL into some other application. That's a no no. It lives on its own. It's it's distributed on its own. It's running out there in its own container, and it has a web server on it, and it is available over HTTP for you to connect to and look up information.

Okay. So like in the IMS world, every DLL or app microservice would be in its own application pool. Yeah. You totally just aged yourself right there. You totally Yeah.

Because, to tell you the truth, like, that that talking about IAS, much less talking about application pools is just gone. Like, there's just still a lot of people that work in that world, including me on some of those projects. So we got we gotta talk about it. Totally. But now to me, my application so, like, I'm I'm you know, I've I've moved to dotnetcore.

Right? I we have to, make that clear. I moved to dotnetcore.netcore, each application has its own web server built in, has its own Kestrel server built in, and it's within a container. Right? So what you would have with IAS and pooling, now I have with Kestrel, my own web server and and containers running out there.

And then my containers, you know, run-in some platform and so on and so forth. Yep. For so it's the you know, there's the old kind of way of doing things. Very rigid. Right?

When you get into IIS, when you run many sites or or many services and things in IIS, very, very we always have the term of cattle versus pets. And an IIS server is a pet. You love it. Right? You you you customize it.

It's yours. I don't know if I say it, and I love it. Well, you know what? You have to. You have to.

You have to. So, like, that thing, it means so much to you. Right? And and, really, I would say that's a problem. Because if you're terrified of ever restarting that that pet or, you know, updating, the operating system or something, that's a problem.

You have a very, very rigid system, and you cannot move with the times. Right? It's holding you back. But if you move over to this, you know, self contained containerized kind of place, instantly, I don't care about any of that stuff. Right?

The operating system just needs to run containers. You update that operating system anytime you want. I don't care. It has no web server on it. It just I just need to be able to run containers on it.

And my container itself contain it is running some version of dot net within. I control that. All the packages, how IS is configured is running totally contained. So I don't care about the operating system anymore. So that's why microservices and containers, like, you're almost always gonna hear them talk together.

Right? That's just peanut butter and jelly there. Okay. So it sounds like there's all sorts of good things for microservices, but there's gotta be some bad things. What are kind of the most common challenges that somebody would run to when they're trying to get to a microservice architecture?

I mean, no doubt the first one is they're hard. Right? I mean, imagine you have all these different projects. Now all these different solutions, each one has their own unit test, their own integration test. This gets unruly because you've got a lot going on.

You have 2 different definitions of address. Now microservices are are easier when you have many development teams because, you know, they're just worrying about a single microservice. But if you have a smaller development team, which is probably the reality of a lot of us, you're maintaining multiple microservices. And so you always gotta keep that context, that that boundary, of which microservice I'm working on. And that's hard doing that.

So that's first thing for sure. The reality there of moving to microservices. I would I would say, though, the benefits of doing that versus the overhead and maybe a little bit of debt that you're taking on, for moving to microservices, the benefits outweigh the negatives there. So at what what point, in the size of your project then do you do you decide to to adopt the market service route rather than you think? It sounds like for small projects, you probably don't wanna do that.

Would that be true? That that's that's a really good point. Because as you read headlines today, and, you know, you're just you you just hear developer advocates and things, they're always talking about microservices, and going to containers, and that sort of thing. And it kind of indirectly makes you feel like your monolithic application is wrong, and you shouldn't be doing that. And that is not the case.

Right? This is a decision. This is a technical decision of really, it's I'm sorry. It's it's a business and technical decision. Right?

Do I need to have my system in a place where I can iterate on these little pieces very quickly and go to the go to production with these little pieces very quickly? Will that give me a business advantage? If the answer is yes, then you probably need to be looking at microservices and not, you know, just single deployment monolithic applications. If the answer is no, it's like this application is what it is, and we don't really get many features for it. It just runs.

There's no reason for us to really iterate on it too much. Then don't break it apart. Right? You're fine. It's just like, if the business is on you to to, you know, add new features and and really, you know, move with the times, or the technology is just really causing you to hold on to server 2008 or something like that, yeah, that that that helps you make the decision.

But it's worth calling out, like, a model of the application is not wrong by any means. Yeah. Because I thought that I guess before we started today that are taking, as you and then as Azure function. Okay. You develop a, an application using Azure function.

Each each one of those Azure functions would be its own mock services. But it sounds like a mock services that's here a little bit bigger than that. It's its own application, essentially. Yep. You're, don't blur the lines between what a, like, a Cloudflunk function is and what a microservice is.

They on the outside, they could feel like the same thing. They're not. One is very granular, and one is a little less granular than the other. But on the on the scale of things, you know, granular up to just grand, a function, very, very specific job. Right?

Scale to 0 kinds of things. I just wanna do this thing really well and very efficiently. Then you move up to a microservice, and it's like, I've got this domain of things that I need to do really well, but there are a couple of things that I need to do well. And then up to a monolith where it's like, I'm doing everything, hopefully, really well for it. So kind of different levels there.

The the the function thing, like, honestly, I don't run into a lot of enterprises that are doing any sort of production functions, cloud functions kind of stuff right now. It's just it's a lot of talk. It's very cool. There's definitely, you know, enterprises and and definitely folks using them and using them well. Right?

They have a great I Lambda is a very, very popular feature, I know, of AWS. But in the grand scheme of things, functions are just so specific that it's like, I don't know, the adoption of it maybe needs a little more time or something. So do you have some suggestions or recommendations on how to, you know, migrate or move from a monolithic application to microservice? Carefully. That's my that's my suggestion.

Now Where do you start? Where do you start? Like, seriously, I'm I'm you know, I've done I've done some some webinars and some talks. Some of my coworkers have done some really good talks about this, but I am right now just kinda kinda force myself a little bit to get hands on and do this. And this is it's just so complicated because all the decisions your your your journey of taking a monolith to microservices, your journey there has so many potential places for bad decisions, and you don't even realize it.

Right? And there's so much learning that you have to do to figure out whether that thing is good for you or not. You know, when you get along this, you start reading about event driven stuff and using a message bus. Is that right for me? Is that, you know, is that good or is that bad?

And you have to you have to really disconnect your your technologist side because it's like, oh, an event bus would be really cool. Like, that would be a lot of fun to implement. You can't look at it that way. It's like, yes. But is this going to be good for the business?

Right? That's the reason this application exists, to make money to do something for the business. Is that right? To use this technology, will this give me some edge? Maybe yes, maybe no.

Then there's, like, decisions about, like, okay, Microsoft with dotnetcore, and, you know, we're moving on to dotnet5, has introduced officially the notion of long term support releases. Haven't really done this before in dotnetframework, which made life very difficult to stay up to date with things. But now they have that notion of long term releases. And so that makes you like, am I going to choose to only follow long term releases here? So dotnetcore3.one is gonna be it.

And then in a year from now, dotnet6 will be a release. But in between there, there's going to be other releases with cool little fun things, but we're not gonna care about those. So now I'm saying that, look, I'm gonna go to microservices. Every microservice is going to use dotnetcore3.one. And not until dotnet3.sorry.notuntil.net6.

Am I going to have to update all of these microservices and get them all out to production? So it's like along the way, there are just so many small and big decisions that you have to make. And they're so specific to what you're doing that it's it's hard to do. I I I yeah. I wish you could just pick up a book and say, like, model it to microservices.

Here's the formula. Follow this. And what you, I think, would see is, I need somebody that's done this before because there's a lot of questions that I have along the way. So it sounds like it's it's hard to maybe the first thing to do is to find a a use case. But maybe if if you if a company does decide to go down the route of using microservices, possibly, maybe if it if they're building a new module or something, a new piece of functionality, it might be good to make that into as a as a starting step to make that into a microservice instead of ripping apart their existing application.

Would you would you agree, you think? Starting small. Yes. Absolutely. Because the so the other side of this that we don't have to go really far with this, but this is also very, very relevant in my world talking to these large companies and these large developer teams, and that is a change in culture.

Right? Because going to this type of of architecture of microservices, this is gonna change the way you work. You have been doing monolithic waterfall kind of development, maybe some agile stuff in there and all that for years. And now we're gonna go from potentially a project based mentality within the entire company. Right?

You're gonna go from a project based thing where it's like, I make this thing that the business wants. I throw it over the wall to some other team. They support in production. I move on with life. Right?

To a product based thing where I own this thing for the life of it. Right? It is mine. And that's a that's a pretty big change. Right?

So microservices along the way, like, there's start small, understand what you're working with, get you and others around you comfortable in this new way of doing things because it's gonna be a journey, for sure. So is it is it really best to use the container type of architecture or or, you know, not? No. Yeah. Without a doubt.

If you're gonna go to microservices, you're gonna go to containers. And so this now we're gonna get into as as our journey of discussion of microservices goes here, now you're gonna get into your platform. And where where am I going to run this thing? Right? How am I going to do that?

And so from a developer's point of view, if we do this correctly, all the developer cares about is my application needs to run-in a container and expect these things to be fed to it, like my connection string or configuration values or something like that. I I'm gonna expect these things to be fed to my container. My application can run. It's pretty resilient in its container. And then where the container is running is really less of a thing.

Right? The Docker has kind of become the the kleenex of containers. Right? It's technically a tissue. But Yeah.

Docker has become the the Kleenex of, containers. Right? If you really wanna be, like, technical, you're gonna say it's an OCI compliant container. That is the spec that everybody follows for. That is a Docker container though.

It's an OCI compliant. So your Docker container, like your your Kleenex, where it runs, whether you're gonna go to whether you're gonna go to a Kubernetes cluster, or you're going to go to an EC 2 instance. You're gonna use like Elastic Beanstalk or something, or you're gonna go to Azure container service, or or other Azure type container services, things like that. Like, that doesn't matter to you because all of these things will run a Docker container. Right?

That's what I need to be worried about as a developer is, can I run-in a Docker container and hear the things that I need to be able to run correctly? So as you get into the platform side of things, you know, hopefully, you have other, hopefully, other, like, platform teams that are next to you or around your team to help you or really just aid you and say, here's what you have. Here's what we've chosen to work with. Get your app to a container and deploy it here. Right?

But there's kind of a line of separation there sometimes for it. Does that answer is that helping? Yeah. I I definitely that does help. I hope that helps our our audience as well.

You're also involved with a product called Steeltoe. How does that fit into microservices? Alright. Funny because that's kind of a natural progression there. So when you I do this for a living.

Awesome. Well, thank you. It's probably a good thing I don't. When so when you're moving into a container world, you are going to be hit with a couple of hard realities here. And I'm talking about as a developer and what my habits as a developer have been.

And what I'm really going for is debugging more than anything. Right? Getting to your logs. Traditionally, you've had IAS logs. You've had the event logs, probably written written to some file.

Your application may be writing some logs to a database, maybe logging logging to some, you know, local file on that VM, something like that. Like, that that was life for a long time. When you go to a container, when you go to a microservice running in a container that is then running on some platform, you don't get any of that. You don't get access to anything. IAS does not exist in your world.

I'm speaking Yeah. You can't really can you really attach, you know, like Visual Studio to debug under this? No. Actually, well, in some odd ways, you can. They're a bit unnatural, but but you can.

But, yeah, your your thinking is going the right direction there. Like, I I my life needs to change here, and the way I do things needs to change because as I write logs, I don't have a disk anymore. That disk may or may not be there when my instance, my container gets killed and spun up somewhere else. Right? And I don't know where it could be at any moment.

So I need to be able to aggregate my logs elsewhere if I'm gonna be able to debug things. Right? And it as I as my application runs, I I the performance of my application. So, like, this becomes a big deal. If you're running application on IAS on a web on a Windows Server, have you ever cared how much memory it actually takes to run that application?

Or, like, when you fill up all your variables, have you ever really cared how much it takes? Probably not. Or, you know, you've never really spent the time to do some hard math there for it, or how much CPU it's using or things like that. Like, the whatever. It's like Right.

Not not until it comes to the time. That's the only that's the only time I think about it. Yeah. You know, network latency and things like that, that's more of an issue, but still, like, you don't have to spend a lot of time on that. Now your currency here is memory when you go to a container.

Because when you spin up that container, one of the hard values you're going to have to provide is how much memory am I gonna give that container? And you can't go over it because you're gonna die if you go over it. The container is getting killed if you go over it. That's that's just the way life is. But the thing is, a single application does have a finite amount of memory that it needs.

But how do you figure that out? Right? How could you possibly, you know, figure out the what that real number is? That's an art to do by all means. But anyway, when you're going to this world of containers, these are the things that you need to start thinking about.

Right? And they're very different from possibly your traditional world that you've been doing. So Steeltoe. Steeltoe was was really born out of 2 needs. One is the Spring framework for Java developers, and more importantly, within the Spring framework called Spring Cloud.

There's some really cool things going on there. And I I I will be the first to admit that the Java world is eons ahead of us in the dot net world for containers, like, really a lot of years ahead of us for that. And the Linux operating system, of course, too, way ahead of us for this. So, you know, I'm not gonna fight that by any means. The Spring Framework, Spring Cloud, they've been doing this for a lot longer, and they're doing it pretty good.

They've learned a lot along the way. And so at the time at Pivotal, we said, well, we wanna do this in dot net. We wanna use some of these spring components in dot net. And, also, as we're containerizing our dot net applications, there's some boilerplate stuff going on here that every single microservice has to have because you're running in this container now. And so the the steel toe project was born out of that.

That was in, like, 2015, something like that. So the boilerplate stuff. Okay. My logs can no longer be written. They need to be streamed out, which in my world means console dot write.

That's streaming logs. You're gonna console dot write is going to standard out. Docker is going to see that, capture that, and forward that on to the logs of the container. And then the platform running that container is gonna see it and forward it on to your chosen log aggregator, Splunk or, you know, whatever you have to your to your Grafana database or, Prometheus database or or whatever out there. Right?

But the idea is your logs are being streamed out of your application and put somewhere safe because your container may or might not be there in the next minute. Health. Your application needs to be able to report its health somehow to the platform Because they need to kinda agree that things are running okay. Just saying that the process is running, like, okay, the container's running, and within it, my process is running. That's not enough.

Because it could very well be dead, right, and just a zombie process running there. So in fact, I need an endpoint in my API slash health. And that slash health, if it responds with an HTTP status of 200 and possibly some other deeper information in the in the payload of the response, that is truly healthy. Right? And to get to that 200, actually, a lot of decisions were made.

Is my database available? Is my API running? Are these things here? Are these things here? And that's the accumulation of that of that 200 response.

So just a couple there. Distributed tracing. Like, I need to see because now in a microservice world, I'm gonna be connecting to a lot of other services around me, a whole lot of them around me. So I need to see how healthy those connections are, and is there a bottleneck for that? So visually show me, here's where the request came in.

I connected to this. I connected to this. It connected to the database, and then the response came back. And it took this much time to go along the way there to do all those things. And, oh, look at that.

The this microservice is only responding you know, my overall response time was a second. One second response time for an API is not real good. So we need to find the bottleneck in there and and do that as distributed tracing. Things like that. Like, you're gonna use them in every single microservice out there.

And so Steel Toe, was born out of that as just all these packages. Pick and choose whatever you wanna do, add them into your dot net application, and you can have all of these things instantly. Very I mean, really, really, very little code. Because we know what it should look like. So why should you have to sit there and configure all this stuff and add it into every single microservice you have?

Just use add a using statement or something like that. Let it hook into everything and go with that. So that's the that's the boilerplate side of Steel Tail Pro project. Pretty much just, you know, install it, configure it, and then it just kinda does its thing? Yep.

And that and so that that kind of pattern was born out of the Spring way of doing things. Because spring like spring cloud applications, in Java, the idea is using attributes. So I should just be able to say I'm using a config server. I'm using a discovery server. I'm doing these things.

And then in my properties file, I'll tell you how to connect to these servers, but you should do the rest because you already know how to do all that stuff. I shouldn't tell you that. And so in Steeltoe, we're using attributes. Right? Annotations in Java, attributes and dot net.

Attributes. And dotnetcoreintroducedthe.a build pipeline or really middleware is the idea here. It's very powerful being able to use middleware independency injection and all that. And so let's tap into that. And in fact, you know what?

Give me 1 or 2 lines and tell me what you wanna do. Put your settings in app settings, Jason, and I'll do the rest for you. Because I know exactly what that looks like already. Yeah. That's the idea.

Do you see how sorry. I I'm I'm I'm gonna get on my soapbox for just a minute because I I I love, you know, helping others to just learn a different new technology and such. Are you guys seeing like, we talked about all the microservices and saying it within a domain. Right? And and creating this API, and then putting it in a container and going to the platform.

And then adding steel toe into it to help your application get better at running on the cloud. Right? Because debugging is that different. Do you see the big picture? Like, all this is working together.

Right? Oh, yeah. I'm definitely seeing the the big picture much much better now. Are you, why? Yeah.

Yeah. Definitely. I think it sounds like from what you were saying that steel toe well, with cloud so we've, with with containers, there's a bunch of fairly common problems that you have, such as logging and and things like that. And Steeltoe allows you to essentially solve those problems by putting it into into this by putting it into the start file of a normal application and calling it before you before it runs. Would that would that be true?

Like, if and you can do it just by a couple of lines. Yeah. And, actually so you're you're exactly correct. And they take it a little bit further and say, look. All of this needs to be open source because some wanna use packages in different ways than others, and some need to extend this stuff.

So Steeltoe is 100% and has always been open source project. There is there's nothing proprietary. The project was donated to the dotnetfoundation years ago, so it's it's not really, you know, owned by any one commercial entity or anything. So it is completely open source. It is for developers, by developers.

VMware employs one of the largest contributing teams to Steeltoe. Because VMware, as we talked before, as VMware gets into this application world and, you know, is going on its own journey for supporting applications as well as supports infrastructure, you know, they wanna be a part of that. They wanna help that out for it. So anyway, the CTO project is totally open source and totally, totally extensible. That's the big thing.

Like, you're not logged into those packages, you know, that's that's that's not gonna help anybody. If you're just locked into some 30 3rd party software that's gonna tell you this is the way you do it, and you're only gonna move when we move. It's just not the world we live in now. So you can do whatever you want. Does Steeltoe work on any platform?

So Steeltoe, as I said before, you know, if you got a project started in 2015 for dot net, you didn't know much about dot net Core at that time. You were doing dot net Framework. And in fact, you were doing because you're on dot net Framework, you're also looking at Windows Containers. Windows Containers at that time was rough, really rough. So that's where ciel 2 got started.

And in fact, in its its first major version and second major version, it supported dotnetframework applications on Windows, doing all these cool boilerplate things, as well as being able to interact with Spring Cloud components and all that. That was a pretty big feat doing all of that. Containerizing.netframework is is a whole story in itself. Now, you know, the dotnet world is moving to Linux, and so so has the cielto project. And so a little bit of 2 dot o embraced dot net core, but it's really meant for dot net framework.

3 dot o, which just got released about 2 weeks ago as of our reporting date here, that is solely .netcoreonlinix. Alright. So in the .networld, it's like you're you you're being pulled back and forth. Right? Where you're gonna run this thing, because, you know, you got decisions to make.

They're much like the monolith deal. But as far as Steeltoe is concerned, ultimately, your app's gonna be running a container. Steeltoe, quite frankly, doesn't care what the operating system is for. Just run it in a container and, you know, do the right thing. So 3 point o just came out.

What's kinda coming next down in the pipeline for steel? So one of the big things that was introduced in 3.0 is a component called steel toe messaging. So when we were talking about our microservices and we're we were talking about what kind of architectures am I choosing here, and that path is fraught with thorny roses and, you know, little elves that are gonna stab you, and it's just a rough path going down that monolith microservices thing. One of the decisions that you're gonna make is, am I gonna do something event based for it? Am I going to use a message bus?

So my UI is talking to these public public facing I'm doing quotes. Sorry. Public facing APIs. Right? That's that's kind of a straightforward thing.

But then those APIs, that's kind of my my edge surface of my application. Those APIs are gonna talk to a bunch of other services. Well, instead of them talking directly to those services, maybe they just put a message on a bus. And some other service is subscribed to that bus to watch for those messages. And when it sees something, then it does something else.

Right? But you're never really actually connected. 1 service talking to another service. There's a bus in between there. Okay.

This makes perfect sense. Right? In some in obviously, it's it gets a bit, complicated, but this is a very, very good application using message bus in such many instances. Okay. If that's the case, your application needs to be really good at talking to a message bus and getting the absolute most.

And when you get into that world, you start getting into custom headers. And you start getting into this is not over HTTP anymore. This is over, like, AMQP or or using RabbitMQ or something like that. There's a whole Rabbit protocol that happens there. You're beyond HTTP and that kind of stuff.

You gotta get really good at that stuff. We saw that. It's a bit early in the dot net world for talking about event kind of architecture and stuff because, you know, everybody's just getting the microservice thing and all that. But Steeltoe team's trying to stay ahead of that a little bit, and so they introduced messaging. So with steel toe messaging, and specifically they're talking about RabbitMQ right now, what we're talking about is you should be able to tell your application where your message bus lies, where your RabbitMQ server is.

Sorry. Messaging broker is. And what kind of information you want to serve up on that broker, and, optionally, some other fancy settings and things, and go. Right? Because using a message bus, as I've described, it can get involved.

Right? A lot of code that you could be writing to do all this, make it resilient, make it production ready, and you've never written one line of business logic along the way, and you've taken on a bunch of debt doing that. So the point the idea with steel toe messaging is, in fact, give us tell us where it is, where your messaging stuff is, what broker you're using, and mark a few of your methods with annotations as being a callback for Rabbit. Meaning, I want to be notified when this message is put on this bus, and when it is, tell me right here in this function. This is my callback for it.

It's literally one annotation to do that. Sorry. Attribute to that, backwards there. One attribute to do that, tell it about Rabbit, and go. This, like, seriously, when I saw this, when the team demoed this for me, and, you know, they handed me the the the code behind it, Woah.

Man, I got a whole lot with just a couple lines of code. It was mind blowing seeing all that. That was way cool. So that's kind of the next thing is getting into messaging. Then, the the messaging is in 3 dot o for Rabbit.

Obviously, they've opened up an entirely new set of doors for, you know, supporting other things like Kafka and other messaging, software. Also, the what they're going where they're going with this is Spring Cloud Dataflow. So the idea here is with Spring Cloud Dataflow this idea with Spring Cloud Dataflow is you build these data pipelines. I need to take some information in. I need to process it and do something with it, and then I need to put it somewhere else.

Right? This is a very common task to do that. Well, I don't wanna build the whole data pipeline to do all this stuff, and that's this project, Springfield, is is born out of that. I just wanna write little applications that process data that do these little jobs and things. But the message bus that's being used, everything else that's being done, I don't want anything to do with that.

And I want this data pipeline to run on massive amounts of data very, very fast, and I don't really wanna deal with all that. And so where they're going with this is they want to be able to to run Java and dot net applications side by side in the same data pipeline, one talking to another over this thing. But as you can imagine, to do that, to make them that compliant with one another, you gotta be really darn good at messaging and that sort of thing. So the messaging thing, quite honestly, is just like it's totally got my gears going because this is so cool what they've done. It's so easy to implement, but they've built it out production ready, and it's it's pretty awesome.

Very, very cool. Yeah. That definitely just sounds really interesting. Alright. So, David, is there anything we haven't asked about, either Steeltoe or microservices that, we should know?

Gosh. We've covered a lot. If we haven't Yeah. We have. We probably I I won't even get into it.

I mean Well, how how do we get started? Should we, talk about that? If we could just quickly? Yeah. Sure.

Yeah. Yeah. So the the the first step, interestingly enough, the first step is you can using the dotnet CLI or using Visual Studio, you can create a web API project. And it actually it starts you off in a pretty good place. And then from there, you can add in some Sealed packages.

Because when you create that web API project, that's actually gonna create a proper API for you with restful endpoints and and get you going pretty quickly. You can then go add in some steel toe stuff. Right? The the kind of Mhmm. I need health.

I need distributed tracing. I need health. I need some good logging. You know, that kind of stuff. You could add those packages into that application, and you're you're you're on your way.

And it just you know, you just keep adding and adding and adding databases and connections to other services and stuff like that from there. And should you compile it into a Docker container first? But to see it working? Actually so so yet another discussion point is what you would call parity between environments. Right?

It's part of the 12 factors. So parity between environment. Because now you're in this container cloud world, and you have all these services around your application. And to even run your application, these services have to be up and going. So how do I do this locally for that?

And so that's a whole another subject, doing local development and all that. But, actually, your application, I would say, you use your local Docker instance and something like Project Tye that Microsoft is working on. That's a really cool thing that they're doing to help you spin up all of these services, Docker Compose, you know, something like that, to spin up all these services, Microsoft SQL database, a, a message bus, whatever. Spin it up locally, and then run your application right out of Visual Studio like you normally do. And then, you know, from there, as you get into the container side of it, you're going to have to write a Docker file.

You know, you are gonna containerize and send it out. So there is gonna be a bit of a, you know, transition period there for it. But, really, locally, like, developing locally, I I like to work as much at a Visual Studio as I can to stay as close to the code I can before I really have to containerize my app and continue on down the line. Cool. Thank you.

Yep. Project Eye, is that t I e? Or t y e. T y e. Okay.

Yeah. Project Eye, it's it's a fairly new one, but one that I think is very becoming very popular in the dot net community. And it's all about being able to develop locally and keep as much parity with your local environment as your production environment. Because as that relationship degrades, right, that that if you're not keeping your local environment, your production environment as much on par as possible, as that degrades, your publishing to production, as your application goes to production becomes a bigger and bigger event. And that sucks.

Right? That's Saturday at 2 AM. Everybody's on hands. You know, it's those stupid things. It's like, that should not be a thing anymore.

And with microservices and all that, you should be able to deploy this thing because your testing is so good, because you're you know, everything is just so resilient around it. You should be able to do this in the middle of the afternoon is your, I guess, your goal with anything. So anyway, that yeah. That parity between environments, that's a big deal, and Project Thai really helps you out with that. Awesome.

Awesome. So, I think I'm gonna move on to PIX now. Why what's your pick for this week? Yeah. So learning a, like, second language, like, the hardest thing for me is often, like, trying to find someone to actually practice speaking and listening to that language.

So, I actually found an app. It's called Tandem, and it's it's just a, like, big community that allows you to find people that speak Chinese or Spanish or whatever you're learning and essentially just, you know, you can teach them English and just do a bit of a language exchange. So I've just been using that, and I found it pretty useful. So I thought that'd be my pick for for this week. Alright.

Cool. Okay. So my pick this week is gonna be a video game even though I don't often pick video games. It's Doom Eternal. It's really cool.

They just put out a demo on one of the the latest in video video cards. And, you know, I remember playing Doom back when it first came out, the original Doom game, and then Doom 2. So, you know, again, I'm revealing my age, and, you know, I'm not too too bad at doing that. I've done that so many times in the show. But, so if you like video games, you like shoot them up, 1st player type of thing, definitely check out Doom Eternal.

So, David, have you given some thought on what your pick should be for our listeners this week? I have. But can we, for a moment, can we visit the whole Doom thing? Because Yeah. Oh, yeah.

As I you know, when I when I made my move to to San Diego and I got my, I guess, my first legitimate programming job out there like, Doom was a big deal. Right? PC Doom. We built a map of our our office floor. It was a, you know, pretty big building, and we had the floor.

And, of course, we had some special things in the CEO's office. But we built a map of our of our floor, and, like, basically, every evening, it was on. Everybody shut off, you know, IDEs and all that stuff, and it was, like, full on hours of doom. That's awesome. Very cool.

So what did you come up with for a pick? So my pick, unfortunately, I just don't have as expanded its horizons as you guys because I I just love technology, is actually identity server. I've been spending, just in my free time, a lot of time learning about identity server and the the differences of authentication versus authorization and, like, just what that relationship is and breaking them apart. In a container world, in an API world, API gateways, like, this is a this is a big deal. And it really got my attention the past few days.

Learning it, getting into it, just, you know, making it really cool. Very cool. So you you were talking about jets earlier. I thought maybe you might have wanna pick the the new Microsoft Flight Simulator. Have you tried that out?

So, dude, I I I haven't had a video game on my, on my PC in a really long time. I'm just boring like that. But the the actually, I've I've seen, just in all the blogs and everything that I follow, I've seen a lot of screenshots and, you know, headlines and things like that about what simulator is. And, man, it really got my attention because that looks pretty darn cool being able to go up and fly. You know, we'd, like, full on fly at that resolution, a Cessna or something like that.

Man, that that might be my pick in just a couple weeks. Cool. Awesome. Yeah. I I I haven't tried it yet, but it definitely, you know, just it looks so cool.

You know, being start wherever you want, fly everyone with all the detail they've got in there compared to how it originally came out with just, you know, basically black and white lines on a screen. So If you could put, like which I I don't you may be able to do this. I don't know. But if you could stick, like, an f 14 or an f 15, you know, or a Raptor or something like that and fly that around LAX, that'd be pretty awesome too. Alright.

Cool. So So if people have questions about Steeltoe or microservices, is there some way they can reach out and get in touch with you? Sure. I'm definitely on, most platforms. My personal site is, dieruff, dot net.

That's d I e On GitHub, it's dieruff. And then, I'm I really kind of am on their way too much. On Twitter, my handle is dieruff david. So any one of those is all gonna lead you to the right place. Awesome.

Awesome. And if our listeners want to reach out and get closer to the show, give us suggestions, we'd love to hear from you. They can reach out to me on Twitter. I am at.netsuperhero. Nice.

Alright. Thanks, David, for your time today. I I think it was a really good help for a lot of people that might have had some confusion about microservices and how to set them up and maybe even how to to move from a monolith to a microservice. So we really appreciate it. Thank y, sean.

Thank you very much for the time. I really appreciate the opportunity. I learned a lot. So thank you. Awesome.

Alright. Great. And we'll catch everybody else on the next episode of adventuresin.net.