Monoliths, Service Architecture, and Microservices
Monoliths, Service Architecture, and Microservices
There are many discussions about which level of system granulation is the best. We went from monoliths to microservices and back again.
There are many discussions about which level of system granulation is the best. We went from monoliths to microservices and back again. Today we will break it down.. a bit.
The big kahuna, the monolith! Most systems start here, and I would argue most systems should stay here. Monoliths are deployed and developed as a single unit. It contains all the functionality that the application supports, from UI to the database.
Pros:
Early on, simpler and faster development
Performant
Fewer cross-functional concerns, and if there are easier to grok them.
Cons:
As complexity and size increase, so does the agility of the said system
Larger systems changes become more complex.
Monolith is strong, fast, and for most of you, the right choice. However, as time progresses or the application grows (complexity and team), new strategies might make more sense. Respect the monolith.
Now let's venture in the world of distributed systems where things you could have been certain of are no longer so certain. We wrote something here about distributed fallacies it give it a read.
The lesser known service-orientated architecture (SOAs)is slightly different where systems are composed of fully functional units that are loosely coupled. That often don't cross communicate and use a shared database.
Pros:
Improved service focus and boundaries, resulting in better maintainability and testing.
Teams can move faster and in parallel.
Cons:
Overall system response time
Increased coordination and require larger planning effort upfront.
SOAs are great, and if your system is well defined, and you need to move away from a Monolith for reasons, SOAs are a great fit to increase reliability and speed of development for a growing team.
Microservices the big, little m. Unlike SOAs, Microservices are even more fine-grained with one responsibility and generally with their own data boundary.
Pros:
Ease of development and testing of the Microservices.
Increased team agility
Cons:
Complexity of distributed systems
Deployment complexity for multiple systems
Operational complexity of the overall system.
Microservices can be great for the correct problem if you have a growing team and currently evolving application. However, it has shortcomings of increased complexity, and overall tooling and systems need to be in place. It creates a path forward for future growth, but the number of applications currently facing these challenges isn't numerous.
There is always a 'right' way to design each type of service or platform, and as your systems grow, you will always need to change and evolve to solve new problems. Unfortunately, early in your service, you don't know what will be your biggest hit or what might be an unforeseen bottleneck.
Migrations are likely to happen more than once during the life of a system or none at all.