Why You Probably Don’t Need Microservices

[00:00:00]Somebody asked in a comment if I could maybe do a discussion about microservices and I'll say that I have read a book about microservices about 10 years ago, so I'm probably an expert at this. But jokes aside, I have worked at a company before where we tried to do this microservices approach and micro UIs approach. So I'll kind of give you my opinions on it and just walk you through what exactly is microservices, when would you might want to use a microservice, why do these large companies even have microservices, and also when you should probably just completely avoid it cuz there is a lot of overhead and complexity that you may not have thought about trying to maintain all these separate services that are deployed out there. So let's just jump into it. We have a user. Let's just say user. We also need some developers, so I'll just go ahead and add in like a developer here there.

[00:00:42]Maybe we can have three developers. We need to have an API, so I'll add in a server. I'll just call this your app and then probably also a database, so database.

[00:00:51]I'll make the developers green because they're always super happy and then we're going to go over here and make a box around this and I'm going to move it backwards a little bit. Okay, so here is your monolith application. It's the API connects to the database. The user needs to make a request to the app and your developers are over here pushing pull requests to try to add features and make changes. Okay, so this is a traditional application, a monolithic application.

[00:01:14]And for the most part, this works perfectly fine. If you're a small company, a startup, a side project, the less moving parts you have, the easier it is to understand the code base and also to maintain it. Now granted, adding AI into the equation does change a little bit because now it's much easier for a developer to jump into a new project and understand it, but if you were to look at microservices in the wild, you may have a different service written in a different language, a different framework, and so having that context switching for one developer need to know maybe a go off service and then another service is maybe using something else. There's a lot of overhead. But let me rewind cuz I think I'm jumping ahead.

[00:01:51]So this is the traditional monolithic approach to an application. Why exactly would you start splitting stuff off into separate deployable encapsulated services, okay? So, one good example that many books, like I mentioned, or just online people talk about, is an off service. So, every request a user has to make to your app, it typically has to go and look up credentials and verify the session from a database. But, this database is also going to contain all your normal application records. At some point, it may make sense to split off that data into a separate database. So, for example, you could actually make an off service. Let me copy this whole thing and I'll put it over here.

[00:02:29]And let's just pretend now that we have an off service.

[00:02:32]And this is your off API and it has its own off database, okay? So, you kind of pulled out if you identified a seam, you identified an area in your code base that you could probably pull out and you're moving it into a completely separate deployable unit. So, off service. And basically, now developers have to worry about working on this monolithic application, the monolith may go and reach for the off service to figure out, "Hey, is this user actually validated? Is their session proper?"

[00:03:01]Instead of having to go to this database, we've now reduced the strain on this database, we moved the data out to its own self-deployable thing. Okay, so what are the benefits of doing this, right? One benefit is we can scale this thing up independently from the monolith. Like, the actual application logic that's dealing with storing canvases or drawing stuff, I don't know, depending on whatever you're building, you can scale that out separately from your off service. You may decide that your off service needs to have a bunch more servers. Maybe inside of it you need some type of like caching system like Redis versus your other application doesn't actually need that. So, this is something that you can kind of split off. I'm trying to click on this box and move it, but like whoever made this drawing diagram like doesn't know how to code. All right, let's just do this.

[00:03:43]We'll put like a Redis caching system in here. Anyway, so the point I'm trying to get at is that when you've identified an area in your code base that can be scaled up independently because the amount of load that's hitting it is a much higher than some other parts, or if you decide that you need to actually rewrite that certain piece in a a faster language. Let's say that you're getting a bunch of auth requests all the time, you can actually rewrite this auth service in Go or Rust or something so that you can reduce the amount of latency it takes to actually like get this data back and send it back to the user, okay? So, some other benefits of doing this is let's say there was some really complicated complex logic in that monolith and you wanted to pull it out so that it's easier to maintain. That's also something that this can achieve.

[00:04:22]Helps with maintainability from one direction, right? I will say that it can make stuff a lot more complicated when it comes to deploying and orchestrating and maintaining all this stuff because now, we talk about some of the downsides, this developer needs to now care about two different services.

[00:04:38]Whether this code lives in a mono repo or if it lives like, you know, in separate repos, it doesn't matter.

[00:04:43]Someone needs to know how to write whatever code this monolith was written in. Let's just say it's Node or something, uh JavaScript or TypeScript, and now the auth service was written in a different language. So, that's a completely different language, typically it's different frameworks, typically it's a different ecosystem, which adds on to the the burden for the developer to even be able to manage both of these things. Secondly, the whole deployment orchestration of how this works. If you were to make a breaking change on your auth service, you need to make sure that all these other services that are deployed independently know how to deal with that breaking change. And that, of course, adds on a bunch of complexity for orchestration. Now your developers need to coordinate with other teams, but I will say let's go back to the the positives of this. So, as you have a bunch more developers, let's just keep on adding developers, what you can end up doing is you can split off different developers into like teams, right? A lot of organizations, this is how I've seen it done where you have This is the auth service team. They're going to be working on your auth service, and that's kind of the only thing that they're responsible for. So, instead of a developer working on two different services, they just work on the Go auth service. That's their kind of specialty.

[00:05:45]They make sure it's fast, they make sure it's secure, they make sure they're scaling it properly. And this also works pretty well, but honestly this was not in my opinion the original intent of microservices. Microservices was there to solve a technical problem, but it ended up being adopted by large-scale organizations and companies because it tried to also solve their organization problems as well. There is something called Conway's Law where systems end up replicating what we kind of see in organizations. So, typically if you're working at a company that has microservices their probably some type of organization structure that was the reason why your microservices kind of map to your organization. All right, let's break this down into one more microservice. Let's say like a payment service, okay? Let's say you have another set of developers who need to work on maintaining payments. They have their own payment database, they have their own notification system. How do you send out emails? And maybe you hire a couple of developers to kind of work on this. Now, as the microservices increase, the complexity in terms of the network requests starts to increase as well. So, now instead of the application being responsible for sending out the the emails for the payments and also just writing straight to the database, the app server, the monolithic node service needs to then contact the payment service. So, I'll say payment server.

[00:06:58]And this could be a I'll just say payment database, okay? Now, from what I read, at least I believe, typically these microservices go one-to-one with the database. You don't want all these apps sharing the same database because when you update the schema, again, if you do a breaking change to your schema, you have to make sure that all these different apps know how to coordinate and deploy out with that breaking change. But now the point is is that this payment service, maybe it needs to go and contact the off service, maybe you have a different service for like notifications or something. And you can see that as you start adding in more and more services, you've now added in a bunch of network traffic, which means that something that used to just run on the machine itself like the CPU. If you can get this all deployed onto a single VPS, you can do intra communication on the loopback address and keep the network speed very fast. But now you've introduced some latency to try to do a request from your monolithic application to your off service, your payment service, etc. And this just keeps on adding in. So, when you add this complexity, you now have to add in a bunch of error handling. What happens if this server was rebooting, or you know, maybe it was doing a rolling deployment at the time, and this request fails? Do you have enough error handling and retry set up in your application to even handle when the new payment server comes up? These servers typically would have to have some type of rate limiting in place as well. So, if this application for some reason is flooding the payment service with too much requests, again, you have to make sure you have a bunch of stuff in place to do retries. Also, your payment server needs stuff in place to rate limit. So, now that original monolithic approach that you were doing, you now have a bunch of different services. They're all maintained separately. They all deploy independently, which is great for scaling and great for your organization, because now you can have developers just focus on their service. But now the complexity is actually shifted to the dev ops side of things, and also to the actual internals of how these services all operate. You got to make sure that everyone on this dev team knows how to properly deploy out and secure these things. So, typically, what you'll see is these larger companies end up embracing stuff like Kubernetes, right?

[00:08:55]And everyone who's deploying out their services, they use the same standard Kubernetes to get it all deployed out there. Cloud Foundry is also one that's out there. But again, as the organization grows, something that can become very complex is if you let these services deviate too much. Like this one's a go service. Maybe someone decides that the tech lead on this one wants to make it in Rust. Now you have a bunch of different services that are kind of going against a standard, and now it's very hard to take one developer and put him onto a new team, cuz now he has to ramp up and learn the new language, learn the new best practices of Rust, learn the ecosystem, the frameworks, whatever. I think I already kind of mentioned that, but I hope you guys get the point. Now, I think there's one more thing I want to hit on. As you are scaling out these different services, some of these services do not need to be publicly accessible. But if you do that, they don't have a domain.

[00:09:43]How do you actually have this service know to contact this payment service?

[00:09:46]There's DNS you can use. If you're using Kubernetes, there's a built-in way to do this. One approach that we ended up doing on our project was something called Consul, which is a discovery service. So, basically, as these services come online, you could have four payment services that are horizontally scaled. As they come online, they're going to register the Consul, so that when the app service needs to actually contact the payment service, it's first going to say, "Hey, give me one of the payment services instances." And then it's going to get an IP or, you know, a location it can make the request to, and then it will make the request. Same thing with the off service. That thing when it comes online, it's going to register itself with Consul. And you can keep this behind a VPC. You can keep it private, but all these other services can use it as like a centralized place or a registry to know how to even contact these other services. So, you've added in yet another thing that you have to maintain and deploy and update and keep secure. And as you can see, as you keep on scaling out these microservices, you're probably going to hit more and more complexity and and other solutions that you'll find online that people have created to solve the problems that microservices are creating. Okay, so there's just some of the pros and cons of microservices. I'm not trying to go super in-depth on this video. I'm trying to keep all my videos like 8 to 12 minutes. So, I think I covered a decent amount about it. I would recommend go check out that book I showed. It's called Building Microservices. It's by Sam Newman.

[00:11:03]Or just ask ChatGPT to give you more or information. But I think something I've seen working on a microservices team was that often we get very territorial about our services. And even though we have the ability for other developers at our org to make changes to our microservice, typically, there's a bunch more red tape. This developer may say, "Hey, I just need a little fix on this this project to be able to do this on my payment service." This team's like, "Yeah, we'll get to it when we get to it." It never ends up getting added into the codebase because of who knows what.

[00:11:33]Um, but there's a bunch of organization overhead that goes into it. Versus if you just have a monolith, make a pull request, you can just do the refactoring right then in the code. Maybe someone can review it. You can get it deployed out there. And then your users can start using it. Let me know in the comments if there's anything that you wish I dived a little bit more deeper into. Uh, I think I kind of hit on most of the stuff, but I'm sure there's a lot of stuff I missed out. Anyway, all right. Hope you guys enjoyed. Have a good day and happy coding.