Technology strategy
Macro trends shaping the tech industry
This is the fourth article in Technology Radar Echoes, a series where authors share their insights and experience on the technology problems and solutions driving business differentiation for enterprise leaders. Now in its seventh year, the Thoughtworks Technology Radar is an assessment of trends significantly impacting software development and business strategy created by an international advisory board of technologists.
The digital era is upon us. Enterprises that view software development as a costly overhead and not a competitive capability will struggle. To participate and thrive in this digital world, enterprises must learn to adapt to the uncertainties of our time—get new products to market faster, enhance current products quickly and efficiently, and provide customers with meaningful digital experiences.
To accomplish these goals your enterprise needs to integrate agility/adaptability into three areas: people, process, and technology.
People need to be comfortable with experimentation and change. Processes need to be iterative and enhance learning. Technology, including technical architecture, needs to support rapid delivery of products and services.
The answer to this question is clouded by technologists who are constantly talking about seemingly arcane topics. Which arcane topics need executive attention? One of the most important is microservices. Here’s why.
Microservices impacts people, process, and technology: team organization, processes and practices like DevOps, and realigning architecture to fit the problems we solve rather than by technology layers. Microservices fosters adaptability in each of these areas. It’s worth executive time to understand their potential contributions.
This architecture has some clear benefits. First, each service is highly decoupled from other services, meaning that they are self-contained. Thus, technical changes in one service (for example, a data structure change) cannot affect another service. The services still communicate via messaging, but no service is allowed to modify details of another service.
Second, because developers don’t need to share infrastructure, they can implement each service in a technology stack suitable to the complexity of the problem. Given the complexity of today’s technology stacks, the ability to use simple tools for simple problems and complex tools for complex problems, all in the same application, gives development teams increased flexibility and reduces cost. Leaders value technologists who can elicit the simple from the complex.
Third, each service encapsulates business functionality, making it easier to form teams around a particular problem domain rather than split by job function. For example, service teams typically include developers, business analysts, DBAs, operations, and QA—everything needed to build and deploy the service. This, in turn, cuts down on coordination cost.
Moving from a functional organizational structure to a product or service structure is a growing trend in agile enterprise transformation. Using microservices supports this trend.
Last, because each service is isolated the architecture is both fast and flexible. Changes to services can occur quickly because the scope is small, which give developers new advanced capabilities. Once architects design a system with small, self-contained services, where applications consist of messaging between deployed services, capabilities like multi-variate testing become easy.
For example, the business may be unsure about a future direction for their website. They design two services with similar but distinct capabilities, deploy different versions to different groups of users and harvest the results to drive the direction of future development. Companies like Facebook analyze their users by conducting experiments using this type of A/B testing.
Standardization has always been a mantra of IT organizations as a way to reduce costs. Unfortunately, it also reduces flexibility—the more standardization, the less flexibility. With microservices, architects and developers can design applications with a wider variety of technology stacks that closely mirror the complexity of the problem.
The microservices style of architecture is opposite from the way many enterprises deploy software and allocate IT resources. One of the major goals of many architectural styles was to utilize shared resources (operating systems, database servers, application servers, and so on) effectively. Because the cost of resources impacts the bottom line, companies built software architecture to maximize shared resources.
However, shared resources have a downside. No matter how effectively developers build isolation into these servers, contention for those resources always arises. Sometimes components interfere with one another because of dependency management, or sometimes problems arise from two components fighting over some resource, like CPU. Inevitably, shared components interact in undesirable ways.
A few years ago, something interesting happened: Linux became Good Enough for most enterprises, and Linux variants are commercially free—but that wasn't quite enough to impact architecture.
Next, innovation in open source coupled with agile development techniques encouraged developers to create tools to automate many of the cumbersome manual chores in operations, referred by many as the DevOps revolution.
This brought development teams and IT operations closer together using advanced tools like Puppet, Chef, and Docker. Suddenly, Linux variants were also operationally free, allowing developers the luxury of deploying their components to a pristine operating system with nothing else to interfere. Suddenly, an entire possible class of errors disappears because each component is decoupled from the others.
If developers can build their own realistic environments, they have to coordinate less with operations, which reduces friction across organizational silos. The ability to spin up production-like environments programmatically removes problems with testing, integration, competition over shared environments, and a host of other problems.
Prescriptive governance does have a downside—often, teams must use tools less than ideal for a certain purpose for the sake of standardization. But a more subtle downside lurks as well. For example, consider a large enterprise that has chosen to standardize on a particular message queue. When evaluating all the projects that will need this shared infrastructure, the enterprise architects find the most complex use cases and pick a suitable tool to handle them.
However, many of the projects don't have the most complex use case. Yet, because each project must share the same infrastructure, every team takes on the maximum complexity of other teams. This occurs with databases as well. Many projects only need a simple data store for a few records, without sophisticated querying capabilities, yet end up using an industrial strength database server because it is the standard.
Containerization solves this problem because it moves away from shared infrastructure—each project deploys in their own pristine, containerized environment. Because no impetus exists to choose tools because of sharing, each project picks more suitable tools.
Of course, serious downsides exist if enterprise architects allow each project to choose their own technology stack. We commonly see a practice we've named the "Goldilocks Governance" (where enterprise architects choose a few technology stacks—simple, medium, and complex—and assign new projects according to scale) used in highly decoupled environments. The company still benefits from portable knowledge but steps away from inadvertent over-complication.
For example, if analysts identify a Customer domain, it resides within the its own bounded context. Within the Customer context, developers know all the implementation details: class structures, database schema, and so on.
However, other bounded contexts (like Orders) cannot see those implementation details. While the domains may send messages to each other for coordination purposes, neither domain can pierce the bounded context of another. Thus, developers in one bounded context freely make implementation changes without worrying about breaking other domains.
The container in microservices is the physical manifestation of bounded context in Domain-Driven Design (DDD): each represents an encapsulation barrier to prevent implementation details from interfering with other parts of the system. The isolation provided by the bounded context presents a different way to structure software architecture.
In the past, designing architecture primarily revolved around technical architecture: architecture structural patterns, libraries, frameworks, and so on. For example, the layered architecture is quite common in many organizations:
[Figure 1: Traditional layered architecture]
In Figure 1, the architect split along technical layers, making it easy to swap out an entire layer if needed. For example, if developers needed to change the persistence mechanism, all the relevant code appears in the persistence layer.
How often do developers swap out the entire persistence layer? Virtually never. How often do your teams work on concepts like Customer? Every day!
Where does Customer live in the layered architecture, represented by the peach-colored images in Figure 1? Partially in the presentation layer, the business layer, persistence, and so on. Thus, the common unit of change on projects—to the domains—is poorly supported in the layered architecture because common change affects each layer.
The impact is more severe if different layers represent different parts of the development workforce. For example, a change to Customer will likely entail changes to user interface, business logic, persistence, and other characteristics. If your organization has developers, DBAs, user interface designers, and operations in separate HR silos, the coordination cost to make common changes is enormous.
Microservices, with its emphasis on decoupling and containerization, flips the traditional picture in Figure 1, making the domain the primary architectural element, as shown in Figure 2.
[Figure 2: Domain-centric architecture]
In Figure 2, the layered architecture still exists, but the coupling boundary is the domain, relegating the technical architecture to an implementation detail, now encapsulated within the domain. Building a domain-centric architecture with workers isolated from one another in technology-centered silos is difficult.
One of the significant problems that many technologists building a digital enterprise have is being weighed down by legacy systems that need to be untangled in order to support new initiatives such as mobile applications. Increasingly, these enterprises are using microservices as a key strategy in this untangling process.
Greenfield projects benefit from the DDD exercise to understand their problem domain and where the seams between important parts lie. For existing projects, making the system more modular forces developers to untangle transactional balls of mud and make clearer distinctions between the parts that belong together versus ones that are incidentally coupled.
In 1968, Melvin Conway made a prescient observation about software development which has come to be known as Conway's Law:
In what we have deemed the Inverse Conway Maneuver, many companies now organize cross-functional teams built around domains rather than structured around technology layers. For example, a Customer service might include a business analyst, developers, QA, UX, DBA, and operations person.
Rather than build something passed off to operations for inclusion in the next giant release, the team deploys their service when ready. Many companies using microservices use continuous deployment to get changes into production as quickly as possible.
William Gibson was correct—the future is already here for many companies who view IT competency as a new measure of robustness. Other companies slow to realize this may find their future impacted.
The future is already here, it's just not very evenly distributed.
The digital era is upon us. Enterprises that view software development as a costly overhead and not a competitive capability will struggle. To participate and thrive in this digital world, enterprises must learn to adapt to the uncertainties of our time—get new products to market faster, enhance current products quickly and efficiently, and provide customers with meaningful digital experiences.
To accomplish these goals your enterprise needs to integrate agility/adaptability into three areas: people, process, and technology.
People need to be comfortable with experimentation and change. Processes need to be iterative and enhance learning. Technology, including technical architecture, needs to support rapid delivery of products and services.
Tech agility can’t be ignored—agile people and agile processes can’t make up for clunky technology.
The answer to this question is clouded by technologists who are constantly talking about seemingly arcane topics. Which arcane topics need executive attention? One of the most important is microservices. Here’s why.
Microservices impacts people, process, and technology: team organization, processes and practices like DevOps, and realigning architecture to fit the problems we solve rather than by technology layers. Microservices fosters adaptability in each of these areas. It’s worth executive time to understand their potential contributions.
Technology Agility
The microservices architecture style, featuring extremely small services deployed independently from one another, was popularized by companies like Netflix. Each service contains a discrete bit of business functionality, which is technically isolated from the other services, creating a Lego effect: developers can swap a service for a new one without breaking other services. Like giant Lego models, which can have 75,000 pieces, large digital applications can be built from these Lego-inspired services.This architecture has some clear benefits. First, each service is highly decoupled from other services, meaning that they are self-contained. Thus, technical changes in one service (for example, a data structure change) cannot affect another service. The services still communicate via messaging, but no service is allowed to modify details of another service.
Second, because developers don’t need to share infrastructure, they can implement each service in a technology stack suitable to the complexity of the problem. Given the complexity of today’s technology stacks, the ability to use simple tools for simple problems and complex tools for complex problems, all in the same application, gives development teams increased flexibility and reduces cost. Leaders value technologists who can elicit the simple from the complex.
Third, each service encapsulates business functionality, making it easier to form teams around a particular problem domain rather than split by job function. For example, service teams typically include developers, business analysts, DBAs, operations, and QA—everything needed to build and deploy the service. This, in turn, cuts down on coordination cost.
Moving from a functional organizational structure to a product or service structure is a growing trend in agile enterprise transformation. Using microservices supports this trend.
Last, because each service is isolated the architecture is both fast and flexible. Changes to services can occur quickly because the scope is small, which give developers new advanced capabilities. Once architects design a system with small, self-contained services, where applications consist of messaging between deployed services, capabilities like multi-variate testing become easy.
For example, the business may be unsure about a future direction for their website. They design two services with similar but distinct capabilities, deploy different versions to different groups of users and harvest the results to drive the direction of future development. Companies like Facebook analyze their users by conducting experiments using this type of A/B testing.
Standardization has always been a mantra of IT organizations as a way to reduce costs. Unfortunately, it also reduces flexibility—the more standardization, the less flexibility. With microservices, architects and developers can design applications with a wider variety of technology stacks that closely mirror the complexity of the problem.
The microservices style of architecture is opposite from the way many enterprises deploy software and allocate IT resources. One of the major goals of many architectural styles was to utilize shared resources (operating systems, database servers, application servers, and so on) effectively. Because the cost of resources impacts the bottom line, companies built software architecture to maximize shared resources.
However, shared resources have a downside. No matter how effectively developers build isolation into these servers, contention for those resources always arises. Sometimes components interfere with one another because of dependency management, or sometimes problems arise from two components fighting over some resource, like CPU. Inevitably, shared components interact in undesirable ways.
Containers and Decoupling
In software delivery, there are two critical technical “environments”: the development environment where developers work, and a deployment environment which is the domain of IT operations staff. Traditionally, moving code between these two environments has been fraught with technical errors, lengthy time delays, and organizational miscommunication.A few years ago, something interesting happened: Linux became Good Enough for most enterprises, and Linux variants are commercially free—but that wasn't quite enough to impact architecture.
Next, innovation in open source coupled with agile development techniques encouraged developers to create tools to automate many of the cumbersome manual chores in operations, referred by many as the DevOps revolution.
This brought development teams and IT operations closer together using advanced tools like Puppet, Chef, and Docker. Suddenly, Linux variants were also operationally free, allowing developers the luxury of deploying their components to a pristine operating system with nothing else to interfere. Suddenly, an entire possible class of errors disappears because each component is decoupled from the others.
If developers can build their own realistic environments, they have to coordinate less with operations, which reduces friction across organizational silos. The ability to spin up production-like environments programmatically removes problems with testing, integration, competition over shared environments, and a host of other problems.
21st Century Architectural Agility
In terms of governance, the microservices style of architecture has other benefits. Traditionally, enterprise architects defined the shared technology stacks of the organization to maximize resource usage across projects while minimizing support costs. For example, a large enterprise might standardize on Java and Oracle as their primary development platforms. If everyone is using Oracle, then everything can reside in one industrial strength database.Prescriptive governance does have a downside—often, teams must use tools less than ideal for a certain purpose for the sake of standardization. But a more subtle downside lurks as well. For example, consider a large enterprise that has chosen to standardize on a particular message queue. When evaluating all the projects that will need this shared infrastructure, the enterprise architects find the most complex use cases and pick a suitable tool to handle them.
However, many of the projects don't have the most complex use case. Yet, because each project must share the same infrastructure, every team takes on the maximum complexity of other teams. This occurs with databases as well. Many projects only need a simple data store for a few records, without sophisticated querying capabilities, yet end up using an industrial strength database server because it is the standard.
Containerization solves this problem because it moves away from shared infrastructure—each project deploys in their own pristine, containerized environment. Because no impetus exists to choose tools because of sharing, each project picks more suitable tools.
Of course, serious downsides exist if enterprise architects allow each project to choose their own technology stack. We commonly see a practice we've named the "Goldilocks Governance" (where enterprise architects choose a few technology stacks—simple, medium, and complex—and assign new projects according to scale) used in highly decoupled environments. The company still benefits from portable knowledge but steps away from inadvertent over-complication.
Why did we get here?
The book "Domain-Driven Design" by Eric Evans was the other big influence on microservice architectures. This is ostensibly a technique to decompose a large problem space into domains, or the important entities (like customers and orders) and their relationships (customers place orders) and behavior. Part of the definition of the domain was the concept of a bounded context: each domain formed an encapsulation layer around the implementation details.For example, if analysts identify a Customer domain, it resides within the its own bounded context. Within the Customer context, developers know all the implementation details: class structures, database schema, and so on.
However, other bounded contexts (like Orders) cannot see those implementation details. While the domains may send messages to each other for coordination purposes, neither domain can pierce the bounded context of another. Thus, developers in one bounded context freely make implementation changes without worrying about breaking other domains.
The container in microservices is the physical manifestation of bounded context in Domain-Driven Design (DDD): each represents an encapsulation barrier to prevent implementation details from interfering with other parts of the system. The isolation provided by the bounded context presents a different way to structure software architecture.
In the past, designing architecture primarily revolved around technical architecture: architecture structural patterns, libraries, frameworks, and so on. For example, the layered architecture is quite common in many organizations:
[Figure 1: Traditional layered architecture]
In Figure 1, the architect split along technical layers, making it easy to swap out an entire layer if needed. For example, if developers needed to change the persistence mechanism, all the relevant code appears in the persistence layer.
How often do developers swap out the entire persistence layer? Virtually never. How often do your teams work on concepts like Customer? Every day!
Where does Customer live in the layered architecture, represented by the peach-colored images in Figure 1? Partially in the presentation layer, the business layer, persistence, and so on. Thus, the common unit of change on projects—to the domains—is poorly supported in the layered architecture because common change affects each layer.
The impact is more severe if different layers represent different parts of the development workforce. For example, a change to Customer will likely entail changes to user interface, business logic, persistence, and other characteristics. If your organization has developers, DBAs, user interface designers, and operations in separate HR silos, the coordination cost to make common changes is enormous.
Microservices, with its emphasis on decoupling and containerization, flips the traditional picture in Figure 1, making the domain the primary architectural element, as shown in Figure 2.
[Figure 2: Domain-centric architecture]
In Figure 2, the layered architecture still exists, but the coupling boundary is the domain, relegating the technical architecture to an implementation detail, now encapsulated within the domain. Building a domain-centric architecture with workers isolated from one another in technology-centered silos is difficult.
One of the significant problems that many technologists building a digital enterprise have is being weighed down by legacy systems that need to be untangled in order to support new initiatives such as mobile applications. Increasingly, these enterprises are using microservices as a key strategy in this untangling process.
Greenfield projects benefit from the DDD exercise to understand their problem domain and where the seams between important parts lie. For existing projects, making the system more modular forces developers to untangle transactional balls of mud and make clearer distinctions between the parts that belong together versus ones that are incidentally coupled.
Teams
You will also encounter the team impacts of microservices: how an architectural style drives the restructuring of development teams.In 1968, Melvin Conway made a prescient observation about software development which has come to be known as Conway's Law:
Organizations which design systems...are constrained to produce designs which are copies of the communication structures of these organizations.
The implications of Conway's Law for software development? Your design reflects your team structure. The common team structure in enterprises is driven by the human resources department, who group like technologists together. While a logical sorting algorithm, it works poorly when designing self-contained services.In what we have deemed the Inverse Conway Maneuver, many companies now organize cross-functional teams built around domains rather than structured around technology layers. For example, a Customer service might include a business analyst, developers, QA, UX, DBA, and operations person.
Rather than build something passed off to operations for inclusion in the next giant release, the team deploys their service when ready. Many companies using microservices use continuous deployment to get changes into production as quickly as possible.
Summary
Business executives might dismiss microservices as the latest buzzword, but those who understand the implications of this architecture can reap real benefits. Microservices can increase delivery speed, enhance flexibility, and gain efficiencies. Their use reorganizes work to align on business problem domains rather than technology domains; creates business applications from a collection of independent, more easily developed and maintained, services; better matches the complexity level of the technology solution to the business problem; and builds adaptive architectures that can help restructure existing legacy systems and build new products and services that can quickly respond to changing business conditions.William Gibson was correct—the future is already here for many companies who view IT competency as a new measure of robustness. Other companies slow to realize this may find their future impacted.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
