Microservices: expectations vs. realityMorten Eriksen on
Microservices is lauded and hyped, but what rests behind the ornamentation and pretty words?
Just about any digital 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 intrinsically complex, combining transactions, business logic, personalised 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, modularise, 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 supposed 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 different services. And do you have a contingency plan for what to do if 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.
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 organisation 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 stop the entire system from working.
Reality: Microservices actually make your solution less prone to problems related to single points of failure, as your organisation no longer has a mastodon 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.
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 organisation.
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 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 is a principle motivating 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 now.
Frequently asked questions
What are microservices?
Applications organised as a collection of separate services—as opposed to a monolithic system where every function and code is welded together.
Why do I need microservices?
They make it easier to perform changes to your solution and to keep track of current tech development, while having less chance for a single point of failure.
What are the disadvantages of microservices?
A too fragmentary architecture may lead to a bigger challenge for DevOps, more complex testing, and may require more monitoring.
What microservice use cases are there?
Fraud detection, consistent digital experience, credit checks, effective development, system reliability, attribution, enabling new features on top of existing solution, big data, AI/ML.