Microservices: The Pros and Cons

In the world of software engineering, the design patterns used to develop applications are continuously changing. A pattern that has gained popularity in the past years is micro-services. As is the case with any architectural pattern, microservices have their pros and cons. 

In article, we will look at the arguments for and against microservices. We will focus on how and why they are referred to as ‘technical debt’ and why it might be time to the industry to search for a compromise between monolithic architecture and fully distributed systems.

What are Microservices?

Microservices are a collection of semi self-sufficient services that depend on the business structure. Developers connect these services via APIs (Application Programming Interface) and develop and deploy them independently. You can contrast the P2P structures with the monolithic structure, where the application functions as a single whole unit.

Why are Microservices So Appealing?

Enhanced Scalability and Availability: 

Microservices shine when it comes to Scalability. A typical microservice application consists of different services, which all function independently from each other.

This means that each service can scale based on its specific needs. This level of control makes microservices cost-effective. Resources can be focused on the parts of the application that need them. This approach helps improve performance.

For example, if you are selling Taylor Swift concert tickets and you are expecting a crazy surge in traffic, there will be no need to distribute resources across the entire application. You only need to but to scale the transaction oriented services (such as concert page or payment gateway). This saves time and resources.

Independent Deployments and Faster Time-to-Market: 

Micro-services make deployments quicker and more efficient. Since they work independently of the application’s other developments.

This makes the deployment quicker, reducing the time to address bugs and implement new features. You can compare it to trying to find what is wrong with a car engine. If you use a monolithic architecture, you must stop the entire car to perform modifications.

On the other side, Microservices allow you to make adjustment to the engine while the car is still running.

Technological Freedom and Flexibility:  

Microservices offer the ability to put together different softwares, each bringing a solution to a need. This gives developers the freedom to select the best tools for their work and to try out new technologies. This is important in very large firms where different teams can have expertise in different technologies.

The Dark Side of Microservices: Why They Might Be "Technical Debt"

Increased Complexity and Operational Overhead: 

Although microservices come with a multitude of advantages, they also add to the complexity of a system. For example, when you manage a system with various components across multiple services, it requires more scrutiny. 

It becomes an operational overhead as you will need to put in place comprehensive monitoring, logging, and orchestration tools. 

Increased Communication and Network Latency

One of the many challenges of a microservice architecture is that services will communicate over a network and this triggers significant latency, especially in cases that involve a large number of services. Additionally, service reliability and managing networks and failover for services becomes critical.

Difficulties With Data Consistency and Management:

Data consistency means the same point of reference must be respected among several services. Under certain conditions, this can prove problematic to maintain. A case in point is if a service has its own database and all the databases need to be integrated; such integration needs careful planning. Using distributed data management further complicates things.

The DoorDash Story: A Real-World Example

The growing story of DoorDash, a food delivery business, provides great insights as a case study. The pandemic brought them exponential growth and they made the transition from a monolithic architecture to microservices. This enabled them to scale quickly to meet the spike in demand for their services. But this was coupled with some challenges, as a former DoorDash engineer noted in the Youtube video below: 

Although this migration was in the best interests of the company, it did, as expected, come with its setbacks. The company needed to adapt to a significant increase in system complexity as they needed to oversee hundreds of interconnected services. This led to an increase of operational overheads, further exacerbated by the need for advanced tools for monitoring and debugging.

The other consequence of the inevitable expansion of services was the so-called “explosion” of network calls. For example, one single request aimed at the DoorDash frontend generated thousands of internal RPC (Remote Procedure Call) calls which showcased the higher impact that a microservices architecture may have on overall latency and performance.

However, the DoorDash example goes on to show how microservices may be the only option under some circumstances. The company had to decide whether to remain within the boundaries of their monolithic architecture or find a way to best handle the increased complexity that comes with microservices. In their case, the need to scale at speed and meet market demands was more important than the added complexity.

Finding the Middle Ground: Do We Need a New Architectural Paradigm?

Companies facing the choice between these two different types of architecture, should not be forced to choose between one or the other. As the YouTube video highlights, there is a need for new architectural patterns and middle ground which offers the benefit of both systems while simultaneously mitigating their downsides. This middle ground could involve:

Modularity Within Monoliths: Exploring different approaches to introducing modularity and independent deployment capabilities within monolithic architecture. This could offer better organisation, more seamless maintenance, and faster development cycles without the cost of a fully distributed system.

• Service-Oriented Architecture (SOA) 2.0: Applying the principles of SOA while adding a layer of modern technologies and best practices to address some existing drawbacks. SOA promotes interoperability and flexibility by focusing on reusable services with well-defined contracts.

• New Frameworks and Abstractions: Simplify the development, deployment and overall management of distributed systems can be achieved by investing in the development of new frameworks and abtractions. Tools such as load balancing, fault tolerance and service discovery can be utilised to support engineers in building and maintaining microservices-based applications.

Conclusion: Microservices – A Means to an End, Not the End Goal

The architectural pattern of microservices is appealing due to its power and flexibility, but is not the silver bullet that solves every problem in every context. They provide certain advantages but also require conscious tradeoffs. It is one thing to say that microservices will make things easier, but quite another to function and use so many resources including time and context for microservices.

The key takeaway is to avoid dogmatic adherence to any single architectural pattern. Instead, strive to understand the underlying principles of software design and choose the approach that best aligns with your project's requirements and constraints. Remember, the ultimate goal is to build high-quality, scalable, and maintainable software that delivers value to users—and sometimes, that means looking beyond the hype and considering all available options.

The key takeaway from this overview of microservices is to never stick strictly to one architectural pattern. Instead, carve out the time to fully understand the principles of software design and select an appropriate design technique that fits the needs and constraints of the given project. Software design is meant to solve real user problems, and not every architecture is suitable.Sometimes, in fact, the ideals should be set aside for the best result.