Even though CM alleviated some of the infrastructure problems, it did not make them go away. The problem is still there, only in a smaller measure. Even though it is now defined as code and automated, infrastructure hell continues to haunt us. Too many often conflicting dependencies quickly become a nightmare to manage. As a result, we tend to define standards. You can use only JDK7. The web server must be JBoss. These are the mandatory libraries. And so on, and so forth. The problem with such standards is that they are an innovation killer. They prevent us from trying new things (at least during working hours).
We should also add testing into the mix. How do you test a web application on many browsers? How do you make sure that your commercial framework works on different operating systems and with different infrastructure? The list of testing combinations is infinite. More importantly, how do we make sure that testing environments are exactly the same as production? Do we create a new environment every time a set of tests is run? If we do, how much time does such an action take?
CM tools were not addressing the cause of the problem but trying to tame it. The difficulty lies in the concept of mutable deployments. Every release brings something new and updates the previous version. That, in itself, introduces a high level of unreliability.
The solution to those, and a few other problems, lies in immutable deployments. As a concept, immutability is not something that came into being yesterday. We could create a new VM with each release and move it through the deployment pipeline all the way until production. The problem with VMs, in this context, is that they are heavy on resources and slow to build and instantiate. We want both fast and reliable. Either of those without the other does not cut it in today's market. Those are some of the reasons why Google has been using containers for a long time. Why doesn't everyone use containers? The answer is simple. Making containers work is challenging and that's where Docker enters the game. First, they made containers easy to use. Then they extended them with some of the things that we, today, consider a norm.
With Docker we got an easy way to create and run containers that provide immutable and fast deployments and isolation of processes. We got a lightweight and self-sufficient way to deploy applications and services without having to worry about infrastructure.
However, Docker itself proved not to be enough. Today, we do not run things on servers but inside clusters and we need more than containers to manage such deployments.
The DevOps 2.0 Toolkit
If you liked this article, you might be interested in The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices book.
The book is about different techniques that help us architect software in a better and more efficient way with microservices packed as immutable containers, tested and deployed continuously to servers that are automatically provisioned with configuration management tools. It's about fast, reliable and continuous deployments with zero-downtime and ability to roll-back. It's about scaling to any number of servers, the design of self-healing systems capable of recuperation from both hardware and software failures and about centralized logging and monitoring of the cluster.
In other words, this book envelops the full microservices development and deployment lifecycle using some of the latest and greatest practices and tools. We'll use Docker, Ansible, Ubuntu, Docker Swarm and Docker Compose, Consul, etcd, Registrator, confd, Jenkins, nginx, and so on. We'll go through many practices and, even more, tools.
This post is part of a new blog series all about the DevOps 2.0 Toolkit. Follow along in the coming weeks. Each post builds upon the last!
The DevOps 2.0 Toolkit
Configuration Management (The DevOps 2.0 Toolkit)
Containers and Immutable Deployments (The DevOps 2.0 Toolkit)
Cluster Orchestration (The DevOps 2.0 Toolkit)
Service Discovery (The DevOps 2.0 Toolkit)
Dynamic Proxies (The DevOps 2.0 Toolkit)
Zero-Downtime Deployment (The DevOps 2.0 Toolkit)
Continuous Integration, Delivery, And Deployment (The DevOps 2.0 Toolkit)
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.