Part 1: Microservices: Technical, Business, or Organizational Architecture? Yes

With a bucket of Legos, you can tell any story. You can build an airplane or a dragon or a pirate ship—it’s whatever you can imagine.
Christopher Miller

One of the hallmarks of any digital transformation is increased speed and agility. Decisions need to be made more quickly using data and algorithms. Digital services need to be created rapidly to capture new revenue streams and increase customer experience. You might have heard your CTO or Chief Architect (or AWS) talk excitedly about a new software architecture that is going to save your business, make it more agile, innovative, and solve world hunger called microservices. Much has been written about the technical aspects of microservices architecture, but the non-technical aspects (business, organization, etc.) of microservices I find are not covered with the same frequency or energy. But before I cover the non-technical aspects of microservices, I think it’s worth trying to explain it in layman’s terms and the connection to business value.

I find it’s helpful to imagine software systems as a physical manifestation to better explain and understand digital concepts. Imagine if the mixer in your kitchen had the dough kneading implement permanently attached. To change it you have to use a hack saw to remove the dough kneading implement and then weld on the wire mixing attachment. When you test it, you realize that the alignment is off because the mixer shook so violently it fell of the kitchen counter and landed on your toe. So, then you repeat the process again until the alignment is correct.

On the other hand, imagine having a mechanism to allow you to quickly change the attachment or add a new attachment that you just bought. You would think it would be ridiculous to buy something that was not built with this ease. However, most software systems are not engineered this way.

Don’t believe me? Have you ever had the pleasure of working with your IT colleagues and they tell you the minor change you requested requires testing the entire application and will take three months just to retest? (I’ve literally had to tell this to a customer.) In this case, you have the opposite of a microservices or modular architecture, or what is colloquially named a monolithic architecture. Monolithic applications are an intertwined ball of string (code) and duct tape (data). Making changes requires either the equivalent of digital neurosurgery or taking the virtual hacksaw to systems.

Microservices is a technical architecture approach that emphasizes modularity and independence of software and hardware components. The separation and independence are arguably the most important characteristics. Just as physical objects cannot share the same space, microservices should not share the same digital space. If you have younger kids, you know that having them share the same toys is a recipe for a fight. Therefore, as crazy it sounds, you end up buying the same toy for each kid, like I have. In the IT world, buying everyone the same toy is equivalent to giving everyone their own servers or data centers, which seems very expensive, but this leads to “fighting” in civilized forums like Change Control Board meetings. In the world of cloud, the economics change because of the pay-as-you-go utility model and new paradigms where you don’t even have to worry about servers at all called, wait for it…Serverless. So, PlayStations for all!

So, how does this relate to business agility, speed, and value? Let’s use another example, but a digital one. Your CEO has declared that direct to consumer is an important channel that needs to be focused on. A new ecommerce platform has been created. Customers are initially thrilled, but they are starting to complain that the product recommendations don’t make sense. Also, a new business unit wants to create a new category on the site. The tax rules have changed in a state in which you do business, so the tax calculations have to be updated at time of payment. The problem is how to make all these changes. A huge schedule has to be created to coordinate the code for the different technical components and to make sure they don’t break anything. The next window to deploy these changes is months away.

However, if the ecommerce platform were broken up into independent building blocks, then each change could have been made without coordinating with other teams. That is the benefit of microservices, and it’s how Amazon.com is constructed.

Back in 2010 I attended a conference where I first heard the story of how Amazon.com was architected as thousands of microservices. At that time, Amazon.com was deploying a change every 11.6 seconds! I remember thinking to myself, that’s just not possible. Fast forward to today and it’s estimated that a change is made to Amazon.com once every few seconds. So as Amazon has continued to grow and scale, it’s been able to drive even more frequent change. Mind blown. However, it’s not just about the technical architecture that makes this work, it’s about the business and organizational architecture that we’ll cover in the next series of posts.

Never stop innovating,

Joe