A microservices architecture for application development in the cloud is an architectural approach that builds a software application as a collection of small (“micro”), loosely coupled services. Each service in the architecture represents a specific business capability or functionality, such as adding an inventory item to a database or checking the credit on new customers. They typically operate as a separate process, communicating with other services through APIs or lightweight protocols.
Microservices emerged from services-oriented architecture and the need to build better applications. It’s the most favored approach for building net-new applications for a few good reasons. I like using microservice architecture because it offers loose coupling and isolation.
Advantages
Services are designed to be loosely coupled. They can operate independently without directly depending on the internal implementation details found in other services. They allow teams to develop, deploy, and scale services alone, promoting better agility. Additional benefits would be increased resilience since they run independently.
This speaks to the benefits of independence and isolation, which are directly related to loose coupling. Each service can be developed, tested, deployed, and scaled independently.
To be honest, this was not revolutionary when it appeared on the scene. It was more an evolution of architectural best practices that started in the 1970s with structured development, then object-oriented development, component-based development, use of services, and microservices. Each approach influences the following methods; hopefully, we improve things along the way.
Drawbacks
Of course, there are no free lunches in development. Every approach, tool, language, and architecture has pros and cons that you must consider. This is sometimes lost in the hype. Let’s explore some downsides of microservices architecture.
The biggest one is complexity. Microservices introduce a higher level of complexity compared to more monolithic architectures. Systems are broken down into numerous services; the architecture becomes more intricate, and understanding the interactions between different services can be challenging.
This becomes even harder when you consider that we’re also dealing with complex distributed systems as the platforms where microservices are deployed. This is a byproduct of building and deploying multiclouds within almost all enterprises.
Distribution is another consideration. With microservices, communication between services often occurs over a network, leading to latency, network failures, and increased stress. I’ve had to upgrade networks after deploying microservices-based applications for this very reason. It’s not cheap.
Data management is also more complicated. Microservices may have their own databases or data stores, complicating data consistency across various services. It usually requires additional effort to maintain data integrity that enterprises don’t understand until it suffers. This is solvable but takes many more resources than most understand.
Service dependencies can be a pain. As microservices interact through APIs, changes in one service may have implications for others. The result? Versioning challenges and potential compatibility issues, especially during upgrades or service changes.
Finally, resource overhead. Running multiple microservices instances will consume more resources than a single monolithic application for most deployed applications. This can increase infrastructure costs, especially if not managed efficiently. Most are not.
Where to now?
I’m finding that cloud developers and architects approach microservices architecture with almost religious fervor. Of course, they are not the right approach for all applications and, in many instances, become a force fit. When modernizing applications that have already been moved to the cloud or are moving to the cloud, they require many more resources than they should. This is due to many of the disadvantages I mentioned.
That said, they are often the exemplary architecture to use. However, you must have considered many of the trade-offs before committing to it and you must focus on the core application requirements. Unfortunately, we’re not looking at many things that we should be, and we end up with inefficiencies due to mismatched approaches to core application requirements.
Microservices, like any other approach, should be only considered in context, also keeping the purpose of this architecture in mind, when it should be used, and when not.
Copyright © 2023 IDG Communications, Inc.
