The microservices value proposition
Examine the benefits of microservice architecture and techniques to achieve them.
Bacteria (source: Geralt via Pixabay)
The microservice architectural style was defined based on common patterns observed across a number of pioneering organizations. These organizations did not consciously implement a microservice architecture. They evolved to it in pursuit of specific goals.
In this chapter, we will explore the common benefits of microservice architecture and how they drive the higher-order goals from not available—speed, safety, and scale; illustrate how the goals of microservice architecture deliver business value; define a maturity model for microservice architecture benefits and goals; and finally, apply this information using a goal-oriented approach to microservice architecture.
Learn faster. Dig deeper. See farther.
To start with, let’s survey the motivations of some early microservice adopters.
Microservice Architecture Benefits
Why are organizations adopting microservices? What are the motivations and challenges? How can the leaders of these organizations tell that taking on the challenges of managing a collection of small, loosely coupled, independently deployable services is actually paying off for the company? What is the measure of success? Surveying the early adopters of microservices, we find that the answers to these questions vary quite a bit. However, some common themes emerge and tie back to the mantra of “balancing speed and safety at scale.”
Werner Vogels of Amazon describes the advantages of their architecture as follows:
We can scale our operation independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration.
Werner Vogels, Chief Technology Officer, Amazon Web Services
By focusing on scalability and component independence, Amazon has been able to increase their speed of delivery while also improving the safety—in the form of scalability and availability—of their environment.
UK e-retailer Gilt is another early adopter of microservice architecture. Their Senior Vice President of Engineering, Adrian Trenaman, listed these resulting benefits in an InfoQ article:
-
Lessens dependencies between teams, resulting in faster code to production
-
Allows lots of initiatives to run in parallel
-
Supports multiple technologies/languages/frameworks
-
Enables graceful degradation of service
-
Promotes ease of innovation through disposable code—it is easy to fail and move on
The first three points help speed up software development, through organizational alignment and independent deployability, as well as polyglotism. The last two points speak to a safe environment that facilitates replaceability of services.
Social media pioneer Hootsuite has observed efficiency benefits in their microservice adoption based on the tunability of the system:
Some services require high availability, but are low volume, and it’s the opposite for other services. A microservice approach allows us to tune for both of these situations, whereas in a monolith it’s all or nothing.
Beier Cai, Director of Software Development, Hootsuite
With a more granular set of components, Hootsuite is able to independently manage their services and achieve greater efficiency.
Clay Garrard, Senior Manager of Cloud Services at Disney, found that although there was work done to modularize the code base of their monolithic applications, the domain boundaries were not clear. This meant that small changes often led to large deployments.
With microservices, we have reduced the time it takes to deploy a useful piece of code and also reduced the frequency of deploying code that hasn’t changed. Ultimately we strive to be flexible in our interpretation of microservice architecture, using its strengths where we can, but realizing that the business does not care about how we achieve results, only that we move quickly with good quality and flexible design.
Clay Garrard, Senior Manager of Cloud Services, Disney
The primary driver here is speed, as requested directly from the business. However, there is also an emphasis on safety—through independent deployability and testability—as well as future-proofing through composability.
Lastly, SoundCloud sought to solve the following problem when they evolved to a microservice architecture:
The monolithic code base we had was so massive and so broad no one knew all of it. People had developed their own areas of expertise and custodianship around submodules of the application.
Phil Calçado, former Director of Engineering, SoundCloud
By embracing microservices, they were able to overcome this issue and improve the comprehensibility of their software system.
There are common goals and benefits that emerge from these implementation stories. The goal of improving software delivery speed as functional scope grows is realized through greater agility, higher composability, improved comprehensibility, independent service deployability, organizational alignment, and polyglotism. The goal of maintaining software system safety as scale increases is achieved through higher availability and resiliency, better efficiency, independent manageability and replaceability of components, increased runtime scalability, and more simplified testability. Now let’s explore how these goals and benefits derive business value for organizations that employ microservice architecture.
Deriving Business Value
Successful companies do not focus on increasing software delivery speed for its own sake. They do it because they are compelled by the speed of their business. Similarly, the level of safety implemented in an organization’s software system should be tied to specific business objectives. Conversely, the safety measures must not get in the way of the speed unnecessarily. Balance is required.
For each organization, that balance will be a function of its delivery speed, the safety of its systems, and the growth of the organization’s functional scope and scale. Each organization will have its own balance. A media company that aims to reach the widest possible audience for its content may place a much higher value on delivery speed than a retail bank whose compliance requirements mandate specific measures around safety. Nonetheless, in an increasingly digital economy, more companies are recognizing that software development needs to become one of their core competencies.
In this new business environment, where disruptive competitors can cross industry boundaries or start up from scratch seemingly overnight, fast software delivery is essential to staying ahead of the competition and achieving sustainable growth. In fact, each of the microservice architecture benefits that drive delivery speed contribute real business value:
-
Agility allows organizations to deliver new products, functions, and features more quickly and pivot more easily if needed.
-
Composability reduces development time and provides a compound benefit through reusability over time.
-
Comprehensibility of the software system simplifies development planning, increases accuracy, and allows new resources to come up to speed more quickly.
-
Independent deployability of components gets new features into production more quickly and provides more flexible options for piloting and prototyping.
-
Organizational alignment of services to teams reduces ramp-up time and encourages teams to build more complex products and features iteratively.
-
Polyglotism permits the use of the right tools for the right task, thus accelerating technology introduction and increasing solution options.
Likewise, digital native consumers expect always-on services and are not shy about changing corporate allegiances. Outages or lost information can cause them to take their business elsewhere. A safe software system is indispensable. The safety-aligned benefits discussed earlier also provide particular business value:
-
Greater efficiency in the software system reduces infrastructure costs and reduces the risk of capacity-related service outages.
-
Independent manageability contributes to improved efficiency, and also reduces the need for scheduled downtime.
-
Replaceability of components reduces the technical debt that can lead to aging, unreliable environments.
-
Stronger resilience and higher availability ensure a good customer experience.
-
Better runtime scalability allows the software system to grow or shrink with the business.
-
Improved testability allows the business to mitigate implementation risks.
Clearly, microservice architecture has the potential to provide numerous business benefits. However, not every organization needs every benefit, and not every microservice architecture is capable of delivering all of them. With that in mind, let’s now look at how an organization can combine its business objectives with the potential benefits of microservice architecture to tailor a goal-oriented approach.
Defining a Goal-Oriented, Layered Approach
In spite of the fact that microservice architecture was originally a reaction to the limitations of monolithic applications, there is a fair amount of guidance in the industry that says new applications should still be built as monoliths first. The thinking is that only through the creation and ownership of a monolith can the right service boundaries be identified. This path is certainly well trodden, given that early microservice adopters generally went through the process of unbundling their own monolithic applications. The “monolith first” approach also appears to follow Gall’s Law, which states that, “A complex system that works is invariably found to have evolved from a simple system that worked.” However, is a monolithic application architecture the only simple system starting point? Is it possible to start simple with a microservice architecture?
In fact, the complexity of a software system is driven by its scale. Scale comes in the form of functional scope, operational magnitude, and change frequency. The first companies to use microservice architecture made the switch from monolithic applications once they passed a certain scale threshold. With the benefit of hindsight, and with an analysis of the common goals and benefits of microservice architecture, we can map out a set of layered characteristics to consider when adopting microservice architecture.
Modularized Microservice Architecture
Modularity … is to a technological economy what the division of labor is to a manufacturing one.
W. Brian Arthur, author of The Nature of Technology
At its most basic level, microservice architecture is about breaking up an application or system into smaller parts. A software system that is modularized arbitrarily will obviously have some limitations, but there is still a potential upside. Network-accessible modularization facilitates automation and provides a concrete means of abstraction. Beyond that, some of the microservice architecture benefits discussed earlier already apply at this base layer.
To help software delivery speed, modularized services are independently deployable. It is also possible to take a polyglot approach to tool and platform selection for individual services, regardless of what the service boundaries are. With respect to safety, services can be managed individually at this layer. Also, the abstracted service interfaces allow for more granular testing.
This is the most technologically focused microservice architecture layer. In order to address this layer and achieve its associated benefits, you must establish a foundation for your microservice architecture. This will be discussed in detail in not available.
Cohesive Microservice Architecture
The greater the cohesion of individual modules in the system, the lower the coupling between modules will be.
Larry Constantine and Edward Yourdon, authors of Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design
The next layer to consider in your microservice architecture is the cohesion of services. In order to have a cohesive microservice architecture, it must already be modularized. Achieving service cohesion comes from defining the right service boundaries and analyzing the semantics of the system. The concept of domains is useful at this layer, whether they are business-oriented or defined by some other axis.
A cohesive microservice architecture can enable software speed by aligning the system’s services with the supporting organization’s structure. It can also yield composable services that are permitted to change at the pace the business dictates, rather than through unnecessary dependencies. Reducing the dependencies of a system featuring cohesive services also facilitates replaceability of services. Moreover, service cohesion lessens the need for highly orchestrated message exchanges between components, thereby creating a more efficient system.
It takes a synthesized view of business, technology, and organizational considerations to build a cohesive system. This can be addressed through service design, which is the focus of not available.
Systematized Microservice Architecture
The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.1
Alan Kay, 1998 email to the Squeak-dev list
The final and most advanced layer to consider in a microservice architecture is its system elements. After breaking the system into pieces through modularization, and addressing the services’ contents through cohesion, it is time to examine the interrelationships between the services. This is where the greatest level of complexity in the system needs to be addressed, but also where the biggest and longest-lasting benefits can be realized.
There are two ways speed of delivery is impacted in a systematized microservice architecture. Although a single service may be understandable even in a modularized microservice architecture, the overall software system is only comprehensible when the connectivity between services is known. Also, agility is only possible when the impacts of changes on the whole system can be identified and assessed rapidly. This applies on the safety side as well, where runtime scalability is concerned. Lastly, although individual components may be isolated and made resilient in a modularized or cohesive microservice architecture, the system availability is not assured unless the interdependencies of the components are understood.
Dealing with complex systems requires a careful approach based on influence versus control. The system aspects of microservice architecture are discussed in detail in Chapters not available and not available.
Maturity Model for Microservice Architecture Goals and Benefits
These layered characteristics—modularized, cohesive, and systematized—help to define a maturity model that serves a number of purposes. First, it classifies the benefits according to phase and goal (speed or safety) as discussed previously. Secondly, it illustrates the relative impact and priority of benefits as scale and complexity increase. Lastly, it shows the activities needed to address each architectural phase. This maturity model is depicted in Figure 1-1.
Note that an organization’s microservice architecture can be at different phases for different goals. Many companies have become systematized in their approach to safety—through automation and other operational considerations—without seeking the speed-aligned system-level benefits. The point of this model is not for every organization to achieve systematized actualization with their microservice architecture. Rather, the model is meant to clarify goals and benefits in order to help organizations focus their microservice strategies and prepare for what could come next.
Applying the Goal-Oriented, Layered Approach
Now we have a good understanding of how a microservice architecture can bring value to an organization, and a model for understanding what characteristics can bring what goals and benefits at what stage of adoption. But what about your organization? What are your business goals? What problems do you need to solve? It is a common misstep to start down the microservices path for its own sake without thinking about the specific benefits you are targeting. In other cases, some organizations aim for a high-level goal and then only implement one aspect of microservices while ignoring its founding conditions. For example, an organization with a high-level divide between development and operations—an organizational red flag—might execute a containerization strategy on their existing applications and then wonder why they didn’t speed up their software development sufficiently. A broad perspective is needed.
To begin with, define the high-level business objectives you want to accomplish, and then weigh these against the dual goals of speed and safety. Within that context, consider the distinct benefits you are targeting. You can then use the maturity model to determine the complexity of the goal, and identify the best approach to achieve it.
Holger Reinhardt, CTO of the German digital media group Haufe-Lexware, provides an example of a goal-oriented approach in action. One of Haufe’s initial attempts at microservice architecture was on their monolithic service platform, which included functions such as user management and license management. The first attempt was explicitly focused on changing the architecture from monolith to service-enabled software system. The results were not positive. However, when they evaluated the main issues with the application—particularly the operational inefficiencies around it—they changed their approach from refactoring the existing architecture to automating the problematic deployment process. Through a small investment, they were able to take their service platform deployment downtime from 5 days to 30 minutes. Their next iteration will focus on reducing QA time through automation and a switch in methodology from white-box to black-box testing. Following these methodological changes, they will identify the domains in their monolithic application that require the greatest speed of innovation and unbundle those first. By taking an iterative approach tied to clear goals, they are able to measure success quickly and change course if needed.
Summary
This chapter has covered a lot of ground that should help you define a strategy for applying a microservice architecture in your organization. We first analyzed the reasons the early adopters of microservice architecture chose this style. Next, we looked into the common goals and benefits of microservices, how they relate to each other, and what business objectives they can drive. Lastly, we defined a maturity model that can be used to target the right goals and benefits for applying a microservice architecture in your organization. You should now be ready to roll up your sleeves and learn a design-based approach to microservice architecture.