Chapter 4. Overall Architecture

DevOps achieves its goals partially by replacing explicit coordination with implicit and often less coordination. [p65]

Do DevOps Practices Require Architectural Change?

Overall Architecture Structure

A compiler or interpreter turns modules into binaries, and a builder turns the binaries into components. The development team directly develops modules. Components are results of the modules developed by development teams.

Development teams using DevOps processes are usually small and have limited inter-team coordination. When a team deploys a component, it cannot go into production unless the component is compatible with other components with which it interacts. Ensuring this compatibility require either of the following:

An organization can introduce continuous deployment without major architectural modifications. However, dramatically reducing the time required to place a component into production requires architectural support:

Microservice architecture is an architectural style that satisfies these requirements. It is a good general basis for projects that are adopting DevOps practices. By definition, a microservice architecture consists of a collection of services where each service provides a small amount of functionality and the total functionality of the system is derived from composing multiple services.

The following figure describes a microservice architecture. A user interacts with a single consumer-facing service, which in turn utilizes a collection of other services. We use the terminology service to refer to a component that provides a service and client to refer to a component that requests a service. A single component can be a client in one interaction and a service in another. In a system such as LinkedIn, the service depth may reach as much as 70 for a single user request.

Figure 4.1 User interacting with a single service that, in turn, utilizes multiple other services [Notation: Architecture]

To minimize inter-team coordination, there are three categories of design decisions that can be made globally as a portion of the architecture design, thus removing the need for inter-team coordination: the coordination model, management of resources, and mapping among architectural elements.

Coordination Model

If two services interact, there are two details of the coordination:

The following figure gives an overview of the interaction between a service and its client:

Figure 4.2 An instance of a service registers itself with the registry, the client queries the registry for the address of the service and invokes the service.  [Notation: Architecture]

Netflix Eureka is an example of a cloud service registry that acts as a DNS server and serves as a catalogue of available services, and can further be used to track aspects such as versioning, ownership, service level agreements (SLAs) for the set of services in an organization. Extensions to the registry are further discussed in Chapter 6

Management of Resources

Two types of resource management decisions can be made globally and incorporated in the architecture: provisioning/deprovisioning VMs and managing variation in demand.

Provisioning and Deprovisioning VMs

[p70]

Determining which component controls the provisioning and deprovisioning of a new instance for a service is another important aspect. Three possibilities exist for the controlling component:

  1. A service itself can be responsible for (de)provisioning additional instances.
  2. A client or a component in the client chain can be responsible for (de) provisioning instances of a service
  3. An external component monitors the performance of service instances (e.g., their CPU load) and (de)provisions an instance when the load reaches a given threshold. Amazon’s autoscaling groups provide this capability, in collaboration with the CloudWatch monitoring system.
Managing Demand

The number of instances of an individual service that exist should reflect the demand on the service from client requests. We just discussed several different methods for provisioning and deprovisioning instances, and these methods make different assumptions about how demand is managed.

[p71]

Mapping Among Architectural Elements

We discuss two different types of mappings: work assignments and allocation. Both of these are decisions that are made globally.

Quality Discussion of Microservice Architecture