Six years ago, I started to work on the first microservices projects. It was a migration from a monolithic solution to something different, to containers and microservices. Fast forward, we are in 2020, and in ALL engagements where I am involved, we have containers and something more - serverless.
The challenges that we had to manage six years ago are, in most of the cases, already solved by mature tools and products that are part of the microservices ecosystem. The natural integration that we have nowadays with cloud vendors (e.g., Microsoft Azure), load balancers, IDE, and debugging tools enable developers to build microservices solutions as if they were merely writing a console application.
a href="https://www.mhp.com/en/die-karriere/mhpromania/" target="_blank"img src="/ui/images/banner/MHPAdv.png"//a
The flip side of all of this is the lack of in-depth knowledge related to how microservices and serverless work. The pressure stakeholders enforce on teams to deliver fast and agile makes them disregard some of the implications and ignore some best practices. For example, I often see production systems where the only tools used for the the maintenance of a serverless solution is a text file and a powerful text editor. It was the right solution in 2015, but nowadays, it creates confusion and can hide the real cause of the issues.
Don't expect to find solutions. I just want to emphasize what we all forget when we work on a serverless or a microservices project. The answers are already available on the market; we need to use them.
I always envision a solution built using microservices and serverless as our human body. The different organs are the containers where there is one primary responsibility and maybe some secondary ones. Organs need to interact with one another. They might work for a while when another organ takes a break, but the dependency between them is high. The interface between them is well defined, and our eyes, ears, mouth, or hands are the integration points with external systems. We know how to maintain our body, communicate with it, or debug it. Often we ignore all of this when we build complex IT systems based on a serverless and microservices architecture.
The future is here! Microservices and serverless are here to stay. There is no competition between them - the future is a blend between the two, where in most of the cases, the piece of code you write can run in both ways.
We should take into consideration that 73% of companies planning to use one of these two approaches already see them as extremely beneficial for building applications. Almost 65% of companies are already building solutions using the microservices or serverless approach.
As you can see, the future is here. There is a high demand from the market, we have the right tools, but we tend to ignore the basic principles we used to respect 5-10 years ago.
I found the ''State of Microservices 2020" report, provided by the "The Software House", inspiring. Using the figures provided by them, I easily identified the things that teams forget to do, to take into account, and to tackle. In many cases, this can make the difference between the success or the failure of a project.
It is not hard to find people with 10 or 15 years of experience in software development. Even so, when you look for people with microservices experience, around 50% of the people have less than one year of experience. If you ask for serverless experience, the figures are even higher. This is one of the root causes why serverless and microservices solutions don't always work as expected, and you end up with difficult and expensive processes, operations and feature enhancements.
The orchestration of such solutions cannot be reduced to the simplicity of a function. The right tools and processes are required, and the lack of experienced people (less than 7.5% with more than five years of experience) makes it hard to do things right from the first iteration.
Almost all the time, a team that starts to work with serverless and microservices is excited and happy in the first sprints. A lot of frustration accumulates, and, before going into production, more than 58% of the teams are unhappy with how debugging and maintenance are done.
This happens because cloud vendors like Azure offer scalable environments, and cloud governance is not done all of time as it should be. Teams are allowed to increase the number of cores or consumption by 40% without providing too many explanations. This can hide performance or implementations issues.
Yes, serverless and microservices improve the efficiency of work and teamwork. Although performance issues can be easily hidden, defining stable contracts among components is not as easy as we think.
More than 65% of the solutions that are using containers are already running inside the cloud. Less than 35% of the current solutions are using their infrastructure. The migration to the cloud can be done easily as long as the solutions used for the on-premises systems can also be found in the cloud as well.
From the start, most of the hybrid solutions and multi-cloud solutions are built around them. Even if AWS Lambda is preferred by 62% of the cloud services solutions, Azure Functions have a big advantage because they can run seamlessly anywhere (e.g., on-premises Kubernetes cluster).
Each cloud provider offers a specific model to build such a solution (e.g., AWS Serverless Application Model). Less than 26% of the projects use best practices and recommendations to build solutions. The rest of the projects are not aware or do not consider them. This is one of the leading causes that can generate additional costs and delays.
If we add the pressure to build multi-stack and multi-cloud solutions on top of it, with the false expectation that teams will be faster because the 'components' (functions) are simpler, this entire context creates the perfect recipe for disaster.
More than 66% of the current systems have internal communication between services, and around 57% communicate with a static frontend. Unfortunately, SSR frontends are not common (less than 27%) when we use serverless and microservices, which can create friction between the backend and frontend teams.
You might say that we should already have standard ways of how to communicate inside such solutions. Yet, the current numbers are saying something different. Even if we use direct communication via HTTP(s) or gRPC in 76% of our projects, we see that around 43% of our solutions use events. If we put 43% side by side with the fact that around 63% of the projects use message brokers, we realize that the technical team doesn't distinguish clearly between what makes an event and what makes a message. This can easily degenerate and create communication and performance issues when you want to use a message-based system to send a high no. of events, or when we expect the persistency of events to be the same as for messages.
Even if we are in 2020, and around 85% of solutions use logs, less than 34% of them are using metrics and tracking information during investigations. This is scary because this information is crucial when we investigate, and the lack of relevant information can hide the root cause of the problems. I don't want to imagine how you can debug a solution that has 30 functions and 20 microservices using only log files. It is not possible. However, understanding the context where an issue appeared is not easy when you don't have metrics (e.g., I/O metrics).
The future needs to bring us fault tolerance and smart predictions for system failure. It can be done only if we collect all the information related to application, trace, metrics, and health checks. There are many tools on the market that can already be used:
Audits can be performed with Falco for abnormality detection
Monitoring can be achieved easily using Grafana or Prometheus (analyze health checks, metrics, counters, and logs)
When you have issues with a container, you should always check the following:
Does the service exist?
Did I run a service test?
Do I have the right bounding between services and pods?
Do I have the right port mapping between services and pods?
Splitting a solution into multiple functions and microservices enables people to throw the responsibility from one team to another. At this moment in time, less than 24% of teams are using micro-frontends, even if from the way of working point of view, it might represent the future of building such solutions.
In general, we have a team per each domain function, managing one or two services. Besides them, we have an aggregation layer and a frontend team that, besides building the frontend, needs to align with all the backend teams, understand the data flow, and consume the exposed functionality.
When we go with a micro-frontend approach, the team responsibility covers all the layers, from data to backend and frontend. Communication inside the team is easier, and the full functionality can be covered, ensuring the success of the team and the project in the end.
The future is here. Not only will serverless and microservices become the standard way to build complex systems, but they will also become industry standards for backend development.
We need to understand the full landscape of serverless and microservices. It includes tooling, debugging methodology and way of working. The classical way of building software might work using the new architecture approach. However, we limit what we can achieve and the way we build, debug and operate such solutions.
by Ovidiu Mățan
by Vlad Precup
