Should I Build a Monolith or Microservices? 

Thanks for sharing!

It's still great knowledge for a Junior dev though! I've always wondered what the difference was between the two in a deeper sense and what justifies each one

I agree, would love to see more videos about useful architecture tips :)

True, but my guess is that it wouldn't be any different if we changed the name. That would just be more fodder for the click bait crowd.

Yep, and they probably don't understand the scalability aspect. It is like putting a spoiler on a Toyota Corolla.

You are welcome.

Thanks.

You are welcome.

You are welcome.

Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/

You are welcome.

Thanks for sharing!

You are welcome.

Totally agree, micro services end up in a mess of dependencies to manage

Agreed.

I would suggest it on the suggestion site. I don't have one yet, but that is an interesting topic.

It depends on the project. You can have a loosely coupled application with just one project (or maybe two since I really don't like the UI tied to the business logic/data access).

You are welcome.

You can definitely make it work, and if it works for you that's great. It probably isn't necessary, but not everything we do is.

Thank you!

When to choose microservices is going to be situation-specific, but here's a basic criteria: Don't choose microservices unless you have a scalability need that you cannot solve in any other way. For example, if you are trying to process 500,000 requests per second, you might be ready to consider microservices (but only if scaling out isn't good enough for your needs).

You are welcome.

I am glad it was helpful.

Thank you!

I have three courses on here about building monolithic applications: Tournament Tracker, TimCo Retail Manager, and Suggestion Site. All three are playlists on this channel.

Thanks for sharing!

3 tier , n tier are also monolithic systems!

Correct, 3-tier, n-tier, etc. applications are monoliths. Think of a microservice as a very tiny 3-tier application (hopefully less than 100 lines of code, but with its own interface through database). The key is do you have dozens of these tiny, independent applications or do you have one large one (monolith)?

Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/

Thanks for sharing!

No, I don't think so. It isn't designed for that and you aren't getting value out of doing so.

Azure functions are cloud native serverless. It's an abstraction of all the complexities that Tim talked about with something like kubernetes. Similar to AWS lambdas, but imho far more capable. I've never had the opportunity to work on an IAC project that had azure functions in it, so I can't say how close to the best of both worlds it gets. I like azure functions. You can get some elegant all in one api solutions with it and lots of other stuff too.

Azure Functions are microservices, but they can provide and standalone solution to a standalone problem. Basically, the idea of having a monolith with a few microservices where needed (not a distributed monolith).

For sure.

I think you are mixing two different things together. One is a benefit, one is a drawback. Let's start with the benefit. In a microservice structure, if you write bad code for emailing customers, for example, your code could crash that particular microservice. However, it won't crash the overall application. You can also then take down that one microservice, fix it, and apply a new one without taking down the whole application. If your app is a monolith and you have a bug that crashes your application, the whole application crashes. So, that's definitely a point in the favor of microservices. However, what I was talking about was added points of failure. In a monolith, if I want to store the customer record in the database, then email the customer, and create a new order record based upon the transaction, I can do all of that directly by making method calls. In a microservice environment, that's not the case. Typically, the customer creation microservice would store the customer information in database 1. Then, it would send a message onto the message queueing service. The emailing microservice would pick up the message, store some information in database 2, then send the email. Another service would pick up the message to create the order record and store it in database 3. That new record would be then be put into a new message for the message queueing service for future services to handle. So just in that simple example, we have 3 times as many databases, a message queueing service, and the hosting for multiple additional services all as added dependencies. What happens if the queue goes down? What happens if database 2 goes down? While, in theory, a microservice environment can handle most of these things and come back, these things are all additional points of failure for your application. If the queue goes down, your entire microservice environment fails whereas the monolith just keeps going. If database 2 has an issue, the customers don't get their emails in a microservice environment, but the monolith would continue to send those emails. Do you see the difference? I'm not saying that there's never a case where the costs don't outweigh the benefits, but you can't just look at the benefits of one situation and compare them to the costs of the other. That's a recipe for disaster.

I covered modular monoliths in this video.

You are welcome.

I feel like you just fell into the microservice trap. You are advocating for a company who might not need the "benefits" now still implement microservices because it "future-proofs and provides more business agility". So you want to invest lots of time and money into something that they don't need, but that you think they might need in the future. Again, did you listen to my example in the video? Stack Exchange does 1.3 billion page views a month on a monolith. At what point do they need microservices? You do realize that microservices REDUCE performance, right? The trick is that you can have more of them doing any one task, but the overall process will be less efficient than the monolith equivalent. The communication time between services alone is enough to make it less efficient. That means that your solution to a perceived future performance issue is to cause a performance degradation now. As for small companies working with microservices, what you are advocating for is a significant increase in their costs for something they don't need now and, as I've shown, probably will never need. A monolith is MUCH cheaper to build and maintain. Even a moderately-sized business can be on one web server and one database server (maybe a caching server as well for good measure). Maintaining three containers (because even monoliths can use containers, which means some of your microservice "benefits" apply to monoliths as well) can be done fairly easily. If you break that app up into dozens of microservices, each with their own database (because that's a requirement of microservices, don't forget), and now you have a complex infrastructure to monitor and maintain. Then, when it comes to debugging your app, a monolith again is much easier. You can run it fully on one machine to test things out. Testing microservices is a lot more complex. I could go on, but I think that's a good sampling of why I HIGHLY discourage companies from jumping into microservices simply for "performance gains". What they will find is exactly the opposite in almost every case. If you don't have the skills to make a monolith performant, you aren't going to have the skills necessary to make a microservices environment performant. What you are going to end up doing is throwing resources at the problem, which means you will be throwing money at the problem, in order to try to "solve" your issues. This is why there is actually a migration AWAY from microservices and back to monoliths: learn.codesee.io/migrating-from-microservices-to-a-monolith/

Now I'm hungry.

A monolith can have multiple projects. What makes it a monolith is that it is directly connected together, even if loosely. Meaning a change in one part often requires a redeployment of the whole thing. An API in the middle allows for a bit of a modular monolith, which is great. It could also be termed as two monoliths if they truly are disconnected fully from each other.

If you cannot create a monolith without creating a mess, creating a microservice architecture isn't going to make things better. You are going to take those same problems and add the additional problems of eventual consistency, sources of truth, inter-microservice communication, security issues, and more. By the way, as for my experience, I've spent over 20 years being a consultant for companies of all sizes (5 employees through Fortune 500). I've done this full-time for 10 years and part-time for the rest. I've helped set the direction for hundreds of companies over the years.

A microservice is a small, self-contained application that does one job. For instance, it might just send emails. It would have its own interface (usually a small API or a listener for a message bus) and its own database (yes, a whole database just for the one service - the database cannot be connected or part of a larger database and it cannot just be independent tables inside a larger database). The idea is that you break apart your monolithic application (one application that does all of the work) into lots of little microservices. Since they are all tiny and independent, you can deploy changes to them independently of everything else. You can also scale them differently from each other. You can also have multiple of one service running to handle higher volumes instead of just throwing more resources at one. The theory is sound and it is how very large companies like Amazon handle such high volumes of traffic so efficiently. However, it has become a popular topic among developers in general. People have implemented this system in environments that do not need this type of scale. The downsides of microservices include MUCH higher complexity, many more points of failure, and much higher costs among many others. Even worse, some people have taking the wrong lessons from microservices, or they have decided that not all of the points need to be done such as independent databases. What you get then is a distributed monolith. They say they have microservices, but they all depend on the same database, which means if you change the schema for one "microservice", you have to make changes to all of the other services and you need to redeploy all of the "microservices" together. The result is all of the downsides of monoliths with all of the downsides of microservices.

Mostly, but a lot less so in this case. There are very few situations where microservice architectures are the better solutions (and that includes massive sites and systems).

No, if you want to scale up still monolith is best choice. At the point of your scales becomes to big, important bits and pieces will need to be rewritten as external microservices, but for the time being you don't need to overengineer your app. Look at stackoverflow, it is monolith..

That's the trap. It sounds right. You want scalability. But you never really address what type of scale you are expecting that would warrant a microservice structure. As @RaZziaN1 pointed out, Stack Overflow is a monolithic application. They have 300 million visitors per month on an application where they are actively changing data (upvotes, comments, questions, answers, etc.) plus where they are incentivized to filter through millions of records on each visit. That's why I am skeptical of any organization that says things like "we want to scale so we are going to use microservices". Microservices use more resources by far, and are far more expensive, when you are running a site that has 100,000 visitors a day than if you just built a monolith. So you are choosing a complex, expensive solution in the thought that you might get to the point someday of being bigger than Stack Overflow. More often, the reason people choose microservices is because they don't know how to optimize code so they think that monoliths are slow. The problem is that if you build a slow monolith, you are going to build an even slower microservice setup. That means even more costs.

It works until you have 1m simultaneous user then it'll break

First of all, what are you building that you anticipate 1 million simultaneous users? Second of all, Stack Overflow gets an average of 10 million visitors a day. Even they probably don't have 1 million simultaneous visitors often, but they do have them. They don't break. And they don't even have that complicated of an infrastructure. Here is a diagram of it as well as a breakdown of their numbers: stackexchange.com/performance It also looks like the numbers above were visitors per month (and might be a bit low). They serve 1.3 billion page views per month using 9 IIS servers, 4 SQL Servers (two of which are hot standby servers, and only one of which is used for Stack Overflow itself), and some caching servers. This is why I say that people who move to microservices because of scaling don't typically understand how to do scaling. The peak usage on any of the Stack Overflow systems is 20% (that's peak, not average). That means that in theory, they could serve five times the traffic without making any changes. I know I'm being a bit rough on you, and I don't mean to beat you up, but I would highly encourage you to spend more time learning how to make performant code rather than chasing after systems that are even more complicated than the systems you don't know how to tune effectively.

I was talking generally and not specific to my use case but I think I have a valid point, for example when building something for a government entity I think microservices is the way to go. And as I mentioned before when you have a LOT of users simultaneously a Monolith is going to crash, With that said I'm not disagreeing with you about anything, Microservices are very complex and more expensive and they need a lot of resources and experienced, well rounded developers to build them well just like you mentioned in your video. Anyways great video 😃.

Working to ensure ACID with one SQL database is a breeze compared to trying to handle a similar principle (can't really be ACID across services) with microservices and eventual consistency. It is nightmarishly complicated and those who think it isn't don't really understand it well enough yet.