We are now going to talk a bit about why deployments fail. Of course, the reasons could be countless, it seems like there's always something popping up somewhere, and the first thing an end user tests is probably the one thing we did not expect. But let's assume for a moment that we did everything right. What kind of problems do we face when it comes to deployments?

The first category of deployment issues is essentially about correctness from a software perspective. Our microservice might make all sorts of demands about the environment in which it executes; that certain other components are present in the system, that certain configuration files exist, that certain modifications were made to the Windows registry, and so on. If any of those environmental characteristics does not hold, then there is a possibility that the software does not work the same as it did on our development machine. Some concrete issues are:

• Even though a microservice should be self-contained, this is not always the case; rather, it depends on other components to do some work on its behalf. These are its dependencies. For a correct deployment, it is necessary that all dependencies are identified. This identification is quite hard, however, as it is often difficult to test whether the dependency specification is complete. After all, if we forget to specify a dependency, we don't discover that fact if the machine on which we are testing already happens to have the dependency installed.
• Dependencies also need to be compatible with what is expected by the referring component. In general, not all versions of a component will work. This is the case even in the presence of type-checked interfaces, since interfaces never give a full specification of the observable behavior of a component.

Also, components often exhibit build-time variability, meaning that they can be built with or without certain optional features, or with other parameters selected at build time. Even worse, the component might be dependent on a specific compiler, or on specific compilation options being used for its dependencies:

• Components can depend on non-software artifacts, such as configuration files, and user accounts.
• Components can require certain hardware characteristics, such as a specific processor type or a video card. These are somewhat outside the scope of software deployment, since we can at most check for such properties, not realize them if they are missing.
• Finally, deployment can be a distributed problem. A component can depend on other components running on remote machines or as separate processes on the same machine. For instance, a typical multi-tier web service consists of an HTTP server, a server implementing the business logic, and a database server, possibly all running on different machines.

So, we have two problems in deployment; we must identify what our component's requirements on the environment are, and we must somehow realize those requirements in the target environment. Realization might consist of installing dependencies, creating or modifying configuration files, starting remote processes, and so on. As you can see, it's many times easier to say than it is to do!