The Ultimate Truth: Microservices Advantages and Disadvantages

“Disadvantages of microservices? Seriously? Oh, c’mon! There are none.” Yet they exist. And today we’re going to tell you the whole truth about microservices. The good, the bad and the ugly, all in one article.

Microservices architecture. Definition and basic info

If you’re pretty familiar with the basic info about microservices, just skip this paragraph and have real fun reading about their advantages and disadvantages in the following sections. For those who need some clarification we’ll leave the definition and an explanatory infographics below.

What is ‘microservice architecture’?

Microservices architecture is an architectural style in software development. A microservice-based application consists of multiple loosely coupled microservices each of which serves different purposes (functions). Microservices can be built, deployed and tested separately, without affecting one another.

Microservices architectural style is opposed to the monolithic architecture, where an application is represented as a single whole. The application modules are tightly interconnected, share the same source code and a database.

*Note that the above picture gives only approximate visualization of the monolithic and microservices architectures. In a microservices-based application, UI often undergoes decoupling too (microfrontends) and, as a rule, does not communicate to the services directly. There are several generally accepted microservices architectures. If you’d like to familiarize yourself with them all, see martinFowler.com for more.

Advantages of microservices

Now to the fun part.

Microservices architecture has tons of advantages and mainly because of that there is so much fuss about them nowadays. Let's have a look at each of the advantages that microservices offer and briefly discuss them.

Scalability

Scalability is often a key reason why businesses decide to switch to the microservices architecture. What’s more important, using microservices you cannot only scale the whole application easily; rather, you are now enabled to scale one specific function (or two, or three, whichever fits your circumstances). It’s a great thing because:

•  now you can scale faster and
•  save money.

Furthermore, if you seek dynamic scaling, microservices are the right option for you. Microservices architecture allows scaling the capacities up and down in response to changing demand. In a monolithic application this is a very hard thing to do.

BTW, here’s a great blog post on scaling with microservices, if you’re interested in it.

Quick development

In microservice-based applications services are loosely coupled and are far more independent of each other than in a monolithic application.

Say, you need to launch a new feature FAST. No problem. Write it, test it alone and off you go in production! As services have no brittle interdependencies, you no longer have to test the whole application, only the service in question.

This is another great advantage of this architectural style, as it promotes quick development and agility.

What makes application development even quicker is microservices reuse (as contrasted to the monolith where components interdependencies are stronger and reuse is often impossible).

Fault isolation

Oh, that was a real blessing when someone came up with fault isolation. What does it mean for the software development process?

An error created inside a microservice, stays within it and, in the worst-case scenario, affects only one specific service functioning.

For example, your team is ready with a new functionality. After some thorough testing you go into production and something goes seriously wrong. In case your application is built as a monolith, you’ll have to roll back the whole system, while in a microservice-based application the team rolls back/replaces just a specific problem service.

Feature-toggling

Feature-toggling is a great blessing of microservices-based applications.

For those of you unfamiliar with feature-toggling, we’ll leave a short explanation of the notion.

Imagine you want to develop a new feature, but you’re not 100% sure if your users are going to like it. So you need to hide it safely in case it’s a failure. Or else. You’re working on a new super-wow feature and want to avoid some painful feature commitment. It is here where feature-toggling comes in handy. 

Feature-toggler is referred to as a Boolean flag which is stored in a database and contains information about the feature state - whether it should be on or off. 

With feature-toggler at hand, killing the service in a microservice-based application that isn’t running as planned is as simple as that. Introduce a function, run A/B-testing and turn it off if it behaves strangely. 

Freedom in choosing a technology stack

Microservices allow choosing a technology stack that will stay relevant and fresh for years to come. No need to adjust to the old dogs currently used on a project and, frankly speaking, living out their remaining days.

Microservices make it possible to pick up a specific programming language or a framework (or its version) for a specific microservice. Although experts do recommend not to combine too many different technologies within one microservices based system, development teams all over the globe still have more options than they used to.

Agility

Software development must be agile to enable efficiency, dedication and commitment of all the team members. That's why speaking of the advantages of microservices, we could not but mention agility as its huge plus. Again, to make things clear for you, let's have one more example.

In a universe of monolithic applications, teams had to wait for months to deploy a new feature. Why so? With a monolith any changes require a full build and deployment of the entire application and that’s a lot of time. So, team 1 has to wait for teams 2 and 3 to run their new shiny features. That's a waste of time and commitment.

On the other hand, with microservices  you only need to redeploy the service(s) you modified. 

Moreover, due to brittle interdependencies between the modules, same interdependencies appear between the development teams. Team 1 can no longer implement significant changes to the benefit of the entire application only because the other teams ban this innovation (due to some reasons or another).

In case you opt for the microservices architecture, you also opt for small agile teams that are free to innovate and give this world marvelous functionalities.

Find how microservices promote agile development at Amazon here.

As we are approaching the end of the Advantages section, I’d like to mention that this list of advantages is nowhere exhaustive. Here I’ve mentioned the ones that I personally consider fundamental. 

Microservices give you a whole array of other somewhat secondary benefits, like atomic deployment. Yet, for some developers atomic deployment is definitely a killer feature. So, it’s a matter of perspective, of course. 

It’s time to see what’s on the flipside.

Disadvantages of microservices

Every brilliant technology or approach has its disadvantages and microservices is no exception. Although their advantages outweigh the drawbacks (sorry for the spoiler), you have to know what problems you'll face.

Complexity

Monolithic applications are much easier to run and manage than those built using microservices. Have a look at the two pictures below.

This is an example of a monolithic application architecture.

This one is a microservices-based application.

As you see, the microservices application is much more complex, it has more components to deploy and manage. Though microservices enable greater performance and higher system scalability, complexity is the price to pay. And this issue implies one more thing, that should be considered separately.

Higher qualifications

As now your development team will have to deal with a more complex system, needless to say they should have higher qualifications. Given that, consider sticking to a limited set of technologies to be used for your microservices system development. This will help you deal with recruiting issues, as finding 10 gifted developers coding in 10 different languages might be a problem.

Check out this blog post for some tips on how to find and hire the best microservices developers.

Stalled start

A microservice-based application generally requires more time to launch. The project goes through a long preparation stage, coordination of contract terms,  development of a wrapper, etc. A monolithic application, as a rule, doesn’t need all that staff and starts way quicker and easier.

Overhead

Remember, in a monolithic system you had a team of, say, 20 engineers who did all the job together. With a microservice-based application, this principle doesn’t work. 

To develop a microservice application, you hire several teams (incl. A PM, developers, testers, UI/UX designer, etc.) each in charge of a specific microservice. This causes an overhead which, in the end of the day, may result in higher costs and longer deadlines.

Lack of integrity

Once again, a microservice-based architecture means there are several teams in charge of the application. Each team follows its own development methodology, workflows and prefers one technology over others. As a rule, such lack of integrity leads to higher maintenance costs. 

DevOps and CI/CD practices

DevOps and CI/CD practices are great things, by the way. They can hardly be called disadvantages of microservices, yet they are pretty hard to master. That's why they ended up here, in this disadvantages section.

Microservices won't run without DevOps. Even before you start decoupling your system into microservices and even before you think about migrating them, you'd better give a good long think to the infrastructure. And DevOps is all about infrastructure and its smooth automated running.

What about CI/CD practices? They are everywhere now and it feels a little bit weird to talk with you about such obvious things. Yet, if you're a bank or a financial organization, you may be still sticking to the old-days practices for some safety reasons. No judgement, just remember - CI/CD has proven to be safe and reliable. 

Wrapping it up

Cutting a long story short, we must admit that nothing's wrong with monolithic applications. They are reliable, well used and tested. Seriously, if you are not planning to grow big in time, push that microservices thing out of your head. They are complex and most probably will cost you more. So, if you don't need to worry about scalability, you don't really have to worry about implementing microservices either!

However, if you're a relatively big company with grand plans for the future, give the microservices a green light and you won’t regret it a single minute! 

Go through the benefits of microservices once more, if you have your doubts regarding this architectural style. Yes, the disadvantages exist, but luckily the benefits of microservices outweigh the issues they might cause.

If you're looking for more detailed information and some practical guidance on the topic, feel free to leave a request for a whitepaper "How to migrate to the microservices architecture".

In case you'd like to have another dosage of theory, check out some great articles on our blog and don't forget to leave your feedback in the comments!