Deployment and Runtime View

What a machine needs

In the last chapter, we looked at a diverse set of network and physical environments that our software may be deployed into. In this chapter, we’ll focus on the individual instances. They need to be good citizens by providing transparency, accepting control, handling configuration nicely, and managing connections. We’ll see some natural overlap with the stability patterns from the chapter Stability Patterns, since it’s the job of each instance to accept stress and insults with tolerance and grace.

In the car business, they say the engine needs fuel, fire, and air to work. Our version of that is code, config, and connection. Every machine needs the right code, configuration, and network connections.

The vocabulary problem

One problem we’ll run into is that our vocabulary hasn’t really kept up with our technology. For instance, when some people say “server” they might mean a virtual machine running on a physical host in their data center. Others might mean a process inside an operating system, rather than a whole machine image. Technology like containers blur the lines further. A process in a container is also a process on the operating system that hosts the container. Which one should we call the “server?” At the risk of seeming hopelessly pedantic, we’ll try to agree on some terms that may help disambiguate the rest of this section.

Service

A service is a collection of processes across machines that work together to deliver a unit of functionality. A service may have processes from multiple executables (for example, application code plus a database). One service may present a single IP address with load balancing behind the scenes. More on that in Chapter Interconnect. On the other hand, it may have multiple IP addresses using the same DNS name.

Instance

An instance is an installation on a single machine (container, virtual, or physical) out of a load-balanced array of the same executable. A service can be made of multiple different types of executables, but when we talk about instances we refer to processes of the same executable, just running in multiple locations.

Executable

An executable is an artifact that a machine can launch as a process and created by a build process. In a compiled language, this will be a binary, whereas an interpreted language will include sources. For simplicity, “executable” also covers shared libraries that need to be installed before execution.

Process

An operating system process running on a machine. In other words, the runtime image of an executable.

Installation

An installation includes the executable and any attendant directories, configuration files, and other resources as they exist on a machine.

Deployment

Deployment is the act of creating an installation on a machine. It should be automated, with the deployment definition kept in source control.

To make this more concrete, take a look at the “Loan Request” service shown in the following deployment illustration.