While cloud-native architecture is gaining popularity, not everyone is eager to adopt it. One of the main reasons is the potential drawbacks of microservices, a core component of cloud-native architecture.

Cloud-native architectures using Docker and Kubernetes deployments are currently highly favored. Teams opting for microservices can benefit from several advantages:

• Microservices offer flexibility in selecting different architectures, languages, processes, and tools.
• They embody established best practices like domain-driven design and event-driven architectures.
• They support a flexible and potentially quicker release schedule.
• Technologies like Docker and Kubernetes, which support microservices at runtime, can run on standard hardware.

However, it's essential for app development teams to recognize that microservices come with notable drawbacks. Before transitioning from a reliable monolith to numerous smaller, functionally identical micro-components, it's crucial to comprehend these challenges associated with a microservices architecture and how to mitigate them—or accommodate them.

The top 10 drawbacks of microservices can be categorized as follows:

1. Increased topological complexity.
2. Requirement for automated deployments.
3. Complex integration overhead and dependency issues.
4. Challenges with data translation and compatibility.
5. Potential for network congestion.
6. Decreased overall performance.
7. Higher associated costs.
8. Complexity in logging and tracing.
9. Testing and debugging complexities.
10. Organizational inertia.

1. Increased topological Complexity

When a monolithic application is divided into a subset of independent microservices communicating over a network, it significantly amplifies the architectural complexity.

For instance, consider breaking down a single monolithic application into 10 microservices. This necessitates updates to various tasks:  

• Scaling: You need to be able to scale10 applications instead of just one.
• Security: You need 10 API endpoints instead of one.
• Version control: Administering 10 Git repositories instead of one.
• Building: You need to build 10 packages instead of a solitary one.
• Deployment: Deploying 10 artifacts instead of just one.

Managing numerous smaller programs proves more challenging compared to a single, cohesive monolithic application. This complexity stands as one of the primary drawbacks of microservices.

2. Requirement for Automated Deployment

Microservices offer significant benefits for web-scale applications, yet they also introduce complexities in testing, deployment, and maintenance. Manual handling is not feasible; automation becomes imperative due to the multitude of services in enterprise-level applications.

Companies transitioning to microservices architectures need to integrate automation technologies such as GitHub, Jenkins, and Terraform. Additionally, staff members need proficiency in scripting.

Implementing automation consistently and comprehensively requires a substantial investment of time and resources. However, this investment is necessary for companies to reap the rewards of microservices.

3. Complex integration overhead and Dependency issues

Standardizing data exchange contracts between microservices entails significant additional effort.

Microservices are developed and deployed independently within isolated containers. During runtime, these isolated and independent microservices must communicate with each other, necessitating increased integration of RESTful endpoints and standardized JSON or XML exchanges.

Moreover, managing the interdependencies among microservices poses a substantial challenge. RESTful endpoints are particularly fragile, as changes to one component can lead to unintended consequences for others.

In contrast, in a monolithic application, components interact directly through Java- or Python-based API calls, eliminating the need for a common data exchange format or RESTful APIs. Additionally, all interactions are type-checked and validated at compile time.

4. Challenges with data translation and compatibility  

It would be ideal if all microservices utilized uniform data structures and communication protocols, but this is frequently not the reality. For instance, it's plausible to encounter a scenario where a REST microservice attempts to communicate with a gRPC microservice, each employing different HTTP protocols. This presents a fundamental incompatibility.

One approach to address such incompatibility is by implementing a translation mechanism, such as a proxy.

Data translation within microservices presents its own set of challenges. What may be interpreted as a ZIP code in one service could be recognized as a postal code in another.

Data context translation has long been a concern, persisting for decades. Monolithic applications mitigate this issue by storing all data in a single database. However, microservices architecture exacerbates this challenge. With potentially dozens or even hundreds of microservices within an application, implementing data translation between them poses a significant hurdle.

5. Potential for Network Congestion

Microservices communicate via RESTful APIs, exchanging data in JSON and XML formats over the HTTP protocol. Introducing microservices often leads to increased network activity, resulting in network congestion.

However, most microservice communications occur within private, local subnets where network bandwidth can be readily expanded. However, the high volume of XML and JSON traffic over the network contributes to another drawback of microservices: performance implications.

6. Decreased Overall Performance

Microservices entail higher resource consumption compared to a comparable monolithic architecture, requiring more memory, clock cycles, and network bandwidth.

In a monolithic application, all components operate within a single process, with interactions occurring at the hardware level. Components invoke each other through standard method calls, resulting in minimal performance overhead. Moreover, components sharing the same process instantly access shared data as it resides in memory, reducing latency.

Comparing Monoliths with Microservices:

Imagine the difference between interactions within a monolithic application and interactions between microservices:

Compared to the direct communication between components in a monolithic architecture, microservices involve more steps and rely heavily on network communication. This leads to significantly higher overhead and slower performance.

The performance and resource usage drawbacks of microservices lead us to the next disadvantage, which is cost.

7. Higher associated costs

Following decomposition, a monolithic application fragmented into multiple microservices necessitates:

• More total memory for operation.
• Replicated resources when employing multiple containers or VMs.
• Additional bandwidth consumption for invoking RESTful web services.
• Increased CPU cycles for sending, parsing, reading, and reassembling JSON files.

Enterprises today pay for cloud-based computing follows the strategic pay-as-you-go. Greater usage of CPU or memory by an application result in larger cloud computing expenses.

The heightened resource requirements to sustain a microservices architecture compared to a monolithic one translate to escalated costs, representing a significant drawback to microservices.

8. Complexity in logging and tracing  

Cloud-native applications are commonly deployed within Kubernetes clusters where ephemeral containers furnish the requisite microservices runtime. However, the transient nature of microservices, particularly across multinode networks, renders logging, tracking, and auditing exceedingly challenging.

If the Docker container hosting a microservice shuts down, log files are promptly lost unless a background daemon process actively transfers the log data from the container to a reliable storage destination. While tools like the open-source Fluentd help mitigate this issue, it remains a concern.

In contrast, a monolithic architecture typically features a single server folder where all logging, tracing, and auditing data is stored, often with built-in log rotation mechanisms. Managing logging and tracing is considerably simpler with a monolith.

The additional effort required to manage log files, trace files, and audit data across a cloud-native cluster constitutes one of the foremost disadvantages of microservices architectures.

9. Testing and debugging complexities

Identifying and resolving issues in microservices architecture presents challenges akin to those encountered in trace file and log aggregation. When a failed request traverses multiple microservices hosted within isolated runtimes, pinpointing the precise location and cause of the failure can be arduous. In contrast, troubleshooting in a monolithic application follows the path of a failed request on a single server hosted on a single computer.

Additionally, replicating the exact trajectory of a failed request can prove cumbersome, particularly in environments where container-hosted microservices are frequently spun up and down.

Distributed Debugging:

Debugging a microservices-based application is similarly challenging. Tracking the path of a request through an architecture involving potentially hundreds of interacting microservices, each operating within its own container, necessitates a comprehensive monitoring strategy. While logging provides some insight into the internal workings of a microservices architecture, monitoring must offer a holistic view of the system.

Various tools, including open-source projects like Jaeger and Zipkin, as well as commercial products like Datadog, Dynatrace, and Wavefront, aim to facilitate debugging by providing distributed tracing capabilities. Regardless of the chosen tool, a robust monitoring strategy is indispensable for observing both internal and external activities within the diverse microservices comprising the application.

10. Organizational Inertia

Overcoming organizational inertia poses a significant challenge in the adoption of microservices within enterprises.

Transitioning from monolithic architectures to microservices entails substantial commitments: embracing new tools, adopting novel development methodologies, and acquiring additional skills. Without a compelling rationale to embrace cloud-native approaches and restructure monolithic systems, many organizations find it simpler to adhere to established practices and maintain their existing monoliths.

However, compelling arguments can surmount organizational inertia. If the IT department hesitates to transition from monoliths to microservices, it may indicate that the drawbacks of microservices outweigh their benefits - and that's acceptable as well. Not every organization is prepared or necessitates immersion in the cloud-native paradigm. Monolithic architectures still hold relevance in the contemporary IT landscape.

Conclusion  

Using Microservices brings many significant benefits to web applications such as increased flexibility, scalability, enhanced stability, performance, and reduced dependencies between application components. However, there are also challenges that businesses need to consider such as synchronizing and integrating microservices, development costs, operations, and addressing issues when overloaded.

With VNG Cloud, businesses have complete flexibility in choosing the most suitable tech stack for their system, needs, and budget. For more information on services within the VNG Cloud ecosystem, please contact us via Hotline 19001549.