How it All Started
Get introduced to the history of deployment and Microservice-based architectures.
We'll cover the following
The monolith
In the beginning, there was monolith architecture. It was easy to deploy and easy to keep it running. We had only one thing (or a few) to keep an eye on. The monolith was not usually deployed very frequently. At the end of a release cycle, the development team would hand the operations team a package. The operations team would deploy and monitor this application to a handful of servers and make sure it was running smoothly. If some of these servers failed, the operations team would manually move the application to the remaining healthy servers.
But it was not perfect.
It was hard, if not impossible, to scale individual components. Changes to one tiny part of the application required a whole redeployment that had to be carefully planned, and the lack of clear boundaries could lead to a design that is not so great.
Microservice-based architectures
Then, the industry started converging to microservice-based architectures. At first, it was a single application that became dozens of small services that could be individually scaled and deployed more easily. Teams started having more autonomy to deploy and monitor their own services, and the development and operations teams became one.
But still, it was not perfect. Having dozens, hundreds, or thousands of services running reliably is no easy task.
Our first challenge is that we probably won’t have a dedicated, physical machine for each application or service we need to run. That would get very expensive, especially when we want to have redundancy. Instead, we need to have several applications sharing the same physical instance. But different applications have different requirements, and each one can depend on different libraries or different versions of the same library.