Over the last decade, engineering teams have overwhelmingly favored microservices over monolithic architecture, based on the benefits of continuous delivery, scalability and improved resiliency for cloud-delivered products and services. Earlier this year, however, Amazon made headlines for returning to a monolithic architecture for video monitoring. This raised the question: would 2023 mark the Return of the Monolith?
The short answer is no.
But in this edition of Crosslake Conversations, our expert practitioners expand on the benefits and challenges of both microservices and monoliths – and discuss how operating partners can reconcile varying architectures when companies with competing approaches are acquired.
Contributors
Adam has helped define modern engineering excellence as a principal engineering manager and owner of the Software Developer discipline in the Engineering Excellence team at Microsoft – while contributing code for Windows NT 3.1 and 3.5, Windows 2000 and Office 2013 and 2016. He talks about what leads smart engineers to write bad code in his book, The Problem with Software.
Dave Bamber, Chief Technical Architect
An engineering leader and architect, Dave advises global businesses on technology strategy, software development and platform architecture, helping identify technology-related risks and opportunities throughout the M&A due diligence process.
Mark Hastry, Technical Architect
Mark is a technical architect who has developed and delivered cloud-based solutions using multiple methodologies, languages and technology platforms. Versed in delivery, strategy, architecture, and digital transformation, he provides private equity investors with insights on the technology systems of the target companies they seek to acquire.
Mike Tedesco, Lead Practitioner
Mike is a respected Chief Technologist who has rolled out microservices in a serverless architecture for Subway, led the development of Priceline.com’s original airline booking system and redesigned the website for World Wrestling Entertainment.
What are some factors that help determine whether your organization would benefit more from a monolithic or microservices approach?
Adam: Microservices have long-term benefits, but they may be more work in the short term – especially if this is a new approach for the team. The most important factor is complexity, both of the application and the development team. Microservices allow teams to work on separate components of the application and deploy them independently from other teams.
One of the keys to Amazon’s growth was that Jeff Bezos mandated, in the early 2000s, that all teams would remain small using the “two pizzas” rule, meaning that a team should be small enough to be fed by two pizzas. They would maintain and deploy their services via well-defined, connected APIs. This allowed the overall Amazon application to grow large, while avoiding a lot of the complexities of managing large teams and codebases. However, if your application is reasonably simple and your entire team can still be fed by two pizzas, you may not gain as much benefit from microservices.
The Amazon Prime example is interesting and certainly goes against the current wisdom, but it seems it is a specific situation due to them passing a very large amount of data (videos and then frames from videos) between microservices, which is an unusual case. The audio/video quality monitoring service is a small part of the overall Prime Video service, so conceptually it is still a microservice within that. It’s a good reminder that you have to be aware of where your costs (CPU time and actual costs) are, and there may be a tradeoff where further splitting is a negative.
Mark: The company’s scalability requirements and ability to undertake the complexity introduced with microservices are the two main factors to consider. Microservices will help if your application has specific areas that need to scale more than others. However, creating a well-architected monolith is the better option if you don’t have the justification, skills or time to manage the additional complexity of microservices. You can incorporate microservices design thinking into an initial monolith by creating a very modular architecture that can quite easily be broken down into microservices later.
Mike: When architecting systems, look for autonomous, independent groups of services that can be broken down into small, manageable pieces that align with business domains. Ensure that each microservice component can operate independently and doesn’t rely on other system components for scalability, which frequently boils down to the data architecture and database design. If the proposed architecture applies these principles without significant compromise, the winning approach is usually a microservice.
What are the steps to move from a monolithic architecture to a microservices approach?
Mark: Leaders shouldn’t feel forced to move from a monolith to microservices just because it is deemed the “better” or more fashionable architecture. Both models, when executed well in the right context, can be effective and appropriate for any business, with the inverse being equally true.
Define and understand your current state to understand the business requirements. Outline your non-functional requirements to ensure you can achieve performance, uptime, resilience, redundancy, scalability, security and capacity. Understand those requirements first – and then identify your target architecture.
Mike: When approaching migration from a monolith to a microservice, follow design patterns that help break down the work into small steps that allow teams to work in parallel. Domain-driven design and SOLID principles help architects draw the blueprint for software engineering teams to follow. From there, push for the strongest “shift-left,” continuous-integration mindset and supporting tools to allow teams to leverage the latest technology, such as serverless architecture. Once that’s in place, the transition steps are another project that should follow a mature software development lifecycle.
Adam: Remember that you don’t have to move to 100% microservices to get benefits. It’s like solving a jigsaw puzzle. Every little part of a puzzle that you solve is a worthwhile accomplishment on its own, making the remaining unsorted pile of pieces smaller and easier to manage.
Start with a small piece of functionality in your existing monolith and carve it out to a microservice. Don’t worry about changing the architecture or moving the data to a different database. Keep it simple so you can concentrate on the unique aspects of the microservice, including how it exports an API and how it is deployed.
Be prepared to change target architectures if needed after you have created a few microservices. This is not an argument for every microservice being written in a different language – that can become difficult to maintain as developers become too specialized. But you may want to re-evaluate certain aspects, such as moving your database from SQL to a NoSQL approach. Once you have figured out how to write microservices, commit that all new major components will be written as microservices, rather than added on to the monolith.
How do you ensure a seamless transition from monolithic architecture to microservices?
Mike: Fundamentally, interoperability is essential to allow for a transition between old and new services (or in-house and third-party services). The underpinnings of a seamless transition are typically based on an API that preserves enough commonality between the old and the new patterns to ensure continuity of business services. Look for opportunities to implement feature flags that allow new services to be activated in a well-orchestrated fashion.
You’ll want to keep the decision to go-live or to rollback in the hands of the infrastructure and operations teams, as they are well-tuned to maximizing service quality through transitions and upgrades.
Dave: It’s important to be aware of “tight coupling,” which is when core business logic is intertwined with dependencies, such as UI or database technologies, and becomes difficult to change. Whether you are deploying a monolithic or microservices architecture, flexibility in the technology is key, as business objectives will likely change over time.
Adam: Implementing a new microservice is an opportunity to re-evaluate your current technical platform, and that applies whether you are carving out functionality from an existing monolith or writing a new component. Evaluate potential new languages, databases, and platforms – while at the same time, avoid making a choice just because it’s something new or something your architect wants to try.
What challenges can arise when integrating a company with a different approach to architecture?
Mike: The biggest issues occur when a transition requires new capabilities that are not possible with legacy architectures: a transition from batch processing to a streaming architecture, for example. Similarly, a transition from synchronous to asynchronous processing can also be quite challenging. Teams get tempted to implement hacks to bend old systems to behave in modern ways – this movie usually doesn’t end well. Acquirers should seek to understand the limits of legacy architectures and frame expectations accordingly. Sometimes, a fresh architecture is necessary to achieve meaningful business outcomes.
Mark: Understanding an architecture and transferring that knowledge is extremely challenging. A microservices structure can be quite asynchronous and involve multiple components for a single-user operation, making it difficult for a developer to follow a full end-to-end user journey. On the other hand, while monolithic architectures have fewer code bases, the overall complexity of the code may be challenging to understand.
Adam: The simplest approach is to treat the other code as one big service. If your code is already split into services (micro or not), then it will be easier to integrate.
When we look at a tech acquisition where the target uses a different platform or language than the acquirer, we determine if the target has an API that exports the needed functionality and if the acquirer already has experience calling across services. The concerning situation would be the opposite: you acquire a company with different tech, they don’t export an API, and you don’t have experience calling an API. This will require work on both sides to learn new skills.
Other differences are often more cultural than technical. A company that is split into many services likely has strong test automation, a culture of releasing frequently, ownership pushed down to individual teams, etc. This will lead to complexities integrating with a company that has a monolithic code base.
Dave: If you are acquiring a business that is already in the process of transitioning between monolithic and microservice architectures, work to understand their reasons and their expected benefits of the transition. It’s likely they are addressing technical debt. Ensuring the combined organization has the appropriate skills and support capabilities to manage the integration will be key to a successful transition.
Connect with us to discover whether a microservices or monolithic approach will best enable your business strategy.
