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
At this point I think we need to change the "Monolith" name... Popular opinions reference Monolith like it was a "disease" and the solution is the Microservices... But in fact if you are not able to build a clean Monolith you'll end up having a lot of fun with Micro Services 😉
Around 85% .NET job descriptions are asking for experience in Microservices, but most of the time they can't really tell the actual reason why. The answer is always scalability and nothing more in detail.
I'm becoming a tech lead next month in a new employment and this video is a great consideration material for my new role and works to be done there. Coincidentally in my last employment, I stick to the principle that Tim explained in this video, and yes, not everything needed to be ported to the microservices.
Thank you so much for sharing your profound knowledge with us Tim! It is so much fuss about micro-services that it makes it really confusing to understand why everybody are doing it with some vague reasoning.
A good video as always. also good timing overlap with the modular monolith episode on rocks. More Info always better and makes it sink in more for me8).
I agree with basically everything, except the "points of failure". Distributing and thus minimizing points of failure is one of goals of microservices. He made exactly that point when talking about the registration service.
Distribution both minimizes points of failure as well as increasing points of failure. Here is why: Imagine you have a monolith that runs on a web server and depends on a separate SQL server. If either server goes down, your app goes down. You have two major points of failure. If the SQL server crashes, your app fails. If IIS/Apache fails, your site goes down. Now let's imagine a microservice implementation. It uses Kubernetes to manage 5 different web apps, each with their own database. They communicate over some type of service bus (let's say RabbitMQ). Where are our points of failure? The idea is if one of the web apps fails, a new one gets spun up (or more than one is already running). Ok, so we could say that there are no points of failure there, but that's not true. What if one of the web apps is affected by a JavaScript bug. It doesn't matter how many you spin up, they are all the same. That's a point of failure. Now you have five times the number of points of failure for web apps. Let's go further. What happens if RabbitMQ goes down? All of your apps crash. Point of failure. What happens if any of the five databases goes down? Point of failure. What happens if Kubernetes goes down? Point of failure. In all, your efforts to eliminate points of failure actually make a lot more. So you keep adding complexity in order to reduce those points of failure. Replicating your whole K8s environment in another region would help, but now you depend on great replication. That's a point of failure. Before long, you have an incredibly complex, expensive system that often has many more points of failure in an effort to eliminate points of failure. The alternative, with a monolith, would be to replicate the database and have the application hosted in another region as backup. Something you have to do with a microservice architecture too, but at a much smaller scale and with less moving parts.
@@IAmTimCorey Again, I think there's a misunderstanding here. To my knowledge, no one is claiming that microservices "eliminate points of failure". They're claiming they distribute them into smaller, less destructive points of failure, that can be recovered from quicker. That admittedly comes at the cost of increased complexity. This is the point you made with the registration example. To reduce the impact of the monolith's single, massive point of failure, you move that functionality into a microservice, which won't bring the entire app down if it fails, and can be quickly redeployed. That's one of main the goals of microservices. I still think your overall suggestion is exactly right. Start with a monolith, and create microservices if and when needed. They likely won't be.
Thanks for the video! Can you please suggest or make once some separate video about best ways on how to test monolith, especially layer between unit and e2e ui tests? Or only monolith way is to use unit tests?
I decided to go with monolith for my latest project and I've been stressing that I should've gone with micro services. All the other devs at the company where I work have been pushing them even though we're definitely not a Google sized company. Thanks for this video, it definitely calmed my nerves.
We've just successfully deployed a microservices based Api in AWS. We liked the idea it was highly configurable on a very modular level, and that cost is pay-per-use only, also deployments are naturally a breeze which is an added bonus without setting up a blue/green mechanism manually. Maybe it's not what you would term as the justified solution for it but it's worked out great for us for what is not a massive Api but handles a very large number of requests every day. Modular monolith is something I've been considering for a few new things lately though.
Thank you Tim Do you have any series or introduction video about what is modular monolith with the best practices for that? or should I suggest that on suggestion site?
Too many young programmers lean toward what they consider fun instead of functional. I get it. My early days of programming revolved around what I thought was "neat" code such as segmenting code into thousands of tiny methods/objects so that I never repeat a single line of code. In every case, none of my fun ideas lasted. I learned the hard way what not to do. Microservices is absolutely one of those ideas. It's a bad idea in almost every scenario.
You really just touch the point that I am concerned about all the time, WHY we need Microservices and What is the scale for Microservices need, but here there is a question, what are the criteria used to choose upon ?
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).
I think you touch on some really good points here, especially where beginners are concerned. Scale your work to the business you're working for. Any developers role is to essentially hit business goals at the end of the day - how you do is largely irrelevant to everyone but yourself. (managers and owners certainly (for the most part) have no interest) We have a monolith in our SME business (50 employees) and its fine, in fact the greatest bottleneck of the system is born from development knowledge gaps but thats OK too. No-one is an instant expert from the start and by the time you've become an proficient in something, there's a new breed of technology replacing it - its never ending. Stick with something, run with it but crucially, *make it work for the business*.
monolithic is fine. Good for small, medium and large apps who don't have crazy scalability, adaptability or availability requirements mostly centered around hypercomplex application architectures (Amazon Web Services, Azure API, GCP, etc). Microservices are cool but are for big apps run by big boys (Largest streaming company in the World) on big systems (AWS, Azure, GCP) paid for by companies with all of money (Netflix, Apple, Salesforce, etc). The question always comes down to: Is doing things the microservices way worth the additional cost and hassle? In almost every scenario I have seen it deployed, the microservice juice was not worth the squeeze. Run it on K8S and you take the horror to a whole new level.
Thank you Tim for priceless information and clearing the air. I was very overwhelmed with the term Microservices being mandatory requirement in many job requirements. Just a question, as you mentioned write loosely coupled monolith applications. Does having many separate layers or projects in one solution with proper DI and unitOfWork implemented is considered loosely coupled as well ?
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).
Hi Tim, I like what you say and I think you also have in mind the idea of using in the monolit blazor and not frontend frameworks like angular. But the guys that are indoctrinated with only microservices will scream like crazy :). Maybe soon you can make a video and advice us what aproach a dev should have when he needs to fight tech-leads and architects that are not doing the right thing. Thank you!
We've come to the exact same conclusions in our organization (with also the same human capital issues) and are already in the process of phasing out complexity and returning to simplicity and lower technical debt.
While I generally agree, It is easier to work with microservices when you build new features. If you start it right, it forces you to think harder about the architecture and you will be forced to decouple your components whereas with a Monolith, there is far greater temptation to skip this especially under high pressure to deliver.
When stating it is a disadvantage that a micro-services have more points of failure, this is in fact an advantage of microservices. The failure of 1 micro-service should not impact other micro-services, and therefor the failure has less impact. The separation of concerns that is brought by micro-services is a great advantage over monoliths, this is not a disadvantage of micro-services, it is a disadvantage of monoliths.
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.
Sure. And in fact, I would recommend that. If you REALLY find that you need microservices, you will probably have a couple key areas that jump out. Make those areas microservices but keep the rest of your monolith. But wait to optimize until you need it rather than prematurely optimizing and causing issues.
I have seen a bunch of people speaking about and doing microservices courses, looks like this a trending topic I haven't too much about Monolithic Architecture, how can learn more about Monolithic book, courses o TH-cam channel recommendation?
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.
Hmm could I get an opinion on a 3 tier system over a monolith. We a web application but also have the system to server mobiles. Generally I use monolith as default.
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)?
In my opinion, this portrayal of the importance and role of micro-services is not completely accurate. It is definitely not only large tech companies that need micro-services. I have seen small companies that desperately needed to change their monoliths to micro-services. When comparing monolithic to micro-services, all benefits and disadvantages should be considered, not only the few mentioned here. A company might not obviously need the benefits of micro-services right now, but things change, and micro-services future-proofs and provides more business agility. The disadvantages of micro-services listed here is also not completely accurate, by stating the complexity of implementing Kubernetes/containerization. In fact, for micro-services I would recommend Azure Durable Functions running serverlessly - this is really easy to implement, and has great cost saving and other advantages over other micro-service implementations. Then there is also Azure Container Apps, which is also good and easy to implement. Modernization is simply the breakdown of larger components into smaller micro-services, and in my opinion, all companies could benefits from this. It is the new way.
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/
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).
Just so we are clear.. When your talking about a Monolith, your not talking about the Front end project/API all in one project/deployment. Your strictly talking about the API project being a monolith correct.
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.
monolith on itself are almost always created as a spiderweb of references between the different projects in a solution. This in my opinion makes the monolith more complex then the architecture of microservices. I still agree that microservices in total are more complex then a monolith but in my opinion mutch less chaotic complex. I love microservices due to the maintainability of the code. A solution is way smaller and easy too manage. Testing your one small service and replacing it, is made way easier. I understand clean code and all, but i barely see this in a monolith solution. So most programmers i see don't really have the skills to create a monolith in a modulair way. I see this way more often when the microservices architecture is used as they are more forced to be 'modulair'. You are talking about one man's army in big businesses. I work for 5000-300.000 busnisses and they have multible teams for this. So our experiance in how a company handles IT seem too be very different. This seems to be in my opinion the reason for our different in opinion
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.
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).
I think it depends, for example if you want to scale your app and you have a large user base then microservices is the way to go. That said it’s definitely more complex and way more expensive than a monolith. For most ppl monolith is the way to go.
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.
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 😃.
If devs knew better how to use better modularity in their monoliths (trending term modular monoliths) they would probably realise they don’t really need to distribute their modules or turn them into microservices. The big pitfall to watch out for is lack of ACID transactions across database updates once you go full microservice. Having multiple databases all on same instance still allows ACID transactions, e.g. using MSDTS or the like. But split the databases with a microservices architecture and you typically lose this capability, with likely support-intensive consequences with data loss due to eventual consistency (in other words, a lack of consistency).
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.
Obviously a microservice is not a service for DI, consisting of a view lines of code only, like trimming strings. Since I don't know what a microservice is, I cannot continue. I'm just reporting, what viewers you reach here.
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.
Excellent information, and btw keep providing materials about architecture because not only juniors are watching your videos ! Great video!
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 :)
At this point I think we need to change the "Monolith" name... Popular opinions reference Monolith like it was a "disease" and the solution is the Microservices... But in fact if you are not able to build a clean Monolith you'll end up having a lot of fun with Micro Services 😉
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.
Around 85% .NET job descriptions are asking for experience in Microservices, but most of the time they can't really tell the actual reason why. The answer is always scalability and nothing more in detail.
Yep, and they probably don't understand the scalability aspect. It is like putting a spoiler on a Toyota Corolla.
I'm becoming a tech lead next month in a new employment and this video is a great consideration material for my new role and works to be done there. Coincidentally in my last employment, I stick to the principle that Tim explained in this video, and yes, not everything needed to be ported to the microservices.
Thanks for sharing!
Starting the day by learning from you is a pleasure. Thanks, Master.
You are welcome.
Thank you so much for sharing your profound knowledge with us Tim!
It is so much fuss about micro-services that it makes it really confusing to understand why everybody are doing it with some vague reasoning.
You are welcome.
Thank you dear Tim for making it so clear, keep it up dear, and thank you again for your valuable quality content.
You are welcome.
Tim is always a great mentor.
Thank you!
Microservices are great for company like meta as they need to continuously add/test new features but for most other cases monolith is still better
Totally agree, micro services end up in a mess of dependencies to manage
Agreed.
Thanks, Tim. Good one! 👍
You are welcome.
The whole video talked exactly same word what I am advocating from a long time. Thanks putting in a video so that I can share
You are welcome.
A good video as always. also good timing overlap with the modular monolith episode on rocks. More Info always better and makes it sink in more for me8).
Thanks.
I agree with basically everything, except the "points of failure". Distributing and thus minimizing points of failure is one of goals of microservices. He made exactly that point when talking about the registration service.
Distribution both minimizes points of failure as well as increasing points of failure. Here is why:
Imagine you have a monolith that runs on a web server and depends on a separate SQL server. If either server goes down, your app goes down. You have two major points of failure. If the SQL server crashes, your app fails. If IIS/Apache fails, your site goes down.
Now let's imagine a microservice implementation. It uses Kubernetes to manage 5 different web apps, each with their own database. They communicate over some type of service bus (let's say RabbitMQ). Where are our points of failure? The idea is if one of the web apps fails, a new one gets spun up (or more than one is already running). Ok, so we could say that there are no points of failure there, but that's not true. What if one of the web apps is affected by a JavaScript bug. It doesn't matter how many you spin up, they are all the same. That's a point of failure. Now you have five times the number of points of failure for web apps. Let's go further. What happens if RabbitMQ goes down? All of your apps crash. Point of failure. What happens if any of the five databases goes down? Point of failure. What happens if Kubernetes goes down? Point of failure.
In all, your efforts to eliminate points of failure actually make a lot more. So you keep adding complexity in order to reduce those points of failure. Replicating your whole K8s environment in another region would help, but now you depend on great replication. That's a point of failure. Before long, you have an incredibly complex, expensive system that often has many more points of failure in an effort to eliminate points of failure.
The alternative, with a monolith, would be to replicate the database and have the application hosted in another region as backup. Something you have to do with a microservice architecture too, but at a much smaller scale and with less moving parts.
@@IAmTimCorey Again, I think there's a misunderstanding here. To my knowledge, no one is claiming that microservices "eliminate points of failure". They're claiming they distribute them into smaller, less destructive points of failure, that can be recovered from quicker. That admittedly comes at the cost of increased complexity.
This is the point you made with the registration example. To reduce the impact of the monolith's single, massive point of failure, you move that functionality into a microservice, which won't bring the entire app down if it fails, and can be quickly redeployed. That's one of main the goals of microservices.
I still think your overall suggestion is exactly right. Start with a monolith, and create microservices if and when needed. They likely won't be.
Thanks for the video! Can you please suggest or make once some separate video about best ways on how to test monolith, especially layer between unit and e2e ui tests? Or only monolith way is to use unit tests?
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/
I decided to go with monolith for my latest project and I've been stressing that I should've gone with micro services. All the other devs at the company where I work have been pushing them even though we're definitely not a Google sized company. Thanks for this video, it definitely calmed my nerves.
I am glad it was helpful.
We've just successfully deployed a microservices based Api in AWS. We liked the idea it was highly configurable on a very modular level, and that cost is pay-per-use only, also deployments are naturally a breeze which is an added bonus without setting up a blue/green mechanism manually. Maybe it's not what you would term as the justified solution for it but it's worked out great for us for what is not a massive Api but handles a very large number of requests every day. Modular monolith is something I've been considering for a few new things lately though.
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 Tim
Do you have any series or introduction video about what is modular monolith with the best practices for that?
or should I suggest that on suggestion site?
I would suggest it on the suggestion site. I don't have one yet, but that is an interesting topic.
Too many young programmers lean toward what they consider fun instead of functional. I get it. My early days of programming revolved around what I thought was "neat" code such as segmenting code into thousands of tiny methods/objects so that I never repeat a single line of code. In every case, none of my fun ideas lasted. I learned the hard way what not to do. Microservices is absolutely one of those ideas. It's a bad idea in almost every scenario.
Thank you for your valuable information🎉🎉🎉
You are welcome.
You really just touch the point that I am concerned about all the time, WHY we need Microservices and What is the scale for Microservices need, but here there is a question, what are the criteria used to choose upon ?
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).
I think you touch on some really good points here, especially where beginners are concerned. Scale your work to the business you're working for. Any developers role is to essentially hit business goals at the end of the day - how you do is largely irrelevant to everyone but yourself. (managers and owners certainly (for the most part) have no interest) We have a monolith in our SME business (50 employees) and its fine, in fact the greatest bottleneck of the system is born from development knowledge gaps but thats OK too. No-one is an instant expert from the start and by the time you've become an proficient in something, there's a new breed of technology replacing it - its never ending. Stick with something, run with it but crucially, *make it work for the business*.
Thanks for sharing!
Thanks
Thank you!
I press the like button before watching, thanks , Master
You are welcome.
monolithic is fine. Good for small, medium and large apps who don't have crazy scalability, adaptability or availability requirements mostly centered around hypercomplex application architectures (Amazon Web Services, Azure API, GCP, etc).
Microservices are cool but are for big apps run by big boys (Largest streaming company in the World) on big systems (AWS, Azure, GCP) paid for by companies with all of money (Netflix, Apple, Salesforce, etc).
The question always comes down to: Is doing things the microservices way worth the additional cost and hassle? In almost every scenario I have seen it deployed, the microservice juice was not worth the squeeze. Run it on K8S and you take the horror to a whole new level.
Thank you Tim for priceless information and clearing the air. I was very overwhelmed with the term Microservices being mandatory requirement in many job requirements. Just a question, as you mentioned write loosely coupled monolith applications. Does having many separate layers or projects in one solution with proper DI and unitOfWork implemented is considered loosely coupled as well ?
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).
Hi Tim, I like what you say and I think you also have in mind the idea of using in the monolit blazor and not frontend frameworks like angular. But the guys that are indoctrinated with only microservices will scream like crazy :). Maybe soon you can make a video and advice us what aproach a dev should have when he needs to fight tech-leads and architects that are not doing the right thing. Thank you!
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/
We've come to the exact same conclusions in our organization (with also the same human capital issues) and are already in the process of phasing out complexity and returning to simplicity and lower technical debt.
Thanks for sharing!
While I generally agree, It is easier to work with microservices when you build new features. If you start it right, it forces you to think harder about the architecture and you will be forced to decouple your components whereas with a Monolith, there is far greater temptation to skip this especially under high pressure to deliver.
When stating it is a disadvantage that a micro-services have more points of failure, this is in fact an advantage of microservices. The failure of 1 micro-service should not impact other micro-services, and therefor the failure has less impact. The separation of concerns that is brought by micro-services is a great advantage over monoliths, this is not a disadvantage of micro-services, it is a disadvantage of monoliths.
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 like this opinion; Microservices is compilated as unnecessary. Thank you so much.
You are welcome.
Microservices is a great way for service providers and consultants to make a lot of money by encouraging needless complexity. Let the buyer beware.
For sure.
Is there a way to start with a monolith and refactor into microservice as needed? Or is it too much work and not worth it?😂
Sure. And in fact, I would recommend that. If you REALLY find that you need microservices, you will probably have a couple key areas that jump out. Make those areas microservices but keep the rest of your monolith. But wait to optimize until you need it rather than prematurely optimizing and causing issues.
@@IAmTimCorey This makes total sense. Only optimize as needed. You rock!
I have seen a bunch of people speaking about and doing microservices courses, looks like this a trending topic I haven't too much about Monolithic Architecture, how can learn more about Monolithic book, courses o TH-cam channel recommendation?
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.
Hmm could I get an opinion on a 3 tier system over a monolith. We a web application but also have the system to server mobiles. Generally I use monolith as default.
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)?
In my opinion, this portrayal of the importance and role of micro-services is not completely accurate. It is definitely not only large tech companies that need micro-services. I have seen small companies that desperately needed to change their monoliths to micro-services. When comparing monolithic to micro-services, all benefits and disadvantages should be considered, not only the few mentioned here. A company might not obviously need the benefits of micro-services right now, but things change, and micro-services future-proofs and provides more business agility. The disadvantages of micro-services listed here is also not completely accurate, by stating the complexity of implementing Kubernetes/containerization. In fact, for micro-services I would recommend Azure Durable Functions running serverlessly - this is really easy to implement, and has great cost saving and other advantages over other micro-service implementations. Then there is also Azure Container Apps, which is also good and easy to implement. Modernization is simply the breakdown of larger components into smaller micro-services, and in my opinion, all companies could benefits from this. It is the new way.
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/
Is it a good idea to deploy 3 tiers web app to a k8s env？
No, I don't think so. It isn't designed for that and you aren't getting value out of doing so.
Where so Azure functions fit into this? By the way, 100% agree that micro-services are tough and rarely the way to go.
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).
What about modular monolithic or macro services?
I covered modular monoliths in this video.
Just so we are clear.. When your talking about a Monolith, your not talking about the Front end project/API all in one project/deployment. Your strictly talking about the API project being a monolith correct.
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.
Make spaghetti or make lasagna
Now I'm hungry.
monolith on itself are almost always created as a spiderweb of references between the different projects in a solution. This in my opinion makes the monolith more complex then the architecture of microservices. I still agree that microservices in total are more complex then a monolith but in my opinion mutch less chaotic complex.
I love microservices due to the maintainability of the code. A solution is way smaller and easy too manage. Testing your one small service and replacing it, is made way easier. I understand clean code and all, but i barely see this in a monolith solution. So most programmers i see don't really have the skills to create a monolith in a modulair way. I see this way more often when the microservices architecture is used as they are more forced to be 'modulair'.
You are talking about one man's army in big businesses. I work for 5000-300.000 busnisses and they have multible teams for this. So our experiance in how a company handles IT seem too be very different. This seems to be in my opinion the reason for our different in opinion
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.
Always late to the party
hm, it depents, is the only viable answer, isn't it?
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).
I think it depends, for example if you want to scale your app and you have a large user base then microservices is the way to go. That said it’s definitely more complex and way more expensive than a monolith.
For most ppl monolith is the way to go.
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 😃.
If devs knew better how to use better modularity in their monoliths (trending term modular monoliths) they would probably realise they don’t really need to distribute their modules or turn them into microservices. The big pitfall to watch out for is lack of ACID transactions across database updates once you go full microservice. Having multiple databases all on same instance still allows ACID transactions, e.g. using MSDTS or the like. But split the databases with a microservices architecture and you typically lose this capability, with likely support-intensive consequences with data loss due to eventual consistency (in other words, a lack of consistency).
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.
Obviously a microservice is not a service for DI, consisting of a view lines of code only, like trimming strings.
Since I don't know what a microservice is, I cannot continue. I'm just reporting, what viewers you reach here.
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.