Microservices vs. Monolithic Architectures

We have long used monolithic architectures in traditional software development. Monolithic architecture is the easiest to implement. Systems start small, with a few moving parts: a single codebase, stateful objects, and a single database. Monolithic systems serve us well when it comes to simple applications and small development teams, where everyone knows how the application works.

As applications grow and complexity emerges, however, developers struggle with larger codebases. Over time, monoliths become tightly coupled and entangled. Making structural changes becomes more challenging — the impact of interdependent functions can lead to longer development cycles, difficult deployments, and more bugs. An error in any module can bring the entire application down. Updates must be deployed via the entire application. In addition, as the application grows, the team often grows too. New team members need to understand how the monolith works before they can safely contribute. Bugs, outages, arguments — all these results hurt the customer experience and damage internal morale.

A microservices architecture addresses the challenges of developing complex software. Microservices can be used to break the application down into smaller components or services. Each component manages a single business function (hence microservice) and communicates with other services using APIs and messaging protocols. Switching away from monolithic architectures has made work easier for developers. They are no longer forced to maintain large codebases, and microservices enable them to focus on smaller scoping within projects. It’s also easier to add new people to a project since they don’t have to know the entire system, just a small part of it.

Rebuilding the Airplane at Amazon

Colin Bryar’s & Bill Carr’s book Working Backwards recounting their Amazon experience describes the process used to update Amazon.com. Originally created as a monolithic bookstore, the system became more complex with the addition of new product lines. Consider what the database engineers faced — original plans to sell books require a certain template of fields. Adding products like kitchen gadgets didn’t fit the template. As if flying an airplane and rebuilding it as it flies, the Amazon development team migrated from a monolithic architecture to a service-driven one. The core database, which had been so problematic to “democratize” for the growing e-commerce catalog, was migrated piece by piece into a new framework, eliminating the constraints of competing with other products and coordinating schema changes. New services could be created and tested at any time without impacting the core systems. “Earth’s Biggest Bookstore” transitioned quickly to what we know it as today — a purveyor of almost anything. The nimbleness afforded to Amazon by using microservices became a huge competitive advantage.

Going Rambo on Netflix

In 2008, Netflix had a horrendous service outage in its own data centers that crippled DVD renting services for days. With a goal of eliminating single points of failure (SPOFs), Netflix improved its uptime by migrating the IT infrastructure from its data centers to AWS and employed microservices in lieu of its monolithic architecture. By 2016, Netflix had over 8 times as many streaming members than they had in 2008. Users also became more engaged, with viewing up 300% (we all binge watch now, right?). Using its microservice architecture, engineers can create new features and implement them in production from their first day — their approach to DevOps is to build self-healing “Rambo” systems that fight their way through, something not possible with a monolith. Thus, we’re all treated to a good customer experience as Netflix deploys continuous improvements and new ideas (streaming, buffering, tracking activity, recommendations). Oh, and scale? Netflix has hundreds of microservices with thousands of production changes every single day, all running on tens of thousands of virtual instances inside AWS.

Paying Down Debt at Wix

With massive technical debt, website platform Wix.com adopted microservices to address haunting stability issues. With many intertwined applications fixing bugs in one part of the system could actually bring down the whole system. Wix decided to break things into smaller services to better handle scalability and quality assurance. They now have over 1,500 microservices being maintained by over 400 engineers. The company defines a microservice as a single application deployed as a process with one clear responsibility. A microservice is as large as the team of people managing it, and they have to be able to describe the microservice responsibility in one clear sentence. With over a million websites running in their cloud architecture

Getting Craft at Etsy

Etsy has established a reputation for an architecture that is optimized for change, enables regular experimentation, and allows Etsy to deploy many times each day. A company well-documented in The DevOps Handbook, Etsy had struggled with performance problems. Their engineering team needed to decrease server processing time from concurrent API calls, which weren’t easily allowed in PHP. They also needed to support development of new features and mobile apps, which required more platform extensibility. Etsy decided to redesign their platform using an API architecture similar to Netflix. Etsy developers redesigned their microservice architecture, making it flexible enough to accommodate change, continuous experimentation, and frequent deployments.

Understanding Microservices vs. Monolithic Architecture

Amazon, Netflix, Wix, Etsy, Google and other leading technology companies have switched from monolithic structure to microservices. The microservices vs. monolithic architecture debate is continuously hot. Although we often argue that microservices are the way of the future, the monolith is still a viable option in some situations. When starting up a new solution, or an application with a small scope, a microservices architecture may be overkill. But we have lived through more than one application that outgrew its original footprint, with the monolith slowing us down. Consider the end game when making your architectural choice!