The Almighty Microservices Architecture: Is It Best For You or Your Client?

Photo by Alina Grubnyak on Unsplash

The start of a new client engagement is frequently baked with the question of which architecture is suitable for the lifecycle of the product. This product, whether it be: a proof-of-concept, a project mid-development seeking to modernize the development process, or a mature product in-need of a complete digital transformation, has to meet the unique consumer demand.

For the past few years, I have been given the opportunity to work for a big tech company that is an industry-leader both in cloud technology and development methodology with the Garage Method (an extreme version of Agile development). This dual-front innovation covers the entirety of the development process has given me experience in architecting and developing applications for a range of clients. From small start-up companies all the way to large enterprise corporations; all wanting to capitalize on the hottest new microservices cloud technologies to elevate their user and developer experience. Terms like latency, scalability, availability, data consistency, etc. get thrown around often as the key points to ensure the cleanest user experience possible. Time and time again, I hear the same thing:

“Application Monolith Bad. Microservices Good.”

As concepts like distributed computing, loosely coupled lightweight services, and highly maintainable/testable code become more appealing, the microservices architecture has emerged as the de facto standard for large-scale application architecture. I would like to offer a counterpoint to this idea and propose that not all modern applications need to follow the microservice architecture. In many cases, microservices might be too complex and a monolith may actually provide a superior user experience. To determine which camp you belong in, I propose you and your client ask yourselves a series of 5 questions before committing to a microservice infrastructure.

But First, What Are Microservices?

Microservices, as defined in simple terms by Kong Yang are “a method of developing software applications which are made up of independently deployable, modular services. Each microservice runs a unique process and communicates through a well-defined, lightweight mechanism, such as a container, to serve a business goal.” In other words, microservices break out functions of a large application into smaller, manageable chunks that act independently of each other in terms of deployment and maintenance. This is a complete contrast from the traditional “monolith” approach where an entire application is deployed at once and managed, scaled, and maintained as a single entity.

Photo by Clint Adair on Unsplash

According to Jeremy Hillpot, the benefits of this strategy are numerous

• Improved Scalability: Microservices are a powerful framework if you need to scale out a specific function of an application independently without impacting other parts of the application. You can add, delete, and update functional units gracefully without impacting or compromising other parts of the application. This is useful when combined with a cloud/container orchestration tool like Kubernetes or OpenShift, which can automatically handle scaling, pod monitoring/regeneration, 100% availability, and more.
• Fault Isolation For a More Resilient Application: Due to the autonomous nature of workloads running in isolation from each other, service failure in one workload will likely not impact other workloads
• Programming Language and Technology Agnostic: Microservices within a cluster can communicate with one another regardless of the language or technology used to build the specific services. This is a key benefit of flexibility in development to be more adaptive to different situations or new technologies in the project, whereas a monolith application would likely need to stick to one programming language family.
• Better Data Security and Compliance: Microservices living inside a cluster manage data inside an isolated container and utilize secure APIs to communicate with one another, ensuring only authorized users and resources can view data.
• Faster Time to Market and “Future-Proofing”: Because of how easy it is to add and remove from the microservices architecture; development and upgrades (either of new or existing services) can happen very quickly and with very little disruption of other resources living on the cluster. CI/CD is a key part of this framework.
• Greater Business Agility and Support for DevOps: The focus on a modular framework allows for a greater speed of development in small iterations. If problems occur, changes can be easily rolled back.
• Small Team Support: For a complex architecture such as service clusters, it is more effective to have smaller teams with direct lines of communication, where each microservice is managed by a specific team. The smaller code base per microservice makes the task of maintaining and deploying code by a smaller team much easier. This team framework has consistently produced more output and generally provides a better experience for developers overall.

However, this framework does not exist without some disadvantages

• Higher Price Point: The complexity of microservices demands a sufficient hosting architecture with more security and maintenance support. Hosting multiple services with high availability usually comes with a higher price point. For enterprise clients already hosting their services as a monolith and looking to do a complete digital transformation to a microservices infrastructure, the initial investment to find those resources as well as hire competent developers and DevOps engineers is usually a steep price.
• Increased Complexity: Imagine dividing a large-scale monolith into smaller services each responsible for a single function. It is a network driven entirely by communication and complex secure networks. Tasks like debugging become harder to track the point in which failures actually occur in the call stack, and while unit testing may be easier with microservices, integration testing is not. This requires more than testing a single entity, but rather testing each API call along the chain.
• Interface Changes Involve Modifying Other Services: A microservices infrastructure relies on concise, consistent network communication between the functional workloads. These API endpoints define interfaces/contracts between them and any other services or clients that may call them. Services may even be called by multiple different clients/services if it contains functionality that is used frequently. The problem comes when one API/interface needs to be changed. This can cause a cascading effect on the calling services, which also all need to be changed to fit the new modification. Otherwise, it might not be able to communicate with the microservice properly.

The Bottom Line

Microservices solve many of the scaling, availability, and organizational issues enterprise applications face when servicing millions of clients at the same time. However, there is a serious need of understanding the scope and timeline of the project, available resources, and tolerance for complexity before undertaking the long task of building a microservices infrastructure. The conversation you have with your client and team needs to address at least the following questions, otherwise you face the risk of wasting serious time and money.

The 5 Questions to Ask Before Diving Into Microservices

1. Does your timeline for development to production reasonably support the length of time needed to securely architect, build, and configure a complete microservices architecture?
2. Does your budget for architecture, development, DevOps, maintenance, and management suffice for the entire lifecycle of the application?
3. Do microservice topics like latency, scalability, availability, and improved security matter for the number of users/consumers of your application? Or do you have a smaller user base that can get by with the traditional monolith structure?
4. Are your development and DevOps teams mature enough to handle the sheer complexity of deploying, securing, and scaling multiple services continuously over the lifecycle of the project?
5. Can your development teams be organized in such a way that they may synergize with the idea of microservices being individually managed by small teams empowered through direct lines of communication and improved operational flexibility?

Only if the answers to these questions are “YES” should you even consider making microservices a choice for your project. If the application is large, complex, and in serious need of being controlled to meet large user demand, then microservices may be exactly what you are looking for.

Resources

1. Casey, Kevin. “How to explain microservices in plain English.” Enterprisers Project. August 16, 2017.
2. Diguer, Sarah. “Microservices Advantages and Disadvantages: Everything You Need to Know.” Solace. June 1, 2020.
3. Churchman, Michael. “5 Reasons Not to Use Microservices.” Runscope Blog. October 25, 2018.
4. Hillpot, Jeremy. “7 Key Benefits of Microservices.” DreamFactory. March 16, 2020.
5. Richardson, Chris. “What Are Microservices?” Microservices.io. 2018.
6. Lumetta, Jake. “Should you build or buy microservices?” ButterCMS.