196 Should I Build a Monolith or Microservices?

If I am building an app, should I design it as a monolith or should I use microservices? Should I convert my current monolith to microservices? What are the things I should think about before making a decision? These are the questions we will cover in this episode of Dev Questions.  

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:25

Should I build a monolith or microservices? This is a question I get a lot and one that has been a bit of a confusion for a while. So I want to address it in today's episode of DevQuestions. Now, this comes from the suggestion site. So if you have a suggestion, go to suggestions.imtimcorey.com and ask it there. Hopefully, you'll see your question answered in a future episode of DevQuestions. So normally when you ask me a question, I say it depends. And then I explain what I mean. In this case, I'm going to give you more of a straight answer. The answer, should I build a monolith or microservices, is almost always a monolith. Now, for whatever reason, people feel like monoliths are this old technology that we shouldn't use anymore, and microservices are the future. And that's just the opposite of true. So let's talk about why. Why should you choose a monolith over microservices? So, number one, microservices have dozens of points of failure. Now, the evangelists will say, yes, but they're so resilient we can have backups and all the rest. Okay, but how many services do you have to depend on? So in a very simple microservice environment, you have a database per microservice. And typically it's not all the same type of database, even. So now you're depending on, let's just pick a few: CosmosDB and MongoDB and SQL and a SQLite database. Now there's four different databases you're depending on and the hosting for those. And then you're going to use four different hosting plans or four different hosts for those four different microservices. Again, they should be all self-contained. You should not share, otherwise, it's not a microservice. We'll talk about that later. So now you're talking about four different web apps. And then you're talking about, well, now you've got to have hosting for those four different web apps. And what if they're on different servers? And if now the servers are also points of failure. And so you start adding up all these different points of failure. And then you have your communication system like service bus. Well, now you've got to make sure a service bus doesn't go down. And then you start thinking through all these other things. And if you just even have four microservices, you now have half a dozen to a dozen points of failure compared to if you have a monolith, typically you have one database, you have one web front end or desktop, but usually web front end, and maybe an API. For a massive system, it could be a massive system. And you say, well, yes, but there's a scalability issue. No, there's not, but we'll talk about that in just a minute. Number two, so number one, microservices have dozens of points of failure compared to a monolith. Number two, microservices add incredible complexity. I used to be an IT director, and one of my roles was to oversee all of our networking, all of our firewalls, all of our servers, all of like Active Directory, and all these other things that were all under my purview. With microservices, one of the things we've done is create Kubernetes or things like it. And now Kubernetes really is that entire server room, the entire networking, the firewalls, all that stuff in text files. All that management, all those services you have to know about in order to manage Kubernetes. That's not your actual code, that's the infrastructure that you add underneath your code that sits on top of other infrastructure that you also have to manage. So the level of complexity is much, much higher. As a monolith, if you're hosting on, let's just pretend we're hosting everything on Azure. Well, you have to handle Azure SQL, let's say. Okay. That's one thing to learn. You have to know about Azure Web Apps. That's two things. And you need to know how to use Azure Deploy or GitHub Actions or something similar, Azure DevOps pipelines. You have to know those three things in order to manage your application. With microservices, that list might be 20 or 30 different things. That's an incredible level of complexity. Number three, and this is the one that people really don't want to believe me on, but it's absolutely true. Most companies don't have the scale to justify. So when you're thinking about a microservice solution, you say, well, we need to scale. We need to scale. How big do you need to scale? Because with a monolith, you can handle hundreds of thousands, if not millions, of people. Is your business larger than that? Almost certainly not. Now, there are a few that are, and you could probably still scale the monolith to that point. So you need to think about what's the justification? What complex, what scale do we need to hit in order to justify the additional complexity and points of failure that microservices brings. And you might say, well, Tim, no website can scale that large. Absolutely they can. We didn't have microservices back in the day, and we scaled just fine. That's you know, old Tim talking. But part of this is that we're not talking about the ability to do things like having multiple versions of your website, for example. You can have that. You can have the ability to scale out, meaning having redundant servers or having a round robin system to send to different servers, even around the country, around the globe, in order to load balance your site. You can still have that with a monolith. So you can scale to very, very large capacities with a monolith. You don't have to have a microservice in order to do that. And then number four, this is one people don't think about, is most organizations do not have a staff to manage the infrastructure. Again, going back to my days of being IT director, I had a network administrator, I had a database administrator, and I had a server administrator working underneath me, and I was understaffed. You're talking about typically what happens is that all falls on one person. All the things that I did with three people, you're now doing one person, and that's not their full-time job. Really, what happens in a lot of companies is they say, we need to do Kubernetes, and so that's part of the developer's job is to also manage Kubernetes. So what you're doing is adding the complexity, you're adding the points of failure, you are scaling for no reason, and you're saying we're going to do all of this without adding any people, which means that what you're doing instead is taking away development resources, taking away the time they could spend on new features or making your app better in order to spend it on infrastructure and site management and risk mitigation and all the other stuff that comes with doing infrastructure. So you gotta think about those costs as well. There's a lot of reasons why microservices are not the right call. Now, I get asked the question: what about monoliths that utilize microservices? Meaning it's mostly a monolith, but we have some microservices on our monolith. And today I say be very careful. You do not want a distributed monolith. So if you have to deploy your microservices with your monolith, you don't have microservices, you have a distributed monolith. If your database schema changes for your monolith and you that affects your microservices, you have a distributed monolith. If your microservices share code with your monolith, you have a distributed monolith. That's a major problem. It makes things worse. So but why? Why are distributed monoliths so bad? Well, number one, they have all the downsides of microservices. They have added complexity, they have add points of failure, and so on. But they also have all the downsides of monoliths. They're harder to deploy because you have to deploy to the entire thing, they're harder to change because it affects everybody, and so on. So you're taking on all the downsides of microservices and adding the mic the downsides of monoliths and saying, hey, that's better. You don't want to do that. Now, there are ways to utilize microservices with a monolith. But the way to do it is to make an independent piece. So maybe there's a certain area or a certain thing that happens that can be independent that itself needs to scale in a way the rest of your monolith does not. So really easy example is a college doing registration. Maybe open registration on a certain date. Well, that's gonna get slammed with a lot of people applying. Because on that certain date, everyone wants to rush to get in on time and rush to be in in line. Well, maybe the registration piece could be its own microservice. It could have its own database, it could have its own setup, its own deployment schedule, it could have nothing shared with the monolith. And then it could scale in a way the rest of the application doesn't have to. Because registration page, yeah, it's gonna get hit really hard all at once in a concentrated time frame. But the rest of the application is gonna just putter along as normal because we don't have that rush of on this date. That could be a use case for a microservice that supports and helps your monolith. Because your monolith then wouldn't have to scale as high. Your microservice could be a thing that could be scaled up very quickly and to a larger height than the rest of your application, saving you money. And if it saves you money and maybe even reduces some complexities while adding others, then it could be worth it. Now, the other thing you can do is you can make your monolith more modular, meaning more loosely coupled. Maybe it's not one big blob, maybe it's two or three monoliths that again are independent. They're more easy to be deployed separately, where you have a little bit more options to not take everyone down when you deploy or not affect everyone, or or so on. You can do some looser coupling in order to make life easier there. So that's a possibility, but you gotta be very careful not to slip into distributed monolith. So the question comes out then, is there ever a time when microservices is the right answer? And the answer is yes, but it's rare. And you probably aren't the exception. I get this a lot where people say, well, is there ever a time? And I say, well, yeah, there's there's a time. They go, cool, that's me. It probably isn't. You're not Google. So that's why I'd say be very careful taking on microservices. If you're already there, you do what you gotta do. But really, microservices is not the golden ticket to a better solution. Writing better code in a more modular way probably is the better choice there. So the bottom line is this microservices sound fun and they can make for some great demos. In fact, you may see people who build out awesome demos with microservices. And you know what? I might even do some microservices type stuff once in a while because there are benefits. But be very careful because often what they'll say is here's the benefits, and they'll start talking about an example of who uses it. And look who they're talking about. They're often talking about multi-million, multi-billion dollar companies. They're not talking about, you know, a single website for a single company, or even a company for a hundred thousand people. They're talking about massive companies. So building monoliths will almost always be the best choice for you. You can scale a monolith to hundreds of thousands or even millions of users. Often people write poor code and it doesn't scale well. And they say, well, see, monoliths don't work. I need to have microservices. If you write poor code in monoliths, you're gonna write poor code in microservices. And you're just gonna pay more money in order to try and get more scale because you wrote poorly optimized code. Write better code. Optimize your code better. So unless you're already maxing out your capacity in the cloud, you probably don't need microservices. So something to think about, but I would encourage you. Yes, it's cool for demos, yes, it could be you know for one-off situations, but the reality is monoliths are almost always the way to go when you build an application. All right, thanks for listening. As always, I am Tim Corey.

SPEAKER_01 15:31

Thank you for joining us for this episode of Def Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamTimcore.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.