In this and the subsequent chapters, we will talk a lot about concepts that might not be familiar to everyone. To make sure we all talk the same language, let's briefly introduce and describe the most important of these concepts or words:
| VM | Acronym for virtual machine. This is a virtual computer. |
| Node |
Individual server used to run applications. This can be a physical server, often called bare metal, or a VM. A node can be a mainframe, supercomputer, standard business server, or even a Raspberry Pi. Nodes can be computers in a company's own data center or in the cloud. Normally, a node is part of a cluster. |
| Cluster | Group of nodes connected by a network used to run distributed applications. |
| Network | Physical and software-defined communication paths between individual nodes of a cluster and programs running on those nodes. |
| Port | Channel on which an application such a web server listens for incoming requests. |
| Service | This, unfortunately, is a very overloaded term and its real meaning depends on the context in which it is used. If we use the term service in the context of an application such as an application service, then it usually means that this is a piece of software that implements a limited set of functionality which is then used by other parts of the application. As we progress through this book, other types of services that have a slightly different definition will be discussed. |
Naively said, a distributed application architecture is the opposite of a monolithic application architecture, but it's not unreasonable to look at this monolithic architecture first. Traditionally, most business applications have been written in such a way that the result can be seen as one single, tightly coupled program that runs on a named server somewhere in a data center. All its code is compiled into a single binary or a few very tightly coupled binaries that need to be co-located when running the application. The fact that the server, or more general host, on which the application is running has a well-defined name or static IP address is also important in this context. Let's look at the following diagram to illustrate this type of application architecture a bit more clearly:
In the preceding figure, we see a server named blue-box-12a with an IP address of 172.52.13.44 running an application called pet-shop, which is a monolith consisting of a main module and a few tightly coupled libraries.
Now, let's look at the following figure:
Here, all of a sudden, we don't have only a single named server anymore, but we have a lot of them and they don't have human-friendly names, but rather some unique IDs that can be something like a universal unique identifier (UUID). The pet shop application, all of a sudden, also does not consist of a single monolithic block anymore but rather of a plethora of interacting yet loosely coupled services such as pet-api, pet-web, and pet-inventory. Furthermore, each service runs in multiple instances in this cluster of servers or hosts.
You might be wondering why we are discussing this in a book about Docker containers, and you are right to ask. While all the topics we're going to investigate apply equally to a world where containers do not (yet) exist, it is important to realize that containers and container orchestration engines help to address all the problems in a much more efficient and straightforward way. Most of the problems that used to be very hard to solve in a distributed application architecture become quite simple in a containerized world.