Why is it now the age of de-microsservice and de-cloud?
Exploring Microservices and Spring Cloud
The term “microservice” first caught my attention in 2017, three years after Spring Cloud released its initial version. This new concept motivated me to explore Spring Cloud and understand its purpose in software architecture. But the big question remains: do we really need Spring Cloud?
Why Microservices and Spring Cloud?
With the rise of smartphones, internet usage patterns have changed. Users now access the internet whenever and wherever they want, which has led to increased traffic on web applications and mobile sites. This shift poses a challenge for engineers to build scalable, stable services that meet user demands.
Netflix was one of the pioneers in implementing microservices, creating components like Eureka, Ribbon, and Hystrix—all of which were later incorporated into Spring Cloud's first version. These innovations allowed Netflix to offer stable streaming services for users worldwide. In many ways, Netflix’s success with microservices helped to push software development forward.
Microservices vs. SOA
Microservices are often seen as the evolution of SOA (Service-Oriented Architecture), as both are part of the "distributed systems" family. Both architectures emphasize loosely coupled services as the primary building blocks, aiming for modularity and isolation. This design means that if one service goes down, others can continue running without disruption.
However, unlike traditional monolithic applications, microservices are independent and can be scaled up or down individually based on demand, making them ideal for cloud environments.
How Spring Cloud Supports Microservices
Spring Cloud provides a suite of tools and libraries to implement microservices. Some of the core components from the first version included:
- Eureka: Service registry
- Ribbon: Client-side load balancing
- Feign: HTTP client
- Zuul: API Gateway
- Hystrix: Circuit breaker
As Netflix deprecated many of these components, Spring Cloud introduced replacements in its newer versions, such as Consul for service discovery and Gateway to replace Zuul. These changes add to the learning curve and can increase the overall cost of implementing and maintaining a Spring Cloud-based microservices architecture.
Monolithic Architecture: The Alternative
Before discussing the benefits of microservices, let’s look at monolithic architecture, which combines all services into a single application. Monoliths are simpler to develop and maintain since all functionalities reside within a single codebase. Interactions between components are straightforward, and resources can be shared easily.
However, monolithic systems struggle with scalability, especially with the demands of modern internet usage. Scaling a monolith means scaling everything, even components that don’t need it, leading to resource inefficiency.
To achieve the flexibility needed for modern applications, you often need to separate the frontend and backend. This allows the backend to scale independently, which is crucial for handling varying traffic demands.
Cloud and Microservices: A Perfect Match?
In theory, microservices are well-suited for the cloud. For example, on AWS, you can independently scale resource-heavy services, which helps to manage costs and improve stability. This approach can allow for better control over costs and more efficient use of resources. However, this comes with additional complexity and requires a dedicated maintenance team for each service.
Distributed Transactions and Complexity
One of the major challenges with microservices is handling distributed transactions. Imagine a scenario where a user places an order that requires updates across multiple services, each with its own database. If one service fails, managing rollbacks across all services is complex. Middleware solutions like Alibaba’s Seata can help manage distributed transactions, but they add to the system’s complexity.
In addition to technical challenges, microservices also require a larger team and increased coordination to handle multiple services. This can lead to misunderstandings and potential downtime if interacting services aren’t managed correctly.
Reconsidering Microservices and Cloud Services
Recently, some companies have reconsidered their use of microservices and cloud services. For example:
- Amazon’s Prime Video migrated from microservices to a monolithic approach, achieving higher scale, resilience, and reduced costs. (source)
- Some experts argue that even Amazon struggles to justify the cost of microservices. (Even Amazon can't make sense of serverless or microservices)
- Twitter laid off 80% of its staff yet continued to operate effectively, suggesting that large teams may not be as essential as previously thought.
In the article "Avoiding Beginner Mistakes Hampering You to Scale Backend", the author discusses simple and efficient ways to scale backend systems without the overhead of microservices.
The takeaway? There are trade-offs between microservices and monoliths, and the best solution depends on the specific situation. What works well today might not be ideal tomorrow.
Final Thoughts
Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations. — Melvin Conway
The microservice will require changes to your organization as well.
As Gall’s Law states:
"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system."
Microservices and cloud solutions offer incredible flexibility but come with high costs and complexity. Sometimes, the simplest solution can be the best starting point, allowing a system to evolve naturally.
References: