Deciding to Migrate from a Monolith to a Microservice Architecture

A monolith, in the context we are discussing here, refers to what most businesses are used to dealing with: one-for-all software solutions, where the many functions of enterprise architecture--application, interface, database--are grouped together into a neat package.

The monolith architecture may be the right choice for a young business or a small app - as its simplicity allows the company to focus on other matters, while having a solid foundation to build on. As a business grows and the needs become larger and more complex, a monolith architecture often becomes problematic.

Migrating a monolith to a microservice architecture will assist a development team with the amount of churn, speed to delivery, and debugging quickly and efficiently. That being said - it may not be right for every business.

How to Know When to Break Up a Monolith into a Microservice

Owning a growing business requires an ability to adapt to circumstances of scale. When your shop becomes too busy, you raise prices or open a second shop. When you’ve got too much to do and not enough employees doing it, you hire. A business that fails to scale gracefully is like a child who doesn’t fit their clothes--uncomfortable, and not sustainable long-term.

But how does one tell when the time comes to make that change? To the untrained eye, it may not be so clear. The problems that upgrading can solve manifest gradually, over long periods of time, making them difficult to identify. Load times will slow, the business will suffer, but not in any way that’s traceable day-to-day.

We have a great example: Amazon.

In 1994, a budding engineer left his role as Senior Vice President at a young hedge fund in midtown Manhattan, traveled cross-country, and founded an online book store in the Seattle metropolitan area. It was the start of Amazon, but over the coming years, the company grew quite rapidly, going public in 1997, expanding its retail offerings to include movies and music in 1998. As the company grew, so did the resources needed to maintain it.

In a keynote at AWS re:Invent 2015, Rob Brigham--Head of Product for AWS Developer Tools--recalled Amazon’s early challenges in scaling.

“If you go back to 2001, the Amazon.com retail website was a large architectural monolith.”

This was how Brigham recalled Amazon’s early days, while cheekily standing before a slide of the monolith from Stanley Kubrick’s 2001: a Space Odyssey.

How Do You Adapt a Monolith Application?

As Amazon grew, it required more developers. As more developers began working on the site, the monolith grew. As the monolith grew, it became more unwieldy.

Even though each one of these developers is only working on a very small piece of that application, they needed to coordinate their changes with everyone else in the project. If they're adding a new feature or making a bug fix, they need to make sure that change is not going to break someone else on that project. If they want to upgrade a shared library to take advantage of a new feature, they need to convince everyone else on that project to upgrade to the new shared library at the same time.

The technical problems continued on from there, but you get the idea. As the development cycle at Amazon became more and more obviously inefficient, they decided they needed to make a change. The change they made would shape how we think about digital transformation to this day.

Rather than try fixing a giant, unhinged beast, they broke it into smaller, tamable chunks. Different functions within the system were identified, and isolated.

The system was still whole, the website still in one piece. But rather than having every part of the system talking and shouting over each other, each little unit acted independently. The result doesn’t exactly look neat, but from the developer’s perspective, it can be transformational.

But, returning to our analogy: shopping for a young child is simple. You buy things that seem to fit, with some level of comfort and durability to them. Quick, easy. Shopping for a teenager is complicated, if not utterly impossible. What teenagers require from their wardrobes has to take into account what’s trending, what looks good on them, and how kids at school will react.

As a company grows larger and more complex over time, so must the software supporting it. Otherwise, you end up with a wardrobe that just won’t work.

Breaking Up a Monolith

As Amazon.com grew, it required more developers. As more developers began working on the site, the monolith grew. As the monolith grew, it became more unwieldy.

Even though each one of these developers is only working on a very small piece of that application, they still need to bite off the overhead of coordinating their changes with everyone else in the project. If they're adding a new feature or making a bug fix, they need to make sure that change is not going to break someone else on that project. If they want to upgrade a shared library to take advantage of a new feature, they need to convince everyone else on that project to upgrade to the new shared library at the same time.

The technical problems continued on from there, but you get the idea. As the development cycle at Amazon became more and more obviously inefficient, they decided they needed to make a change. The change they made would shape how we think about digital transformation to this day.

Rather than try fixing a giant, unhinged beast, they broke it into smaller, tamable chunks. Different functions within the system were identified, and isolated.

The system was still whole, the website still in one piece. But rather than having every part of the system talking and shouting over each other, each little unit acted independently. The result doesn’t exactly look neat, but from the developer’s perspective, it can be transformational.

Choosing a Microservices Architecture

Microservice architecture is, essentially, the opposite of the all-in-one model--you decouple all the independent components of a system to avoid the noise that’s created when they overlap. Engineers with different focuses can do their thing, without unintentionally affecting the job of another engineering team halfway across the globe working with a different part of the system. For this reason, microservices architecture can be game-changing for companies that need it.

Amazon.com in 1994, in 1997, did not require a microservices architecture. In fact, they were better served by the monolith--it was quicker and less complicated. Building a microservices architecture for a small startup can be equally as problematic as a monolith for a large, complex business. Too many different moving parts. Microservices became necessary for Amazon only when the company grew to employ more developers, in more places, than could effectively communicate and collaborate with one another.

When Should You Break Up a Monolith into Microservices?

Well, there’s no single rule. A company may not mature out of its aging software infrastructure in one, identifiable moment. It’s a realization that will make itself known over time as systems become more unwieldy, employees complain and business slows. Perhaps the more apt question, then, is how to scale gracefully. What can they do to ease the transition? One option is to incorporate an intermediary step.

When a digital startup is small, off-the-shelf software may be the best option--it’s cheap, user-friendly, and gets the job done (mostly). But what about when a small startup becomes a midsize company? Suddenly off-the-shelf isn’t so useful at handling the more diverse, heavier tasks necessary to keep the business going. That’s where custom software can help, and this is often where companies come to us.

A customized monolith architecture is still a monolith architecture, but it’s geared towards the specific need of the client for which it’s designed. Think of it like a pair of outgrown kid jeans, cut up and fitted into a nice pair of jean shorts for a pre-teen. When a midsize company has outgrown off-the-shelf but isn’t ready for microservices, customized solutions can be that perfect sweet spot between too tight and too loose. Ultimately, every company is unique and requires its own solutions - we can help you with that.