Microservices, the good, the bad and the ugly

The popularity of microservices has recently been on the rise. The big shift to this modular architectural style is happening because they can solve many current IT challenges such as increasing speed, scalability of applications and rapid test processes.

What are Microservices 

Microservices are an organizational and architectural approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams.

Services are built for business capabilities and each service performs a single function. Because they are independently run, each service can be updated, deployed, and scaled to meet demand for specific functions of an application. 

With a microservice architecture, an application is built as independent components that run each application process as a service. All these services communicate via a well-defined interface using APIs. 

Companies can easily run into trouble if they are unable to scale monolithic architecture that has developed over time, if their architecture is difficult to upgrade or maintenance becomes too complex.

Microservices can be the answer to this problem, as they break down complex tasks into smaller processes that work independently of each other.

By using the approach of microservices architectures it makes applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features, which nowadays time and innovations are those that we all value more than ever.

Microservices represent an increasingly popular style of application architecture. Viewing it from a DevOps standpoint, they are a mixed blessing due to the relative ease and reduced liability of deploying individual components coupled with the increased complexity of managing a larger number of components that grow and change on varying schedules.

What is the benefit of microservices 

Microservices work well with agile development processes and contribute in satisfying the increasing need for a more fluid flow of information in general.

Few of the most advantages of microservices;

1. Agility

Microservices foster an organization of small, independent teams that take ownership of their services. Teams act within a small and well understood context, and are empowered to work more independently and more quickly.

This shortens development cycle times. The benefit here is from the total throughput of the organization.

2. Flexibility/independence

One of the main advantages of Microservices is that it allows each service to be independently scaled to meet demand for the application feature it supports.

This enables teams to test the right-size infrastructure needs, accurately measure the cost of a feature, and maintain availability if a service experiences a spike in demand.

3. Easy deployment

Microservices enable continuous integration and continuous delivery, making it easy to try out new ideas and to roll back if something doesn’t work.The low cost of failure enables experimentation, makes it easier to update code, and accelerates time-to-market for new features.

4. Technological freedom  

Microservices architectures don’t follow a “one size fits all” approach. A great thing is that teams have the freedom to choose the best tool to solve their specific problems. As a consequence, teams building microservices can choose the best tool for each job.

5. Reusable code ‍

Dividing software into small, well-defined modules enables teams to use functions for multiple purposes. A function written for a certain service can be used as a building block for another feature.

This allows an application to bootstrap off itself, as developers can create new capabilities without writing code from scratch.

6. Adaptability  

Microservices are only loosely coupled and have a standardized way of communicating with each other. But since they’re built separately, they don’t have to share the same programming language or technology.

This means that each service can be designed in a way that best corresponds to the functions it needs to perform.

7. Resilience ‍

Service independence increases an application’s resistance to failure. In a monolithic architecture, if a single component fails, it can cause the entire application to fail.

With microservices, applications handle total service failure by degrading functionality and not crashing the entire application.

What are the cons of microservices

So, is it a great idea to use microservices always, are they the right solution when it comes to software development? Probably not.

Microservices don't magically solve every scaling issue, sometimes they introduce more problems than they solve.

Here are some of disadvantages when using microservices;

• While much of the development process is simplified with microservices, there are a few areas where microservices can actually cause new complexity. Thanks to the expertise required to maintain a microservice-based application with all its moving parts, complexity increases.

• The need for increased team management and communication to ensure everyone, not just certain engineers, understand each service and the system as a whole.

• Dealing with distributed systems development, deployment, and operational management overheads can be expensive requiring a high initial investment to run.

• Skilled development teams who understand and manage all the services as well as sufficient hosting infrastructure with security and maintenance support are preconditions that microservices need to work properly. Having this said, most enterprises that are currently running monolithic architecture will need to invest in the new infrastructure and developer resources in order to make a successful move.

• A microservices architecture model results in a large number of APIs, all crucial to the operation of the enterprise — so interface control becomes something that is mission-critical. Even though you can make changes to a microservice without impacting the external system interacting with it, if you somehow change the API (the interface), every application using that microservice will be affected if the change is not backward compatible.
  

The ugly of Microservices

Not everything comes with ease, thus here are a few reasons when not to consider using Microservices;

• Microservices, when implemented incorrectly, can cause poorly written applications to become even more dysfunctional.
• Endless documentation in the form of updated schemas and interface documents for every individual component app.
• Dealing with distributed systems development, deployment, and operational management overheads can be expensive requiring a high initial investment to run.
• Increased resource and memory consumption from all the independently running components which need their own runtime containers with more memory and CPU.
• Automation testing becomes difficult when each microservice component is running in a different runtime environment.

Having explained all the above, it’s worth mentioning that someone shouldn’t choose microservices just because it is the hype or because it is used by a popular company or because it was suggested by a popular person.

For most use cases monoliths are still a great solution and even if you start with a monolith you can always split away into microservices if required.

Extra insights when not to use microservices;

• When your application’s scope is small and you know that it’s not going to grow. For well-defined simple use cases a monolith is always the best fit.
• When the time to market is critical for a new application. The initial time to market would be higher for microservices.
• When the size of your team is small or the average experience of the team is less. It's best to start with a monolith when you are a small or inexperienced team.
• When your infrastructure budget is limited. Though on long-run microservice might help to save money, in the beginning, it is going to cost you more.

In conclusion, don’t choose to use an architecture pattern as microservices just because it works for someone else (Netflix, Google, Amazon or Spotify) unless you absolutely have to. Because, not every application has the same requirements.

So, choose a pattern that is appropriate for your use case, scale and requirements. 

For our upcoming articles join us by subscribing to our newsletter.