This content is part of the Essential Guide: An guide to modern microservices management

The reality of microservices adoption and the limits of your monolith

In this Q&A, Randy Shoup of Stitch Fix talks about the 'reality' of microservices adoption and shares three telltale signs that your monolith has reached its limit.

Moving to a distributed architecture, particularly a microservices architecture, is increasingly all the rage among organizations looking to make a digital transformation. However, while big players like Amazon and eBay have led the charge into breaking monoliths into little pieces, most companies are still figuring out what a microservices architecture means to them.

In this Q&A interview from the 2017 QCon software development conference in New York, Randy Shoup of Stitch Fix, an online personal styling service, talks about the simplest definition of microservices, the "reality" of microservices adoption and the telltale signs that your monolith has reached the end of its life.

What is your simplest definition of microservices?

Randy Shoup: The 'micro' in microservices is more about the scope of the interface and not about the amount of lines of code or how long it takes to write it. So, I think of it as a service that has a simple, well-defined interface. [It should also be] composable, meaning that it's sufficiently general that I can use the same, for example, 'billing' microservices with lots of different clients to compose in lots of different ways.

Randy Shoup, VP of engineering at Stitch FixRandy Shoup

It's all the ideas that we have in software around building good classes, except at a slightly higher level of granularity. We build a class that is encapsulated; the data is inside it. It's got a simple interface, it's easy to use and it's easy to understand. [It's] those design principles just applied at the level of a process or a service.

What's the 'reality' when it comes to microservices adoption? How many are still, as much as they say they're trying to get away, tied to the monolith?

Shoup: The first thing I would say is there are lots of companies that we have all heard of -- eBay, Amazon, Netflix, Twitter -- that have started as monolithic as you can possibly imagine. All of those people that I mentioned, by the way, are now what we would call microservices architecture.

So, [there are] two points. First, none of them started that way; they all started as a monolith. Second, they have evolved their architecture over time … in eBay's case, five generations. Twitter has gone through that evolution, Amazon has gone through it and Netflix has gone through it.

So, nobody started with microservices when they were small, because if we've heard of them, they spent their time building their business and not building technology. The joke that I like to say is: There might have been an eBay competitor in 1995 that spent all their time building a distributed system, and there is a reason why we have not heard of them; they spent all their time doing that.

So, nobody started with microservices when they were small, because if we've heard of them, they spent their time building their business and not building technology.

OK, so what's the reality? Because it's an evolutionary process, there are many different companies that are at different points along that spectrum. So, the people that started really early -- those people that I talked about -- they're all done. Amazon is fully a microservices architecture, and it is still evolving by creating new services.

[But at] Stitch Fix, where I work now, we are in the middle of breaking up our particular monolith and moving to microservices. So, we sort of [have] a foot in each side … there's a monolith on the one end, and [it's] completely microservices on the other end. We're kind of in the middle of a spectrum, and I think lots of companies are there.

What are the signs that your monolith has reached the end of its usability and that it's time to consider a microservices adoption?

Shoup: [One reason is] your team cannot scale. So, as I add more people to my team, everybody is stepping on each other's toes in the monolith, and they're just slowing everybody down.

You might also reach a [performance] scaling bottleneck. Twitter was going down all the time in its early days … it was hugely popular, but it would just die all the time, in large part because its monolith simply couldn't take the load. And so that forced Twitter to break its architecture up into smaller pieces.

And then, the third one is deployment lifecycle. There might be different pieces of your system that need to move more quickly or more slowly. [It] might be that I need to deploy the web interface every day because it needs to change. And that's a big bummer if I have to deploy everything about my system just to tweak something in the HTML.

A monolith is not a pejorative term. It is a completely legitimate solution to [a certain] class of problem. And when you are beyond that class of problem, either because of number of users, the size of your team or characteristics about deployment lifecycle, then you need to do something that's more like microservices.

Next Steps

Learn why Uber needed microservices patterns to improve performance

Get tips for moving data from a monolith to a microservices architecture

How microservices can help in a Docker and DevOps world

Dig Deeper on Application development and management