Microservices: expectations vs. reality

Just about any digital project or solution, whether it’s a website, an app, an API, a CMS, or some other service, consists of code running on a server. Some solutions are dead simple, like a static HTML page. Others are vastly more complex, combining transactions, business logic, personalized interfaces and then some.

Traditionally, such solutions have been built, tested, and shipped as a single piece of software, also known as a monolithic system. In the case of microservices, the idea is simply to split this software into smaller and more manageable pieces—hence the word “microservice.”

The purpose of microservices is simply to divide, modularize, upgrade, develop, and deploy said services independently of each other. This kind of software system architecture allows for faster and safer development, as you no longer need to depend on the entire, integrated monolithic system.

Even though microservices can solve many challenges and increase the speed of development, they are not a magical unicorn that will cure all your ailments without effort.

Here are 5 expectations about microservices and their corresponding realities.

1. Chopping up solves everything

Expectation: Fragmenting and dividing your services will solve all your problems with development inertia, system security risks, and deployment delays.

Reality: It is paramount to avoid chopping up your application into too many small pieces.

A system, whether it’s sewn together or consists of microservices, is still a system—with a purpose and a projected functionality.

However, with the microservices approach, you may run a risk of the system becoming too fragmentary, with different technologies on different services, making it difficult to get an overview and maintain and handle code in the long run.

In a worst case scenario, a poorly handled microservices architecture can lead to the very same problems you tried to escape from.

Furthermore, testing can be more complex due to the number of microservices. Even though they are independent in one manner, dependencies must exist between services in one way or another (how else is it supposed to be a coherent system?)—and the more services, the more complex it becomes.

If you experience network and database problems, it might not always be easy to differentiate the various services. And do you have a contingency plan in case one microservice is down? How will the downtime affect the rest of your system?

Microservices may also require more monitoring to see to it that every microservice functions properly, as you now have several services as opposed to one large service.

See also: How to build a fast and modern site with Next.js and headless CMS »

2. Easier for DevOps

Expectation: Introducing an architecture of microservices will make the workday easier for your developer operations (DevOps).

Reality: Microservices may lead to a more fragmented stack, which means more to manage and upgrade, i.e. more headache for your DevOps.

This in turn could lead to increased infrastructure cost, but overall there might be a cost reduction—because the developers come faster into a productive process and get things going faster.

Remember, embrace the DevOps culture, don't ignore it. Enable your DevOps to do more in production, making it easier for your organization to deploy working digital experiences faster.

3. No single point of failure

Expectation: A microservices architecture will reduce the risk of experiencing a single point of failure, i.e. when a part of a system fails, it will not stop the entire system from working.

Reality: Microservices actually do make your solution less prone to problems related to single points of failure, as your organization no longer has a behemoth to deploy and maintain.

However, you need to design with failure in mind, and you need to be able to handle system downtime, slow service, and unexpected responses.

Also, an issue from one microservice may affect another microservice elsewhere due to inescapable dependencies in your system. So be sure to include a proper and thorough routine for diagnostics of errors.

Learn more: Lift your customer journey with rich web front-ends »

4. More productive developers

Expectation: A microservices architecture enables your developers to be more productive and effective.

Reality: This expectation is also quite possible and likely to become reality in your organization.

The reason for this is that it’s easier for your developers to get acquainted with small components than one large-scale system. Just as it’s easier to start gaining knowledge on any topic by reading introductory texts rather than an enormous all-encompassing tome, it’s easier for developers to start coding with smaller components rather than the entire complex system.

When developers work with microservices, the work process can become more agile and lead to continuous deployment. Coding, testing, deploying, and iterating becomes a much faster process, and being able to see handfast results immediately will motivate basically any human being.

Also, while developing and testing microservices, your developers—gaining crucial knowledge and experience continuously—will be able to choose the right tool for the right task faster.

5. Easier to scale

Expectation: It is easier to scale a microservices architecture due to its modular nature.

Reality: Microservices are designed for this purpose.

The microservices don't affect each other as directly as similar services would in a monolithic system, where everything is bound together tightly.

Scaling with microservices will let you easily discover what services need expanding before others, and what services might not be expanded at all for the time being.

For instance, do you need more processing power while logging services are fine as they are? Then upgrade the former and leave the latter alone.

Finally, with microservices it’s easier to find bottlenecks in your system. No longer being blended together in a single, giant system, you can quickly identify red flags in your system architecture of independent services.

***

Are microservices satisfying your expectations, or did reality come in the way? In any case, investigate and research thoroughly before opting in to microservices. Know your needs, don't throw yourself blindly into unknown territory, just because something is popular in any given moment.

First published 2 May 2019, updated 23 September 2022.