Transitioning from Monolithic Applications to Microservices
From a purely unemotional standpoint, parenting is a practice in adaptive scaling. An infant becomes a toddler becomes a child becomes a pre-teen becomes a teenager becomes a young adult. Throughout that 18 year time period, a parent’s job is to adapt to increasing circumstances of scale. A toddler requires different kinds of food than a child. A child will require less food than a pre-teen will. The clothes that fit a pre-teen will be outgrown as puberty hits and the growth spurts come hard and fast. A teenager requires different kinds of emotional support than they will come adulthood. A parent must adjust grocery store purchases, buy new clothes and adjust how they speak to their child over time.
Owning a growing business, like raising a growing child, 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 which fails to scale gracefully is like a child who doesn’t fit their clothes--uncomfortable, and not sustainable long-term.
Digital infrastructure, being a necessary component to any modern company, is one of those things that needs to be scaled effectively. What works for a budding small business will not work in the same way years later when the business has grown, then further down the line when it’s grown even further.
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 which upgrading can solve manifest gradually, over long periods of time, making them difficult to identify. Load times will slow, business will suffer, but not in any way that’s traceable day-to-day.
To understand how owners can raise their businesses through infancy, childhood, then adulthood, it helps to look to history: at one of the very first companies to face this problem, and solve it.
Case Study: Bookseller
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. Over the coming years the company grew quite rapidly, going public in 1997, expanding their retail offerings to include movies and music in 1998. As the company grew, so did the resources needed to maintain it.
Today, Amazon looks nothing like it did back in 1994, 1998, or even 2008. They’re now a leading developer in digital infrastructure, with the Amazon Web Services cloud platform. But back in the early days, there were real growing pains.
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. A monolith, in this context, refers to what most small 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.
“Now, don’t get me wrong, it was architected in multiple tiers, and those tiers had many components in them. But they’re all very tightly coupled together, where they behaved like one big monolith.”
The monolith architecture was the right choice for a young, budding website. Its simplicity allowed the company to focus on other matters, while having a solid foundation to build on.
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.
Some examples are one whose sole job it was to render the buy button correctly on the product detail pages. We also had a single-purpose service whose sole job it was to calculate the tax correctly on the checkout process.
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 perspective, it was transformational.
Pre-Packaged, Custom, or Micro
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, in anticipation that one day the company will grow to the point where it’s necessary, is like a parent shopping for fashionable clothes for their toddler, in anticipation of their teenager being fashion-conscious. We could draw out the analogy, but you get the point. It’s equally problematic, because too few developers are around to tame 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.
How can you tell when a change needs to be made, from monolith to microservice? Well, there’s no single rule. Just as a child doesn’t become a teenager in one, identifiable moment, so too does a company 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. If a company here in Milwaukee wants to avoid that period of growing pains--at the inefficient end of one software cycle, and the expensive beginning to another--what can they do to ease the transition? One option is to incorporate an intermediary step.
When a 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 Milwaukee companies come to us. A customized monolith architecture is still a monolith architecture, but it’s geared towards the specific need of the client it’s designed for. 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. For more information, or if you want to discuss where your company might be at in this journey, fill out the contact form below and let's chat.