- In a system consisting of many parts, failure of at least one part is only a matter of time. To avoid any downtime if such a situation occurs, one runs multiple instances of each component. If one of the instances fails, there are still others to serve the requests.
- In a distributed application architecture, we have many moving parts. If Service A needs access to an instance of Service B, then it cannot know where to find such an instance. Instances can be on any random node of the cluster and they can even come and go as the orchestration engine sees fit, so we do not identify the target instance by, say, its IP address and port, but rather by its name and port. A DNS service knows how to resolve a service name into an IP address since it has all the information about all service instances running in the cluster.
- A circuit breaker is a mechanism that helps to avoid cascading failures in a distributed application triggered by a single failing service. The circuit breaker observes a request from one service to another and measures the latency over time and the number of request failures or timeouts. If a certain target instance causes too many failures, the calls to it are intercepted and an error code is returned to the caller, instantly giving the target time to recover if possible, and the caller, in turn, knows instantly that it either should degrade its own service or try with another instance of the target service.
- A monolith is an application that consists of one single code base that is highly coupled. If changes to the code are made, no matter how minimal, the whole application has to be compiled, packaged, and redeployed. A monolith is simple to deploy and monitor in production due to the fact that it has very few moving parts. Monoliths are difficult to maintain and extend. A distributed application consists of many loosely coupled services. Each service originates from its own independent source code base. Individual services can and often have independent life cycles. They can be developed and revised independently. Distributed applications are more difficult to manage and monitor.
- One talks about a blue-green deployment when a currently running version of a service, called blue, is replaced by a new release of the same service, called green. The replacement happens without any downtime since while the blue version is still running, the green version of the service is installed on the system and, once ready, a simple change in the configuration of the router that funnels traffic to the service is needed so that the traffic is now all directed to green instead of blue.