The Modern .NET Show
A blurry image of source code, too blurry to read, take the place of the background. Layered over that are the headshot of Josh Garverick and a purple robot holding a microphone; these are on either side of the centre of the image. Above both is the heading 'THE MODERN .NET SHOW' in bold, white text.

S06E03 - From Self-Taught to MVP: Navigating the Event-Driven World with Josh Garverick

Embedded Player

S06E03 - From Self-Taught to MVP: Navigating the Event-Driven World with Josh Garverick
The .NET Core Podcast

S06E03 - From Self-Taught to MVP: Navigating the Event-Driven World with Josh Garverick

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

In the world of software development, staying up to date with the latest trends and technologies is key to success. This thirst for knowledge and drive to constantly improve is something that many developers can relate to. In this episode of The Modern .NET Show, Jamie Taylor and Josh Garverick discuss their experiences and share valuable insights into the industry.

Josh Garverick, who has been in the development industry for about 17 years, started his journey at a young age. He was self-taught, starting with Basic and later moving on to VB .NET and C#. Throughout his career, he has worked on a wide variety of projects, ranging from small ones to setting up cloud infrastructure for multi-region applications. He has also delved into the world of DevOps, working with different types of DevOps systems and Azure.

In the episode, Josh discusses the increasing popularity of event-driven architectures and the importance of domain-driven design. Event-driven architectures provide immediate access to information, enabling quick decision-making. Domain-driven design, on the other hand, helps compartmentalize different aspects of an application and allows for a more relevant approach to solving business problems.

The conversation also highlights the shift in focus within the software development industry. While technical mastery is still important, the emphasis is now on providing value and adding value to the organization. Breaking down an application into domains not only helps determine where each part fits in the overall feature set but also facilitates troubleshooting and debugging. It allows teams to work autonomously and use different technologies as long as they can read and process the events.

The episode also touches on the importance of testing, regardless of the technology choices made by development teams. The book discussed in the podcast aims to provide practical application and guidance for developers at all levels, from newcomers to microservices and event-driven design to senior developers looking to modernize legacy systems. It emphasizes the benefits of testing in an isolated and integrated manner and highlights the value of understanding requirements before deciding on technology choices.

Episode Transcription

Welcome to The Modern .NET Show! Formerly known as The .NET Core Podcast, we are the go-to podcast for all .NET developers worldwide and I am your host Jamie “GaProgMan” Taylor.

In this episode, I spoke with Josh Garverick about event-driven and domain-driven design, and his recently published book Implementing Event-Driven Microservices Architecture in .NET 7. When talking about the book, he had this to say about it’s target audience:

Absolutely. And one of the aims, I think for at least this book was to make sure that it’s kind of applicable across a lot of different audiences, not just the folks coming in super green and just looking at it like, I’ve never seen this stuff before.

There are some disclaimers in the beginning of the book, obviously saying, "you should probably have at least a baseline understanding of things like domain-driven design containerization and things like that," but we’ll link out to resources to get yourself up to speed. So even if you don’t have any background in that stuff, there’s at least a place for you to go out and get that information and then come back and then start going through that journey.

- Josh Garverick

Not only is his book designed for people, regardless of where they are on their journey with .NET, but, as we’ll find out in the episode, it’s also filled with pragmatic lessons that developers can apply to any application that they’re working on.

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : So Josh, as always with all of the guests and especially today, thank you ever so much for taking some time to speak with me today to be on the show. I know we’re ever gonna have a great time, so let’s get this party started.

Josh : Absolutely, let’s do it.

Jamie : Excellent. So, welcome to the show. This episode will be going out after the great rebrand of 2023. For those of you haven’t heard the show before, we were called the .NET Core Podcast, but now we’re going to be called the Modern .NET Core Podcast.

Josh : Now.

Jamie : Wait. The modern .NET show. That’s what we are. So, yeah, we’re going excellent. Way ahead of time. Yeah, right? It’s loads of fun.

So Josh, I was wondering, would you be able to give the listeners a bit of an elevator pitch about you and maybe a little bit of history of you in development? Have you been in development for a minute or for a couple of years? What’s going on with you?

Josh : Okay, so unofficially, I’ve been developing since I was in the fifth grade. So I started with Computer Labs and running Basic, making the screen turn different colors and printing text over and over and over again. And that was pretty exciting for, you know, the mid 80s.

Officially, I’ve been in the industry for about 17 years. I was actually professionally in Human Resources for eight years prior to cutting over to IT, software development, and all that good stuff. I’m completely self taught, so I spent a lot of time, especially during my tenure in human Resources, basically teaching myself not only how to program, but also how to build systems and things like that so that I could get a better understanding of how everything works. When .NET came out in 2003, I actually asked for a copy of VB .NET for my birthday, if that gives you any indication of how much of a nerd I am. I was like, “yeah, this is great."

And somewhere along the way, I want to say it was about two years in to my “official” programming career. We got some training on site at the place that I was working at at the time for C#. And at first I’m like, “I don’t know if I like this,” because I always had this aversion to Java, right? For some reason, when I was teaching myself that, it was like just “eww” and no shade to anybody who develops in Java, right? It was just my personal preference. Same with C++. I just couldn’t wrap my mind around pointers and everything else. Like, “why do I have to manage memory? This is silly,” I get it now, but at the time I’m like, this is a waste of my time.

Anyway, we got some training in C#, and the more I thought about it, I’m like, this actually makes a lot more sense to me. So I started to carry that forward and I’ve been in the C# camp ever since. I’ve been on everything from super small projects to setting up cloud infrastructure for multi-region applications that execute endpoints all across the globe. So I’ve kind of gone from not just software but also the DevOps aspect of things, working with a bunch of different types of DevOps systems and going into Azure and following the whole cloud infrastructure and architecture route. So I’ve kind of rounded out a lot of that stuff. I mean, there’s still areas that I would love to get into that I just haven’t had a chance to do yet. But that’s kind of my journey in a very condensed format.

Jamie : Cool. I do think that well, okay, how do I put it? Because I went to university, college, that kind of thing, did CompSci degree and I think that it’s not as necessary these days because companies, they’re asking for computer scientists but what they want is software engineers. And I think in my opinion there’s a big difference between the two: a computer scientist, because like computer science itself is the topic is more like HOW a computer works, not how to get it to work. Right? It would be like asking a PhD in fluid dynamics to fix the engine in your car, right? They can totally do it because they’ve had all of the training required to understand how the fluid is moving through and past the pistons and all that kind of stuff. But they are like operating at a whole different level.

And I’m not trying to throw shade at all on anyone who hasn’t gone down the CompSci route. I just think that for the, “I am building a web app and it is using HTML to show something on the browser and it’s putting in an HTTP request to talk to the back end and it’s doing some stuff there,” like perhaps a CompSci degree is not the way to go because we’ve talked about this on tablet spaces. I’m sure one school’s syllabus for CompSci will be different to a different school’s syllabus for CompSci. And so how in the heck are you going to ratify that? Because one school will be teaching Java, another school will be teaching C++, another school will be teaching .NET and none of them will teach DevOps, right? And so no one gets used to using Docker and things like that in academia, perhaps. Anyway, I’m going to climb down off my soap box.

I love the idea that you’ve taken that thirst for knowledge, that drive, as you said earlier on that geeky nerdy side of yourself and gone, “you know what, I’m going to do this as a career. I’m going to see what I can do.” I had never at any point in my life thought of, “why don’t I ask for something? Why don’t I ask for my birthday as something like an IDE or like a debugger or something.” That’s brilliant.

Maybe not Visual Studio because that’s super expensive, right?

Josh : That’s the funny thing is when VB .NET came out, I wouldn’t say terribly expensive, it’s not like I was going out and asking for the Enterprise version of Visual Studio or anything like that because at the time I think that was like around two grand or something. So it was much more affordable, shall we say. But it was one of those things, it was like, “I have to have this.”

Jamie : I like, it okay with all of that. At a point you became one of them, Microsoft MVPs that everyone tells you to hang out with, right? That must have been pretty cool to have gotten to that because when I got MVP, I was like, “what in the heck? You’ve let your standards slip. That’s what happened.”

Josh : Man, they’ll let anybody in here.

Jamie : Absolutely.

Josh : This is actually an interesting I think it’s an interesting story, hopefully others will too.

But in 2014 I started looking at a lot of the stuff that was on the Microsoft Learning website which has gone through several rebrands throughout the years and as have I’m sorry, a lot of products and everything else. But I started going through and looking at some of the training courses on specifically TFS because I was getting to a point where I was kind of bored using the CI/CD tools that I had, and I wanted to start looking at things that would help promote me as being more cross knowledgeable on things. So I started to look for courses on TFS, on how to administer it and actually set up an instance of it and stuff like that.

So I go on there and there were a bunch of courses on there from Anthony Borton and Steve Borg who were, they were like the face of TFS as far as I was concerned because that’s what I was seeing on the learning website. And I went through, I watched the videos and I’m like, “these guys seem pretty cool and I really appreciate the knowledge that they’re dropping. So maybe what I’ll do is reach out and just say hey, thanks. Because who knows, maybe they’ll write back or something.” Totally not expecting to actually get a response. So I email Steve, I’m like, “hey, I just wanted to say thank you for putting these videos together. I found them really helpful and your presentation style along with Anthony really fantastic."

And in between the time I watched the videos and sent that email I was also kind of poking around online and I saw that Steve was in this group called the ALM Rangers and I’m like, “what’s that?” So I start looking. It’s a group basically sponsored by Microsoft but made up of full time employees as well as outside folks who kind of work on different projects that are gap fillers for things that are not out there in the community today. And I’m like, “that’s really cool.” So in my email I say, “hey, steve, I also saw that you’re a member of the ALM Rangers. That seems like a pretty interesting group of folks. What’s that all about?” So what does Steve do?

Now, keep in mind I’ve never talked to Steve, I’ve never seen him. He has no idea who I am. He replies within an hour or two. So first of all I’m like, “what?!” Second, he copies Willie Peter Shabb, who was at the time the program manager for the Rangers group inside Microsoft, and he’s like, “oh yeah, this is Peter, he runs the ALm Rangers group. It’s a great group of folks, external and internal to Microsoft who work on a bunch of different gap fillers.” And he emails back and he’s like, “Steve, are you recommending Josh for the program?” And without missing a beat he’s like, oh yeah, Josh would make a great, fantastic ALM Ranger. Rattles off all the stuff. I’m like, what is happening right now?

This is the weirdest thing. So I get introduced formally, start going through, obviously there’s the NDAs that you have to sign and all that good stuff. That’s where I met a lot of folks like Donovan Brown and Abel Wang and Rich Hunhausen, Anisha Pandoria who’s at GitHub now kind of the principal PM over there. So like Martin Woodward, Greg Duncan, Paul Haack, there was just a ton of people that I met and my first real project was working on the Alpha for what is now Azure Pipelines.

Jamie : Oh cool.

Josh : Yeah. So like Chris Patterson and all those guys, I talked with them extensively and did a lot of really weird stuff just to see if I could do it, like off label edge case type of testing. And I don’t know, it was maybe a year in and Willie emails me one day and says, “hey, by the way, I just wanted to let you know that I submitted a nomination for you for the MVP program.” I’m like, “what’s that?” He explains it and all that stuff and I’m like, “why would you do that?” There’s no reason why I’m having fun and I’m poking around in this stuff.

And at the time I wasn’t really privy to the value it was providing to other teams, right? I mean, I didn’t know about the product group interactions and kind of that how that feedback gets translated into actionable items. And he’s like,, “just be aware that it takes some time. There’s some things ironing out for the award periods and everything.” And this was when they were doing them quarterly before they went to an annual review cycle. And he’s like, “you’ll find out and all that stuff.” And of course me being the twelve year old that I am, I’m like, “what am I going to find out? What am I going to find out? Are we there yet?"

And finally it comes through and I ended up getting in and I’m like, “how in the absolute hell did this happen.” I was baffled. I’m like, “this is so weird,” and I’ve been in the program ever since. Just continue to meet great folks such as yourself.

Jamie : Thank you very much.

Josh : Yes, of course. And it’s been a great ride. Just being able to have that level of input on products that go out to millions of users. I mean, to me that just blows my mind every time I have the opportunity to do it. And it’s a huge privilege.

Jamie : It really is. I’ve only been in the program for a little while, but being able to sort of feedback. Obviously we’ve got to be careful not to avoid any NDAs, but yeah, for people who don’t know big part of the MVP Program is being able to feedback to the developers and the technologists at Microsoft about what they are doing and how they’re doing it and show we may use it in the real world which is pretty cool.

So let’s have a chat about your most recent book. With Pact Publishing, which I have the title in front of me and I have the book in front of me, actually Implementing event-driven Microservices Architecture in .NET 7.

Josh : Yes, a mouthful of a title for sure.

Jamie : It’s obviously a cookbook about Norwegian pilchards, obviously. Right from the title, of course.

Josh : Why would you expect anything else?

Jamie : Absolutely. So before we do talk about the book, I just want to make very clear to everyone who’s listening full disclosure, I was one of the technical reviewers on the book, so as much as I like to represent the audience when interviewing folks, some of my questions will be a little bit leading. So folks have already read it and you should too. So go get the book.

But Josh, why should they go get the book and what’s that about?

Josh : So a couple of reasons as I stammer through trying to form a complete sentence here.

One is that event-driven systems, event-driven architectures aren’t going anywhere anytime soon. If anything, it’s increasing in scope as far as popularity goes, but also with the ability to just perform things at an outrageous scale. The world is becoming much more saturated with data, much more near time and real time, as far as expectations are concerned. People expect to see things now. They don’t want to wait for things. And even with the notion of data patterns, like eventual consistency, I still think that people are getting to the point where they’re highly impatient and they just want to see things now. And doesn’t matter if there’s one data source or 250,000 data sources. Doesn’t matter. “I just want to see everything and I want to see it now because I need to make a decision on this information now. I don’t need to make it in ten minutes or in 10 hours.” So that’s kind of like one aspect of it is like it’s not going anywhere. It’s a good thing to have in your tool belt.

The other thing, and this is kind of more I won’t say philosophical, but it’s kind of in that vein, it’s more about solving problems and how you solve problems and how you think about problems. One of the really interesting things that I found over the past few years as I’ve gotten more experience with it is domain-driven design really helps me to compartmentalize the different aspects of an application and obviously the different domains. But it kind of takes your general notion of how you used to develop software, at least for me, and break it apart, but put it back together in a way that seems to make more relevant sense to someone who’s in a business context.

And that’s one of the areas that I think, whether it’s because I taught myself how to do this stuff, or whether it’s because that’s how the industry was for a very long time while I was in it. In the 2000s stuff, there was more of a focus on just be as technical as you possibly can. If you can write your own something like an ORM do that, just become a master of your engineering domain. And now there’s more of a focus on how are you providing value, how are you adding value, how is the business going to leverage what you’re doing and actually turn it around and make it something that’s beneficial to the organization?

And a great way to do that is when you’re building applications, think about it in that perspective. What are the major areas of the application that need to be in existence in order for it to be effective and to provide value? And I mean, that also ties into the DevOps mantra as well, just continuously delivering value to end users of the application. And I think that taking a lot of the topics in the book, it helps you to not only formulate your approach on how you would like to split your domains up or how you would like to go about testing them individually and isolating things in that perspective to deploying things at scale. I mean, all of those things will come in handy as an engineer at some point in your career. Now, maybe they’re not all going to be at the same time on the same project, but they might be. And that’s kind of how I tried to approach this project: was keeping that aspect in mind and trying to make something that was useful for folks outside of just the technology that was being used.

Jamie : Sure. And I think that you talked a little bit about domain-driven design there. I think it’s really important that folks, if they haven’t done any kind of domain-driven design, to really sort of think about, even if it’s a pet project, just think about something that you could do, break into a DDD style design for building the app. Because like you said, you’ll notice that there’s a slightly different way of thinking about it, and I feel like it fits more with the sort of what Agile, and Scrum, and all the different methodologies for managing a project are aiming for as well.

I feel like it’s one of the few, in my opinion, one of the few design principles ideologies that fits really well with what management want. Because like you said, you’re looking at what is the part of the app that brings the most value and how do I bring the most value to the company, right? Because I’ve said it hundreds of times before, your boss doesn’t care how you did it, just that you did it. They don’t care how it works when they push the button and it gives them money. They just care that when they push the button, it gives them money. And there could be a whole bunch of stuff behind it that’s really well engineered. Or it could just be that that button is doing the core part of the business, because that’s the bit that really matters when you’ve got, say, a six month, 18 month, 24 month project, you have a hard and fast deadline that you cannot change and you have an infinite feature set. And breaking things down domains helps you to figure out where in this feature set all of your app bits go, right?

Josh : Exactly.

And it also helps you think through the interactions, right? So not just the events, but the event handlers and where those would be in the overall design of your application in a kind of off label way.

I feel like it also helps you think through the ramifications or the impacts of things that you’re writing into your program or application from the perspective of those events and those event handlers, because it helps almost tie it all together for you. So if you’re a newer person who’s coming into the project, you should be able to look at that overall domain design, look at how the events and the event handlers are all mapped. And it should help you actually be able to not only traverse the course of a specific command, but also troubleshoot the application, right?

I mean, to me, that was one of my biggest struggles when I was a junior to mid level engineer, was like, “how in the heck am I supposed to debug this massive application that spans all these different services and all these different things?” Knowing that as a general pattern, as like a meta pattern, will help you trace through things easier and figure out where stuff is and figure out why things are happening the way they’re happening. And it’s almost like self troubleshooting in a way, if you’re following the model. But that’s why I think it’s so important for folks to look at things from that perspective.

A Request To You All

If you’re enjoying this show, would you mind sharing it with a colleague? Check your podcatcher for a link to show notes, which has an embedded player within it and a transcription and all that stuff, and share that link with them. I’d really appreciate it if you could indeed share the show.

But if you’d like other ways to support it, you could:

I would love it if you would share the show with a friend or colleague or leave a rating or review. The other options are completely up to you, and are not required at all to continue enjoying the show.

Anyway, let’s get back to it.

Jamie : 100%. And if you have broken your app into separate domains and maybe you using microservices, maybe using a distributed policy, it really doesn’t matter as long as you are doing event-driven stuff and passing messages around on an event bus or a message bus or something, or something like that. It then releases you from the technology required to build those individual pieces. Right. So like you and I, Josh, we’re dot .NET guys, so we’re probably going to build it in .NET, but somebody could take a chunk of that domain and build it in Java and then you go make them stand in a corner.

But jokes aside, it really doesn’t matter at that point. As long as the chunk that someone is building knows how to read an event from the event bus, the event service, the whatever you’re using to pass those events around with doesn’t matter, right? You can just pass those events around and all of the different parts of the app can just talk to each other using JSON, using HTTP, using gRPC, using whatever it is that you’re using.

Josh : That’s absolutely right. Yeah. It just makes it simpler for things to snap in.

And it also frees, ultimately, it frees individual teams up who maybe for example, you may have an organization that’s got 14 to 16 development teams all working on different aspects of one platform or one application. It makes it easier for those teams to operate more autonomously, not only from the perspective of how they’re putting together the actual entities and events and messages and everything else, but also what they’re using from a technological perspective. There are some things that obviously you kind of have to play by the same rules, but there are also things that you can go completely into left field on, like you said, using Java or using Python or using PowerShell. It doesn’t matter at that point. What matters is the integrity of the actual event itself.

Jamie : Absolutely.

And then it also then doesn’t really matter because it doesn’t matter. I’m worried about using the phrase “doesn’t matter,” but it doesn’t matter about the technology choices you or the teams use. It then doesn’t matter about how the tests are written as long as they exist. Right. Like you said earlier on, you’re then able to test things in an isolated manner or in an integrated manner. You can say you have like 15 individual lumps of functionality. It could be services, microservices, whatever, and you can say, “right, I’m going to test all of them individually and then I’m going to test a path that I know of that goes through services one, two, three, calls, service four, but doesn’t matter. And I can actually test that they are doing what they’re supposed to be doing. And I can have better confidence in the fact that all of these now work together in a way that they should."

I really like that because part of my history with development is I’m from back in the day when everything was tightly coupled and new wasn’t seen as glue, it was just seen as the way you do things.

Josh : Yes, exactly.

Jamie : How are you going to test it? How are you going to test it? You’re not that’s show. But I feel like perhaps this event-driven and microservices are a great way to sort of separate everything out so you can test things a little better.

Josh : Absolutely.

And one of the aims, I think for at least this book was to make sure that it’s kind of applicable across a lot of different audiences, not just the folks coming in super green and just looking at it like, “I’ve never seen this stuff before.” There are some disclaimers in the beginning of the book, obviously saying, “you should probably have at least a baseline understanding of things like domain-driven design containerization and things like that, but we’ll link out to resources to get yourself up to speed.” So even if you don’t have any background in that stuff, there’s at least a place for you to go out and get that information and then come back and then start going through that journey.

I think that folks that are senior in career, there’s stuff in there for them as well. It could be anything from developing greenfield in domain-driven design and using event-driven architectures, or it could be modernizing an application, which is a lot of what I do, at least have done over the past couple of years is really taking older, legacy vintage systems, if you will, and getting them into a spot where they can really leverage the benefits of being a cloud first application.

So my hope is that the book has stuff for everyone to kind of glean information from and learn and hopefully make the projects that they’re working on a bit better and just share the love of all around.

Jamie : Sure.

I feel like it makes sense. Okay, so let’s say I never build anything that uses microservices or event-driven design. Having a practical application that’s built up across 200, 300 pages, I can actually see where those divisions are made, which then allows me to be more pragmatic, I suppose, with my application design. Even if I never use event-driven architecture or microservices, I can actually say, “right, okay, I think I can see a domain boundary coming up. Oh, cool, there it is. There’s a context boundary.” And then will I don’t have to go 100% in do hexagonal architecture and all this kind of stuff, but I can actually say, “right, okay, this is the domain boundary. I’d better write some kind of DTO here, or I’d better put up some kind of wall here so that I can test anything that this is making assumptions about.”

Josh : Absolutely right. It also helps you to kind of pivot and think through things like failure scenarios too.

One of the Soap boxes, and I’ve got several that I travel with, one of them that I tend to stand on from time to time is around fault-driven development, which I don’t know if I coined that or someone else did. But I actually have a talk that I have done on that. It’s basically pivoting the way that you think about developing things and look at it from the perspective of, “what happens if this fails. What happens if what this runs on fails? What happens if what this runs on fails at the point where it’s being hosted and an entire data center goes down?” That type of stuff. So kind of anticipating expecting things to be broken and how do you gracefully not only recover from that, but also communicate that to the end user in a way that’s not a yellow screen of death or some sort of disgusting stack trace that shouldn’t be leaking out in a production any ways?

Jamie : Sure.

Josh : So a lot of kind of how I look at it is being able to split those domains up and actually individually adjust them for different types of failure scenarios is also extraordinarily helpful. It can lead to things like selective disaster recovery options for certain things, selective business continuity patterns for certain things. Like, the example in the book was, “what if the network connection from one of the subway stations is cut for some reason? Like there’s an outage there’s, somebody hits a cable, something.” Doesn’t really matter what the cause of that is. But how would you still continue to collect that turnstile data? Because you still need it, right?

It’s okay if it’s eventually consistent, but you don’t want it to just not exist. It’s not like a UDP thing where it’s a scatter shot and whatever gets there, gets there. You still need that for maintenance records and everything else. So the idea of having a fallback unit to where those transactions can still be run in the event that it can’t communicate with the primary service, that’s the type of stuff that you get to think about. Or how do you individually scale one service based on fluctuating traffic patterns? And how do you make that more resilient based on traffic patterns or based on usage or any number of metrics that you might be tracking?

That’s another aspect of that. Solving problems in a slightly different way. Kind of shifting your perspective on it and looking at it from a different angle and saying, “well, what if this happens?” And that’s honestly why I threw a chapter in there about Chaos Studio, was to be able to give folks a tangible way to go through and say, “okay, well, go break a bunch of stuff, see what happens,” and then start including that. Start including that in your pipeline as well, so that you have existing established use cases for all this stuff and it just helps to further bolster your application.

Jamie : Oh, absolutely. I mean, chaos engineering wouldn’t exist if it wasn’t required, right?

Josh : Absolutely.

Jamie : Right. Yeah, absolutely. So you mentioned a little earlier on about how the book is it requires a little bit of knowledge around show domain-driven design works and. It requires a little bit of at least a passing understanding of .NET too. Yes, but is it for complete novices? Like, am I going to learn everything I need to know about event-driven microservices and .NET 7. Is it for done experts? Is it for people who are like, “I have this monolith, Josh. Let me tell you about my monolith, right? It’s the worst thing ever. It’s Windows and it’s a million, billion squillion lines of code, and it uses 100 terabytes of RAM just to start the thing. And I want to break it into microservices.” Is that the person that the book is aimed at?

Josh : I think the answer to that question is, “yes, all the above!"

For complete novices, someone who doesn’t know anything about .NET or anything else. I would shy away from that a touch only because you should have at least a solid understanding of .NET to be able to go through and pick the stuff up. Because that assumption is baked in to the premise of the book, that you at least understand .NET and like you said, you have a passing understanding of things like containerization and at least understand what domain-driven design is kind of intended to do and kind of how it works at a very high level.

Do I think that folks who are newer to domain-driven design would find this useful? Absolutely. But I would be reticent to give it to somebody who’s, like, who just started day one in their job as a program refresh out of school that may not have that background, but I think every other audience sector is perfectly able to pick this up and use it.

Jamie : Okay, cool. All right.

So without giving away any of the secret sauce of the book, we’ve talked a little bit about how it utilizes domain-driven design to be able to separate a bunch of the functionality of an app into microservices and use event-driven architectures to pass events through the system rather than passing one lump of state and calling one microservice waiting on the response of another. Because I feel like my personal opinion when people do that, they’re just making a distributed monolith. If I have microservice A, which puts in a direct request to microservice B and sits and waits for microservice B to respond, then you’re going to be waiting a long time and you’ve done it wrong. But that’s my own personal opinion.

But what are some of your say let’s say you’ve got some top tips, right? Let’s say I am going to be designing a brand new, I’m working Greenfield, I’m designing a new application. Where do I start if I want to do microservices right? Because I feel like with microservices, there’s a rite of passage. You’ve got to get it wrong before you get it right. Right? What’s some of your top tips for getting started with microservices, event-driven design, domain-driven design, all that kind of stuff?

Josh : So there are a couple of things, and a lot of them are actually not necessarily deeply, technically related. And I mean that from the perspective of technology, not like, “technically they’re not related.” Totally different.

So the first thing is understand your requirements. That’s probably one of the biggest things is sometimes you get into a newer technology or new to you and you’re like, “I can use this to solve everything.” Which could be true, but it could also cause you a lot of pain, a lot of discomfort, and ultimately not serve any use to anyone other than yourself, right? So think about the requirements of the application. Does it warrant being split up into 150 different units of work that are scaled out across a bunch of different things? If you’re building a WordPress site, you’re not going to build that in microservices; much the same as you wouldn’t use a single server web service for consuming service calls from 15 different geopolitical regions. You know what I mean? There’s differing things that you have to look at and take into account when you’re going through your design phase to really determine if it’s the right approach to begin with.

The second thing, and this kind of goes back to my comment about how I think domain-driven design is a really essential building block in helping to solve problems. I think you can still use domain modelling regardless of the type of application that you’re building, just to understand how everything works together and how to better solve the problems that the business is facing and better view what’s going on in a system and better understand why things are happening or are not happening based on the way that those things interact.

The data is another big thing. So understand how the data is not only stored, but modelled. And don’t let data duplication make you shy away from duplicating data. Meaning when you’re looking at information that’s relevant to a specific domain, it could be pieces of information that are replicated or duplicated across a couple of different domains outside of the one you’re in. And that’s okay because at the end of the day, you need a way to stitch all that stuff together. Don’t get hung up on, “oh, well, it’s duplicating the turnstile ID for this in three different spots, and that’s going to take up tons of room.” Yeah. 20, 30 years ago. Would you have to worry about that? Absolutely. Not so much today. Storing an int today is not a big deal. Now, if you were storing a two to three gig Blob in a database, first of all, shame on you. Second, that’s a valid concern, right?

I wouldn’t worry so much about storing very small bits of information in multiple spots. Because when you go back into your reporting side, your read side, you’re going to pull all that stuff together in a way that makes sense and pull it from the appropriate places. And it doesn’t matter if it’s duplicated, it matters that data is being reported back correctly. So those are a couple of things to keep in mind when you’re doing that.

Equally as important is the mechanism that you use to orchestrate the entire system. So there are ways to use Event Grids and Event Hubs to absorb events and actually allow those to go to topics. And then using pub/sub and other methods, you can get those moved to different places automatically just by virtue of them showing up in a topic. You can use, like you mentioned, an Event Bus, or you could use things like RabbitMQ to be able to allow you to take advantage of AMQP messaging patterns. There’s a ton of different ways that you can do it. None of them are wrong. They’re just different. So taking that approach and really thinking through, “how is this going to play out in whatever world this lives in?” whether that’s in Azure, whether that’s in AWS, whether that’s in GCP, or half on prem, it doesn’t really matter. What matters is how is this going to live, breathe, interact with other parts of the system? And does it make sense to use one type of orchestration over another?

A lot of folks are really big on Kubernetes, me being one of them. Is it the right solution for every problem? No, not even close. But in certain circumstances where you’re working with a lot of independent moving parts that need to scale independently and do a lot of other things, it often makes sense to use that. Because as a platform, Kubernetes allows you that granular control over individual objects, but also a larger orchestration piece that is tough to do without some help.

Jamie : Sure.

I think I would love to personally echo your point about I’m going to change your words slightly about “don’t repeat yourself.” I feel like a lot of people apply don’t repeat yourself, but don’t really understand the message it’s meant to put across. And my version of the message that it’s meant to put across is, “don’t repeat yourself unless you have to.” So like you were talking there about, “but if we duplicate the data, then it will appear in two places.” Well, maybe it needs to appear in two places, right? Because maybe it’s being consumed differently, or maybe it’s being consumed in a different format, right? And that’s a super important thing to really get your head around is that yes, a piece of data, a class, A type, even a whole service can legitimately exist in two different places as long as there is a reason for it. And that reason is not, “I copy pasted it, and that’ll do.” If it needs to exist in two places, then do it.

And I think you’re absolutely right about Kubernetes. And services like that orchestration and looking after your containers and stuff like that is super important. But like you said, if you’re building a website using WordPress or using Hugo or something like that, perhaps containers and kubernetes is maybe not the way to go. But if you’re building something that’s distributed and has a million and one different APIs, and one of those APIs will get hammered. Like, let’s say it’s voting day and one of your APIs tracks how people are voting; you likely want that API to be able to be able to take a million people hitting it at the same time, maybe even a billion. I don’t know, right? You want to know that it will actually work and so that makes sense to distribute that and to have fail safes.

Yeah, I like that because I feel like sometimes, and you hinted at this earlier on, sometimes us developers get really excited about different types of technology and how we can apply them. And I feel like a lot of us will go, “oh my goodness, this would be awesome if I finally an excuse to use Kubernetes or finally an excuse to use X technology or Y technology.” And it’s like, “well, I mean, you could, but will you get anything out of it,” right? Like you said right at the beginning, what value does it bring?

Josh : Exactly? I kind of look at it. A great example of that, at least one that I personally felt the burn of was LiNQ to SQL queries. The old n+1.

Jamie : Yeah.

Josh : Right. So the adverse performance effects of using Nested for loops to go through and pull information, which seems intuitive when you’re doing it, but when you actually go to put it into practice in a productionalised setting, it can absolutely tank your application. And there are ways of adjusting that so that you don’t experience that type of performance hit. But you .NET excited about the fact that you can actually use a query language to join objects in a way that you wouldn’t have been able to do before without tons of SQL and tons of crazy joins and things like that.

And that’s just like one example. Obviously there are plenty of others, but it’s that whole, “know to your audience and know the purpose of what it is that you’re trying to accomplish.”

Jamie : Absolutely. And I think that goes into the engineering side of what we do, right? As exciting as it is to build something from the ground up and to be able to apply a bunch of different technologies, we need to be pragmatic and we need to be engineers and we need to think, “what is it that I need to achieve? What does it look like when I’ve achieved it? And how do I get there?”

Josh : Right, exactly. Right.

Jamie : Okay, so what about if folks are listening to this and went, “hey, that Josh, he knows what he’s talking about, I want to have a chat with him.” Is there a way for folks to get in touch with you? Like, are you on Twitter? Is it LinkedIn? It’s totally valid to not have an online presence? Is it just a case of lean out the window and yell, is it become an MVP and meet you an MVP summit? What’s the process?

Josh : Throw rocks at me in public? Smoke signals? No.

So I’m not on Twitter as much as I used to be, but I will respond there. So at @jgarverick, is my handle there. LinkedIn is probably a much better place, honestly. It’s easier for me to kind of sort through messages and stuff like that there. So just look me up on the LinkedIn and happy to answer questions and all of that stuff.

Jamie : Awesome. Okay. And what about getting hold of the book? Is it just have a look on Amazon, is it go to Packt? Did you have a preferred way for people to buy the book or are you just like, just buy the book, I don’t care.

Josh : Yeah, I mean, ultimately that’s kind of the message, right? Just buy the book, it’s fine. Honestly, Amazon is probably the easiest, to be completely honest, because that gives you the option, obviously, of doing print or digital. So it makes it a little bit easier for you to choose the right medium for you to digest it with.

Jamie : Cool. Okay. Well, what I’ll do is I will get a couple of links for you said you’re not on Twitter as much, but you are more on LinkedIn. I’ll get links for those. I’ll get links for Amazon for the book as well. And I’ll have a chat with Pact and see if we can get some links for the place to send people to or whatever. And I’ll try and get some geo tagged links that are clever so when you click, it takes you to the relevant store rather than going, oh, I’m in Australia, it’s going to take me to the US store. That’s clever. We’ll see what we can do.

Josh : You, yes, completely intuitive. Send me across the world.

Jamie : Absolutely. Excellent.

I guess all that really remains to say, Josh, is thank you ever so much for being on the show. I’ve had a pleasure.

Josh : Thanks for having me. Yeah, thanks for having me. It’s my pleasure.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest, Josh Garverick, for graciously sharing his time, expertise, and knowledge. Make sure to check out Josh’s book over at Packt - you’ll find a link in the show notes.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/review for ways to do that - reach out via our contact page, or join out discord server at dotnetcore.show/discord - all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places