It’s all the craze nowadays: hyped as the “Agile of Systems Engineering”, microservice architecture is an approach to running servers that lets many independent services share the same access to the server’s resources (this is in contrast to “virtualization”, which divides the server’s resources into separate parts). As you may be aware, many companies, including tech giants like Google and Amazon, have eagerly adopted microservices, and the industry just can’t praise them enough. So what makes them so great? Below, we lay out for you what to love — and what to avoid — about microservice architecture.
Read anything about microservices, and you’re sure to hear the word “monolith” tossed about. A monolith is a system that’s packaged all together, with few or no interchangeable parts — something that would be used in virtualization, like we mentioned above. The problem with a monolith is that as you scale the system, the cost skyrockets, and you end up with a giant program that gets more and more unwieldy. The bigger the project, the larger the team you need to work on it, and we know as well as you do the disaster that comes with hundreds of developers all trying to work with the same code base.
GOOD: Microservices allow each part of your solution to be worked on, changed out, and distributed separately, simplifying upkeep and making development a lot less of a nightmare.
Microservices allow for fast updates
No more waiting until all departments have their components ready to package into your next big release — microservices let you send out updates and fixes as soon as they’re ready, as each component can be swapped out as needed. And if something breaks, there’s no need to worry about data loss; all you need to is roll back the problematic microservice.
GOOD: Microservices can be fixed separately, which gets rid of bottlenecking and weighty updates.
Microservices complicate development
While it may be nice to be able to break up your development team to handle the different parts of your project, that distinction makes it harder for the different teams to communicate and work together. What you get is often a project that’s been developed in many different ways; when you need to move responsibility from one microservice to another, things get a lot more complicated, especially if different parts have been written in different languages. Additionally, testing can be a pain when parts that work on their own don’t play nice together.
BAD: Microservices hinder communication; a monolithic structure lets you keep development centralized.
Microservices can get too ‘micro’
When you divide your system into too many separate parts, you end up with the ugly side of microservices: “nanoservices.” Each part needs to communicate with the others. Because each part is separate, communication between parts takes a lot longer than it would in a single program. Having too many small services, then, deals a huge blow to your system’s efficiency, cancelling out any usefulness of microservices.
UGLY: Going overboard with microservices leaves you with a slow system and no benefit.
The final word? Microservices are a powerful new approach to deploying systems. That being said, they’re not a silver bullet, and have some serious drawbacks if used carelessly. Before deciding to transfer your system to a microservice architecture, make sure it would help — not hinder — your project’s efficiency. Here at Ciklum, we understand systems; working with our consultants, Ciklum can help you decide on a structure that best fits your needs.