To go or not to go micro: the pros and cons of microservices
You’ve probably heard people talk about microservices before. You’re probably sick of hearing about them. Maybe you’re not sure you totally understand the concept. If that’s the case, this week’s Rebel Thinking is for you.
In short, microservice architecture is a method of developing applications or software systems, made up of smaller services which provide a complete business functionality. In other words, each microservice performs one, specific function, and can connect with other microservices. It’s an alternative to more traditional monolithic solutions, where all functional elements are linked together in one programme or application.
Microservices were born out of a need to implement and make changes to software quickly and easily. Now that developers are abandoning monoliths in favour of increasingly popular microservice systems, more organisations are beginning to prioritise the development of products made up of interchangeable, upgradable and scalable parts — all of which fit together kind of like a puzzle. Organisations that are gradually adapting a human-centred mindset, which necessitates a fluid flow of information, may be even more drawn to microservices.
As you can see in the above image, each microservice has its own database, which means that the system is distributed and also improves product performance. However, keep in mind that the user will never fully appreciate the difference between both solutions as, at a user interface level, it’s hard to tell the difference.
How do microservices communicate with each other?
Microservices communicate with one another through APIs — a set of predefined commands, functions, and protocols. Developers can take advantage of API libraries, and in most cases they’re given permission to add new ones and share them with the community. APIs are the common language used to enable communication between microservices and other forms of architecture.
There are many new technologies taking advantage of the rise in microservice culture — Docker, a “software container”, is perhaps the most relevant example. With Docker, and similar platforms like Nomad and Kumbemetes, we can replace traditional web server models with smaller and much more adaptable virtualised software containers. Thanks to easy-to-configure “middleware” software solutions, we can ensure the flow of information between systems is accurate and reduce the risk of losing track of any data.
Let’s take a look at some of the pros and cons of microservices. This should help us explain how we, at Good Rebels, determine which form of architecture is right for a team or organisation.
The pros and cons of microservices
There is no easy way to identify which form of architecture will work best for your team — it’s important to assess all the advantages and disadvantages that come with both monoliths and microservices, as well as common pain-points. At Good Rebels, we’re used to working on both agile and more traditional projects — and as such we don’t believe that any form of architecture is inherently ‘better’ — it all depends on the project itself. It’s quite common to start with monolithic architecture and then gradually expand, in a sequential and controlled manner, adding more services as you go along. This way, you can reduce costs and stay competitive.
Of course, the initial scope of work has to be taken into account. Our recommendation, if you want to reduce costs and limit the amount of the time required to complete the project, is to start with a low cost monolithic model and pay close attention to the evolution of the project so that if additions need to be made, they can be made naturally and only when required.
If you’re dead set on microservices, you should first familiarise yourself with the pros and cons of this form of architecture:
Pros
- Versatile — microservices allow for the use of different technologies and languages.
- Easy to integrate and scale with third-party applications.
- Microservices can be deployed as needed, so they work well within agile methodologies.
- Solutions developed using microservice architecture allow for fast and continuous improvement of each functionality.
- Maintenance is simpler and cheaper — with microservices you can make improvements or amendments one module at a time, leaving the rest to function normally.
- The developer can take advantage of functionalities that have already been developed by third parties — you don’t need to reinvent the wheel here, simply use what already exists and works.
- A modular project based on microservices evolves more naturally, it’s an easy way to manage different developments, utilising the resources available, at the same time.
Cons
- Because the components are distributed, global testing is more complicated.
- It’s necessary to control the number of microservices that are being managed, since the more microservices that exist in one solution, the more difficult it is to manage and integrate them.
- Microservices require experienced developers with a very high level of expertise.
- Thorough version control is required.
- Microservice architecture can be expensive to implement due to licensing costs for third party apps.
It would seem that the pros outweigh the cons, however there are certain problems inherent to microservice based solutions (cost, efficiency, response times, etc.). The most important thing to consider is which solution is best suited to the needs of the specific project and which solutions will best help us achieve our objectives.
Mono vs. Micro
Additionally, in order to determine which type of architecture is best suited to the needs of a specific project, we need to answer the following questions:
- How large is the team? A larger team can be more suited to microservices.
- Are we currently dependent on a monolithic service?
- Is there someone in the team with the expertise to facilitate microservice architecture?
- Are we building for a single audience? Microservices are most useful when you’re building for a more diverse consumer base.
With a large and evolving system (think Google, Netflix, Amazon, Uber…etc.), microservices are clearly the better choice. But realistically, does your project compare to an organisation as vast as Google?
We also need to consider the future of microservices — how will they evolve and how will software solution developers benefit? Instant pay through messaging apps, for example, is made possible thanks to integrated and more centralised applications which allow users to place orders or make reservations without having to leave the application itself.
Microservices are like departments within a company; each department has its own role, its own specific set of skills. Following in this same analogy, APIs are like those employees with expertise in a number of different areas — they’re responsible for assisting in the implementation of protocols or specific tasks across different departments. The company can, whenever necessary, make use of these skilled co-workers to achieve a specific result. Microservices depend on organisational culture, and so do those who wish to implement a microservice system. In order to determine whether microservice architecture is right for you, you must first assess your organisation’s needs, resources and culture.
Written by Daniel Requejo and Fernando Villanueva.
