Dominant Designs in Software Engineering: MicroServices Architecture
This is part one of the Dominant Designs, a series of articles taking an in-depth look into the emergence of 4 different dominant designs in software engineering and how to recognize them in an acquisition.
________________________________________________________________
Software development is an art. But unlike art, software has to work. It has business problems to solve, users to serve, and content to deliver.
- The Tao of Microservices, Richard Rodger
Dominant technologies exist in every industry. The original iPhone’s candy bar design became dominant in the smartphone industry and still is. QWERTY keyboard, the Douglas DC-3, the Apple 1, VHS, and many other iconic products all dominated their market, so much so that other brands started copying them, even if the dominant design had flaws.
Now the part about dominant designs existing in every industry holds true for software engineering as well. In fact, as of 2020, there are 4 distinct technologies that are considered dominant: Microservices Architecture, Serverless Compute, DevOps, and Cloud-Native Design Patterns.
Why Multiple Dominant Designs Emerged in Software Engineering? (and why they’re important)
The phrase “dominant design” implies that there can only be one but that, of course, isn’t true. All the technologies I talk about in this series have emerged as dominant in their own right and they do not compete with each other. They’ve already competed with other architectures in software engineering and have come out on top — the crème de la crème if you will.
This means that companies do not have to choose between them. In fact, choosing one design while discarding others isn’t recommended at all. A firm can and should consider each of these technologies when it builds out its solutions today. These designs are relevant to different areas of software architecture and engineering.
Understanding the differences between these designs is important for deploying them correctly, not to choose which one is simply “best” for the entire company. This series is meant to help business owners and executives map out their software side growth, and plan ahead by knowing the associated costs of each of these designs.
Furthermore, the dominant designs are crucial in mergers and acquisitions as a tool and mechanism to scale existing technology and support the growth trajectory of an M&A deal from a software perspective.
What’s Common Between These Dominant Designs?
All four of the designs I talk about in this series have the following in common:
- They’re all built to scale.
- They’re all very optimized for growing enterprises.
- They’re all efficient and cost-effective methods of creating software.
Because of this, they’re all preferred by enterprises over other designs like the older and less efficient monolithic architecture.
Note that there is no “best for all” option. Each technology has its benefits and trade-off. This article is meant to help you understand what the Microservices architecture is and how it scales and improves the overall quality of your products.
What is Microservices Architecture?
Amazon’s famous “2 Pizza Policy” on a Microservices architecture.
Beneath architectures, components, APIs and all the buzzwords in between, microservices architecture is an incredibly simple concept to understand. It’s a method of building software while focusing on the very small blocks of code. Each block represents a micro service, which is basically a product in itself, broken down to more fundamental levels. Then all similar microservices, that change for the same reason are sorted and grouped together.
The most important thing is that each block or microservice is independent of the other and communicate via APIs. In fact, here’s just how much independence (and control) engineers have in a microservices architecture:
In a traditional architecture, services run inside processes and processes run on servers. Processes and services are types of containers that bunch similar services together but containers severely limit the flexibility of an architecture. For instance, to restart a single service, it’s entire container (the process) would have to be restarted, killing all of the other similar services inside that process.
But in a microservices architecture, each service inside its own separate environment (container) that it doesn’t share with any other service. This means that microservices can be changed, restarted, and removed without affecting any other service.
This characteristic makes using microservices to create one large service incredibly efficient at scaling up and down. The interconnectedness of a traditional architecture (like monolithic) makes it similar to a maze (as it scales up) while the isolation of a microservices architecture keeps everything neat. Allow me to illustrate…
A self-contained monolithic architecture. As you can see, interconnectedness can get messy.
Each block is completely isolated and independent, meaning the blocks can be removed, added, or otherwise changed without affecting the rest of the architecture. The blocks communicate via APIs (not pictured here).
Because of all of these characteristics, microservices have become a dominant design. To put the dominance into perspective, 63% of the organizations surveyed are building some (18%) or all (46%) of their applications using microservices.
How The Microservices Architecture Became a Dominant Design?
Traditionally, most systems were built on the monolithic architecture (which was once a dominant design itself) but with time, enterprises and especially small businesses and startups started requiring more agility and flexibility in their workflow. In many cases, software development was outsourced to different teams that had to work together. All of this meant that monolithic was no longer an efficient way of developing software. So companies turned to microservices, a simpler but more powerful alternative to the designs of old.
- It’s Easier to Build Apps
The fact that each part of the software can be broken down to its basic constituents or features and still be operable independent of others means that an application can be as simple as the developer wants it to be. This makes microservices perfect for the “lean startup” mentality of today where businesses focus on building the minimal viable product or a product that requires resembles the actual product but with minimum effort, time, and money.
For instance, with microservices Netflix could be just a video streaming app, or a video catalog app, or even just an app to rate movies and TV series.
Microservices make applications more modular. Speaking of which…
2. It’s Much Easier (and Faster) to Scale
The modularity of the microservices architecture means that each part of the software can be scaled independently of the other. Continuing the example of Netflix, developers can scale up only the video streaming capabilities of the entire architecture on Fridays to keep up with the expected load while not changing anything else.
Furthermore, the isolation present in a microservices architecture means that each microservice can be developed, tested, deployed, and scaled up or down without it affecting the rest of the software at all. This is crucial because it significantly cuts down the time and effort required to push updates or make the product available to more people.
3. Promote Autonomous Development and Cross-functional Teams
This is a multi-faceted benefit. Since each microservices in itself is an application that can run independently, it can be developed as such as well. For instance, to build something as massive as Netflix, you would need a microservices architecture that has 500–700 independent microservices, but each of these services could be developed by an independent team of developers at the same time. While in a monolithic architecture, the developers might have to develop the first 150 services together before they can start on the next 100.
In a monolithic architecture, the software will only work in layers, so it needs to be developed together, which means one team cannot work on the outer layers while the other work on the inner layers.
In a microservices architecture, the product is just a bunch of other smaller, independent products (microservices) working together, which means different teams can develop the different microservices at once and just connect them together using APIs.
Another benefit of independence is that teams do not have to be together. In fact, each team can be separated by hundreds or thousands of miles, have minimal communication, and still build a fully functional application.
4. Building Services Around Business Capabilities
Finally, multiple microservices that work to achieve a similar end goal (like streaming video) can be organized together to simplify things even further. However, businesses can take a different approach as well. Instead of developing services first and then organizing them together, microservices can be built as business capabilities.
For instance, for an eCommerce application, the team may identify the following capabilities: inventory management, user management, delivery management, and reviews. Now different microservices can be built and added to the architecture in the form of business capabilities.
In other words, microservices aren’t just software, pieces of code, or projects. Each microservice can be developed as an independent product that is often bundled with other products to offer an all-around great user experience.
Companies Using Microservices Architecture
Some of the most successful names in technology have made the jump to a microservices architecture in the last ten years. Here are some of them:
- Netflix: From Monolith to 700 Microservices
In 2008, Netflix suffered a massive data corruption — meaning millions of subscribers around the world couldn’t stream anything for 11 hours. Even after the service, it took days to fix the entire issue. Netflix decided to jump ship. Dump the old monolithic architecture and move everything to a microservices architecture hosted on AWS.
In 2008, Netflix became the first major company to do so.
Netflix broke down its monolithic architecture to approximately 700 independent microservices. Netflix leveraged the ability to simply duplicate many of the microservices in order to rapidly scale up to new parts of the world and added new functionality with minimum downtime. The end result looked something like this:
The utterly complex flow diagram is actually one of the most efficient and effective large scale implementations of the microservices architecture.
2. Amazon
Amazon started off as one application talking to a back end that was scaled up as the company expanded. But after years of growth, the front end just couldn’t be scaled up anymore. The monolith system was also slow with updates and very ineffective when it came to server space (a lot of it was unused and on holidays, it became insufficient).
So Amazon slowly started transitioning from a two-tier monolith system to a loosely coupled service-oriented architecture. From there, Amazon moved completely to a microservices architecture. Today, the single Amazon.com webpage is a separate microservice hosted on a single server, with hundreds of other microservices running on their own servers.
Amazon also fixed its core problem of slow deployment of code with microservices and the tech giant now pushes code every 11.7 seconds.
3. Uber
One city. One monolith architecture. And all of Uber’s business capabilities (rides, billing, ratings, etc.) in one codebase. That’s all Uber had when it started in 2009. This meant that when Uber updated any of its features in any one of the capabilities, it had to update everything else and deploy it all at once as well.
The novelty of having “one, clean codebase” tends to wear out quickly when you’re rapidly expanding to cities around the country and constantly updating your architecture. So, Uber followed suit of Netflix and soon started to transition to a service-oriented architecture, particularly, the microservices architecture — enjoying similar benefits as Netflix and Amazon.
Finding Business Value in (Migrating to) Microservices
From what’ve discussed so far, a microservices architecture seems like the obvious choice for software development in 2020. But is it that obvious when you’re migrating from a monolithic architecture to a microservices one?
Well, not quite.
For instance, your problems with your current architecture might not be as severe as they were in the case of Netflix or as growth-inhibiting as in the case of Uber. Maybe the monolithic architecture works “just fine as it is”. In this case, how do you convince your team (and maybe even yourself) that microservices is the way ahead?
Documenting the problems you’ve had with your current architecture is one way. Showing the business value in migrating to microservice is another. Ask yourself these questions:
- How much money can you save by using less server space?
- How much will the user experience improve with quicker updates and fewer bugs?
- How much of the workload will reduce?
- How much growth are you expecting in the next few years?
Each question will reveal how much business value you will gain through a migration.
Microservices architecture is an incredibly powerful technology that has been proven to work by some of the biggest companies on the planet but there’s another cost-effective technology that’s quickly emerging as a dominant design — serverless computing. Read the next installment in this series to read about the pay-per-use life of serverless computing.
This is the first article in Dominant Designs, a 5-part series of articles taking an in-depth look into the emergence of 4 different dominant designs in software engineering and how to recognize them in an acquisition. Click here to read Dominant Designs in Software Engineering: Serverless Compute.
