In the early days of your project, everything was great: the small code base was easy to understand, you could add features and fix bugs quickly, you could verify the whole app was working properly with just a few manual tests and you were able get a new version up and running any time your boss asked to show your progress.
A year later, your customers are loving your app, but now that your team has grown and you have to deal with thousands of lines of code, things are not fun anymore:
There must be a better way, right? After reading a few blog posts and watching some YouTube videos, you realize you are suffering from a case of monolithic hell, and you keep hearing that the way to get out of this mess is to adopt a microservices architecture.
Microservices are an architectural style that structures an application as a collection of autonomous, loosely coupled services that are modeled around a business domain. Each microservice is focused on doing one thing well.
A microservice is small enough that a single feature team can own it. Small team sizes promote greater agility. Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.
A team can update an existing microservice without rebuilding and redeploying the entire application and roll back an update if something goes wrong. In traditional applications, a bug found in one part of the application, can block the entire release.
My name is Julio Casal. I'm a passionate software engineer with almost two decades of experience building all sorts of applications and systems based on the .NET platform.
I like to continuously explore the latest software engineering trends and practices and use them to solve real world problems.
I believe reducing complex concepts into simple step by step instructions is incredibly valuable and helps to make coding accessible and fun for everyone.