What are some of the disadvantages of microservices?
Microservice-oriented architecture has its benefits, but it comes with some drawbacks as well, such as data translation and debugging. Let's go over the big four.
Working with microservices offers some clear advantages. For example, a team that adopts microservices can onboard developers quickly and support a flexible release schedule. But microservice-oriented architecture (MOA) does come with challenges. Here are the key disadvantages of microservices to keep in mind:
- Operations configuration is more complex.
- Requires automated deployment.
- Requires translation over context boundaries.
- Difficult to debug, particularly in an asynchronous environment.
Complex configuration
Although a microservice is isolated and self-contained, it does need to be continuously configured, particularly as it's deployed from development to test and onto staging and production. This configuration can be quite complex. And, if a microservice needs to use other microservices, these bindings need to be configured at deployment or even runtime.
A key tenet of microservices development is the externalization of configuration. Developers should never hard code configuration information directly into a microservice. Information, such as passwords and authentication tokens, is particularly verboten.
In monolithic applications, configuration information is confined to one place. In an MOA, configuration data can be found in a number of places, such as Kubernetes Secrets for access information or Consul for service discovery definitions. Supporting a large scope of configuration activity increases complexity, particularly when an application is made up of hundreds, if not thousands, of microservices. Hence, there's a tradeoff.
This article is part of
An A-to-Z guide to a microservices architecture transition
You get flexibility, but one of the disadvantages of microservices is that you have to accommodate more configuration. The trick is to make sure the tradeoff is worth it.
Automated deployment
While microservices bring a lot of value to applications that operate at web scale, they are more complex to test, deploy and maintain. This is not manual work. It must be automated. The sheer volume of services in play in enterprise-level microservice-oriented applications demands it.
Thus, companies intending to adopt microservices architectures need to know automation technologies such as GitHub, Jenkins and Terraform. And this means having personnel on hand with the expertise to create scripts that drive automation. Implementing automation in a consistent and comprehensive manner is an enormous undertaking, requiring significant investment of time and resources. But that's the price companies pay for the benefits of microservices.
Context boundary translation
While it would be nice if all microservices in an MOA used the same data structures and communication protocols to communicate among themselves, this is often not the case. For example, it's entirely conceivable to have a REST microservice that communicates via HTTP/1.1 try to communicate with a gRPC microservice that uses HTTP/2. The context of the microservice using REST is different from the microservice using gRPC. There's a fundamental incompatibility.
One way to accommodate the incompatibility is to put a translation mechanism in place. One such mechanism is a translation proxy such as Envoy. See the figure below.
Data translation among microservices can also be a challenge. One service's zip code might be another service's postal code. Getting data structure to line up is a challenge.
Data context translation is a problem that's been around for decades. Enterprise technologies such as BizTalk Server and IBM WebSphere Transformation Extender were designed to address it. Regardless of how you solve the problem, you will have to solve the problem.
Monolithic applications store all this data in a single database, which minimizes the issue. In an MOA, the problem is magnified. Each microservice will need to be accommodated. For an MOA that has hundreds of microservices implementing data translation between them, it can be a significant amount of work.
Distributed debugging
Among the disadvantages of microservices is the difficulty of debugging an MOA that has hundreds of microservices interacting in concert. Tracing the path of a request into and out of an MOA is difficult because each container is independent. Unless there is a comprehensive monitoring strategy in place, the MOA is opaque. Logging the internals of an MOA provides a limited view, but MOA monitoring needs to see the big picture.
Open source projects such as Jaeger and Zipkin help to debug interservice activity using distributed tracing. And there are commercial ones as well, including Datadog, Dynatrace and Wavefront. Regardless of the products you use, development staff needs a monitoring strategy in place that can observe internal and external activity with the various microservices that make up the MOA. Without it, you're flying blind and debugging will be difficult.
