Monolith vs Microservices – A PM’s Perspective & MS Teams Use Case
Introduction
🎡🎡 I am on my third product management venture.
🚀 My first company supported back-end operations for insurance giants within the blue cross and blue shield brands.
🚀 My second company supported the Electronic Health Record system for providers.
🚀 My current (third) company delivers online furniture.
All three have one thing in common - They are heavily reliant on the monolith architecture system to support their platforms. This debate of monolith vs microservices has taken a lot of heat in recent days and as product managers, it becomes challenging to develop products on technology that is not effective and has high tech debt.
In today's blog, I want to present a product manager's view on monolith vs microservices architecture. This blog is all about my learnings based on my experience across three organizations. I am not going to talk about the technicalities of building a microservice or a monolith. There are far more capable people to write about that. This blog only presents a product manager's view and its impact on product development.
What is a monolith?
Monolithic software is designed to be self-contained, wherein the program's components or functions are tightly coupled rather than loosely coupled, like in modular software programs. In a monolithic architecture, each component and its associated components must all be present for code to be executed or compiled and for the software to run.
Read more here.
What are microservices?
A microservices architecture consists of a collection of small, autonomous services. Each service is self-contained and should implement a single business capability within a bounded context. A bounded context is a natural division within a business and provides an explicit boundary within which a domain model exists.
Read more about microservices here.
Watch the video below to learn more.
Scroll to the bottom for more articles, reference material, and use cases on microservices and monolithic architecture.
My Experiences
The first company - HM Health Solutions, (now enGen) provides an end-to-end platform to support the healthcare insurers within the BCBS brand. HMHS platform is a monolith comprising of many sub-components. These components are enrollment, claims, care management, billing, finance ledger system, provider management, EDI services, etc. All of the services are knitted very closely to build a monolith architecture. As a result, if certain clients only want to use the enrollment or claims services, they could not. As a result, if you are an insurance company within the BCBS brand you could only board the HMHS platform for end-to-end services.
This resulted in many business opportunities being lost as the cost of onboarding is too high (taking in the range of hundreds of millions). I did work on projects where we tried to build a microservice environment using API and sometimes also thought of using third parties to host some capabilities. The costs of doing this were unbearable (again in the range of hundreds of millions), as a result, we kept on building on that monolith. My last day in HMHS was Sept 2020. Maybe there are changes that have been made which I am obviously not privy to. I just hope all changes were made in the right direction. Anyhow moving to the second company.The second company - Athena Health, the EHR vendor. Athena provides EHR services mostly to small group practices. They are competitors to Cerner and EPIC. They offer multiple services like revenue cycle management, EHR, Telehealth, Marketplace, and Patient Experience (PEX). Athena has a core Monolith platform for all core disciplines to read and write. Athena also has a marketplace where 3rd party vendors can read and write to monolith as well using APIs.
Same as HMHS, the core problem is making any changes to the backend monolith architecture. We suffered from scalability issues and struggled to onboard big customers. There were performance lags in the apps which limited the number of users that can log in. Feature development is very slow as the cost and time to make changes to the monolith architecture (written in PERL) are complex. Hence most of the product works are prioritized to fix the back end for any changes we made. Athena like HMHS is moving towards the microservices model but again the costs of making these changes are huge and have to be done product by product.The third company - Wayfair, the online furniture store. I recently joined Wayfair in the logistics and transportation division. But like my previous two experiences, Wayfair also suffers from architectural issues. It is also a monolith that is used by a bunch of teams to read and write all data. A bunch of Kafka topics is used to transfer data. Wayfair is now making an effort to move towards a microservices model.
Long story short, across all organizations, my products suffered from scalability and performance issues with Monolith architecture. Below are my learnings.
Learnings
Monolith architecture slows growth, Scalability is limited.
Monolithic architectures suffer from drawbacks that can delay application development and deployment. These drawbacks become especially significant when the product's complexity increases or when the development team grows in size. One of the primary reasons for this is the extensive code base, which can make it difficult for new developers to modify the code to meet changing business or technical requirements. As requirements evolve or become more complex, it becomes difficult to correctly implement changes without hampering the quality of the code and affecting the overall operation of the application.
In all three organizations, my products have suffered from slow growth and scalability issues. I specifically remember having discussions with architects and engineering leads to estimate the costs to move our code base as a separate microservice which will expose to different teams via Kafka or APIs. But the sheer time and cost of this work always threaten the roadmap of the product.
Reliability is another concern.
A bug in any one component can potentially bring down the entire application. I remember my time at HMHS, where we spend two days just to figure out a bug that was reported by a customer. It was a claims processing issue where psychiatrist specialty claims were not processing correctly. There were always thrown in exception buckets to be processed manually which was slowing down the process. After figuring out the issue, the solution with E2E testing was another 3 days of work. In all, we lost haft a sprint fixing this issue.
Tight coupling between multiple applications
Service modules in monolithic applications is tightly coupled. Business logic is tightly entangled and makes it difficult to isolate the application. It goes back to the first point but it's important to capture this challenge separately. In Athena, the calendar management application that I was developing was heavily dependent on other applications' architecture and vice versa. Any changes that we'd make would impact the operations. It became a real challenge to align the timing of updates among multiple teams as we wanted to ensure the smooth functioning of all applications. This delayed the feature on the roadmap. Our customers were not happy, it was a delighting feature that would have helped us increase the adoption of the application.
All of these challenges impact the cost of product development and the time to market. Due to its bulky size and higher dependencies, building and deploying mechanisms in monoliths are more complicated and time-consuming. Several of these aspects come under the umbrella of “cost.” Cost of getting started, maintenance cost, cost of development, cost of quality, cost of speed and performance, and the cost of ownership. Cost is a significant factor that comes to the executives’ minds while taking the final decision of adopting any software architecture.
Microsoft Teams: A wonderful use case for microservices
MS Teams is built on a microservices architecture, with a few hundred microservices working cohesively to deliver the product’s many features including messaging, meetings, files, calendar, and apps. Using microservices helps each of Microsoft's component teams to work and release their changes independently.
Azure is the cloud platform that underpins all of Microsoft’s cloud services, including Microsoft (MS)Teams. MS workloads run in Azure virtual machines (VMs), with their older services being deployed through Azure Cloud Services and the newer ones on Azure Service Fabric. MS's primary storage stack is Azure Cosmos DB, with some services using Azure Blob Storage. MS counts on Azure Cache for Redis for increased throughput and resiliency. They leverage Traffic Manager and Azure Front Door to route traffic where they want it to be. MS uses Queue Storage and Event Hubs to communicate, and they depend on Azure Active Directory to manage their tenants and users.
MS Teams gives you the capability to add third-party apps through apps, bots, and connectors. This is where Teams thrives, its one app combines your contacts, conversations, phone calls, access to files, and 3rd-party applications, in a way that “just works”. Just saying, Dropbox absolutely is better than One Drive. Google Apps is better at collaboration than Microsoft’s Office apps. Asana is better than Planner. And, to be very clear, Slack is massively better than Teams at the chat. Teams by virtue of doing everything, even if mediocrely, the app is providing a whole lot that is greater than the sum of its parts, particularly for the non-tech workers that are in fact most of the market. This is a microservices environment at its best.
Microservices do not mean the end of pain points, there are challenges
The grass is always greener on the other side. It's not all hunky-dory with microservices. It comes with its own set of challenges
Governance
We ended up with so many different languages and frameworks that the application became hard to maintain. It would have been useful to put some project-wide standards in place, without overly restricting teams' flexibility.
Lack of data integrity
Each microservice is responsible for its own data persistence. As a result, data consistency can be a challenge. Embrace eventual consistency where possible.
Deployment and testing
Writing a small service that relies on other dependent services requires a different approach than writing a traditional monolithic or layered application. Existing tools are not always designed to work with service dependencies. Refactoring across service boundaries can be difficult. It is also challenging to test service dependencies, especially when the application is evolving quickly
Why PMs should be concerned about Microservices vs Monolith debate?
The product manager is responsible for building a product that is scalable and reliable. As a PM you cannot build a scalable product if the core architecture is stopping you. I am not saying you need to be a technical expert by selecting a microservice environment or a monolith. But you definitely need to understand the core differences between the two so that you are able to make the right decisions for your product and company. These decisions will be made by developing trust between engineering, architecture, and product to come to the table and talk openly about scalability and reliability challenges. Having said that, the PM is not responsible for making these decisions, it's the engineering or the architecture team's job.
These are hard decisions and it is always better to table them early in the product journey. Ask the right questions at the right time can prevent delays and also helps be cost-effective. The reason big tech is able to complete the build and scale the products quickly is that they make these critical decisions fast and without organizational politics.
As a PM it's important to educate ourselves on the technical aspects of product development as well.
Read more product growth essays on Products and Businesses here.
References:
https://www.techtarget.com/whatis/definition/monolithic-architecture
Wish you the best in your product journey
Cheers!