These days only the lazy will not talk about moving from a monolithic to microservice architecture and great advantages of doing this. Guess what? We also won’t stay aside.
We’re big fans of microservice architecture and helped our clients to move to microservices from its first days. But in the tech world, there is no black and no white.
Every decision (and especially such substantial as moving to microservices) shall be well thought through from the perspective of your business needs, expertise, team size and other resources, time constraints, etc. To help you make the right decision, we’ve prepared this honest, bias-free microservices’ pros and cons analysis.
What are microservices?
Microservices correspond to a range of small independent applications (designed around particular business domains or problems), that communicate between each other as well as outside users via APIs to create a larger system together.
Therefore, a microservice architecture is the way of building large complex applications by dividing them into smaller chunks (=apps) in order to make the system easy to understand, alter, test and fix.
Microservices came as a lightweight, easy-to-scale alternative to so-called “monolithic” apps where all functionalities are tied into a single unit and are based on a single platform.
But does it mean that microservices is a cure-all and your only choice? Let’s have a closer look at the pros and cons of microservices.
Benefits of microservice architecture
Separate chunks of the system are autonomous and thus can be modified and released fast (without breaking other parts of the application), and ensure continuous delivery of your product.
Microservices improve modularity, make a product more flexible, and new functionalities and integrations with various systems and devices – easy to add. We explained how this helped one of our clients to transform their product in this case study.
Teams’ flexibility and independence
Microservice architecture makes it possible for a developer (or a team) to work on their apps independently, which leads to less bureaucracy and organisational mess when making architectural or technical decisions.
Smaller pieces of code that microservices consist of are easier to understand and harder to screw. This fact simplifies developers’ daily work, reduces the risk of fatal mistakes, makes onboarding for new team members less painful. Besides, testing a single simple part separately from the whole systems allows to identify and fix bugs quicker.
Microservices can be deployed as containers to any infrastructure. Thanks to that you can optimize the app’s efficiency, its infrastructure and maintenance costs. You can scale separate apps according to the business needs and pay only for resources that are actually being used.
Unlike monolithic apps that share the same code base, microservices can be written in different languages and still communicate successfully among each other. This means you have a wider pool of technologies to choose from in order to solve a given problem.
Drawbacks of microservices
More management and unification efforts
Microservices work well when everything around them is organised well. But in practice teams’ independence and freedom often cause a mess within approaches, multiple libraries and database versions. Compared to monolithic apps, microservices require much more management and unification work, hours spent not on a product itself but organising a working environment around it.
Being independent for teams comes with a price, as it makes it harder to work together on correlated features.
Whereas testing services in isolation becomes easier, running system or integration tests and ensuring all services work together is often more troublesome. It gets complicated by a number of apps (and a need to have a thorough knowledge regarding all of them), dependencies between them, and organizational issues, like finding an idle timeslot for testing the whole system.
More areas of expertise required
Moving to microservices require more areas of expertise. For example, good knowledge of domain analysis and domain-driven design is needed to divide a monolithic system into separate domains that microservices can be built upon. For further smooth functioning, the team needs to be good at observability and monitoring. For infrastructure optimisations – DevOps specialists are needed.
How to find out if microservice architecture is a good fit for your product?
Looking at all of this, we can say that in theory microservices certainly benefit complex products with ongoing functionality and dependencies growth, as well as scaling needs. But only when implemented wisely. Every case is different and moving to microservices doesn’t guarantee you have the same success as other companies.
“People try to copy Netflix, but they can only copy what they see. They copy the results, not the process.” Adrian Cockcroft, AWS VP Cloud Architect, former Netflix Chief Cloud Architect
At the same time for uncomplicated solutions, or when resources are limited, monolith architecture could be a more reasonable choice due to its simplicity.
A good idea for companies with resources constraints (like many startups for example) can be a modular monolithic architecture that is easy to start with and can be later transformed into microservices if there is a need for it.
Overall, deciding on a software architecture at the beginning of a new project is a topic that deserves a separate blog post. Let us know if you’d like to hear our thoughts on that in the comments below.
* * *
Designing your architecture is both business and technological matter. Moving from monolithic to microservices architecture makes some things easier, but other things more complicated. Keep that in mind and weigh all the pros and cons to see what will be more suitable for your business at this certain stage of development. We hope this blog post will help you make the right choice.
Whenever in doubt or in need of more tailored advice, don’t hesitate to request a consultation with our specialists. For more free tips and recommendations read our blog.