The last couple of years, Docker and more general containers and container orchestration systems (like Kubernetes), are a very hot topic in the infrastructure and technology world. While most technical people, like software engineers and software architects, are already well acquainted with these terms, for managers and business people the importance of those technologies are still hard to grasp.
This blog aims to introduce some basic concepts for non-technical people about Docker containers, and how it impacts an (your) organisation.
Before diving in the details, some figures to show the explosiveness of the "container" trend in the IT landscape:
- More than 8 billion Docker containers have already been downloaded
- Docker Inc., the company behind Docker, was valuated at $1 billion in 2015, when the company reported less than $10 million in revenues. In early 2017, the revenues of the company are estimated between $25 million and $50 million.
- In 7 funding rounds Docker Inc. has collected $180 million from investors
- Docker is used in all the leading technology companies, like e.g. eBay, Spotify, Yelp…
- Over 3,000 developers worldwide contribute to the evolution of the Docker open-source platform
- Forrester estimates that about 10 percent of enterprises currently use containers in production, but up to a third are testing them.
- A yearly study of Datadog (provider of monitoring software) shows similar trends:
- In 2016 13.6 percent of Datadog’s customers had adopted Docker. One year later that number has grown to 18.8 percent.
- Large companies are often faster adopters than small companies (contrary to most other trends). Nearly 60 percent of organizations running 500 or more hosts have started using Docker.
An impressive track record for sure, but what are the drivers behind this impressive success.
In most organisations Virtual Machines (= VMs) are already common good for years. These VMs allow to run on 1 physical server multiple Virtual Machines (sort of tiny computers inside the server), which have fully independent operating systems, that run isolated inside the main operating system of the server (i.e. the host operating system).
While VMs are embedded in almost each organisation for multiple years, they face some important issues:
- Around 2 GB of disk space is required for each VM (so if you run on 1 server, 5 VMs you already lose 10 GB of disk space)
- Quite some time to activate
- Considerable memory and other resources are used by the VM itself (even if no application running on it)
Containers aim to provide an answer to these issues. While containers provide a similar isolation as Virtual Machines, they do it much more light weight. Instead of deploying a full operating system, containers allow to run multiple isolated systems (= containers) on a single operating system. This means the different containers share the same operating system, while still guaranteeing the isolation of a Virtual Machine. This means containers have a lot less overhead and hence allow a more efficient usage of the system resources than Virtual Machines.
Such a light weight virtualization provides a lot of possibilities and advantages for an organisation:
- Application Portability: containers allow to package just about any application with all its dependencies into a standardized unit (i.e. a shipping container system). This way an application becomes very portable, as users don’t need to spend time in the installation of the applications and all its dependencies (by just deploying the container, a full installation can be done, including all configuration settings).
- Optimize costs: the light weight nature of containers, allows to use machine resources more efficiently compared to traditional Virtual Machines. Typically, a server can contain four-to-six times more application instances in containers than if VMs would be used. This means an organisation can generate huge savings in power and hardware costs, when switching from VMs to containers.
- Create self-sufficient systems: as containers package applications with all their configuration and dependencies into a standardized unit, it becomes very easy to create development and test environments which are identical to the production environment. This means companies can create very easily sandboxes to test specific behaviour in a production-like environment.
- Security: containers come with their own security layer, meaning that a breach in 1 application (container) can not compromise other applications running on the same server. Specific container features allow to further increase security, e.g. a container can be configured as read-only, allowing to secure very strongly read-only applications (like data reporting & visualization applications).
- Resilience: the usage of containers also increases resilience, as failures can be isolated inside 1 Docker container.
- Monitoring: resource monitoring can be done more fine-tuned as resource usage can be monitored at container level, which fits with the scope of the application.
While the principle of containers exists already for several years, the break through has come with the rise of Docker.
Docker is an open-source project, which has simplified the usage of containers and allowed to define a standard for containers (backed-up by several large players in the industry). A very simple set of commands allows to create and manage containers, allowing to move the creation, configuration and deployment of containers to the developers (fully in line with the DevOps philosophy), instead of to operations specialists (which is still the case when using Virtual Machines).
Docker is an open-source project, which has simplified the usage of containers and allowed to define a standard for containers (backed-up by several large players in the industry). A very simple set of commands allows to create and manage containers, allowing to move the creation, configuration and deployment of containers to the developers (fully in line with the DevOps philosophy), instead of to operations specialists (which is still the case when using Virtual Machines).
Docker images are the basis of containers. An image is like a description of the environment you want to run in the container. You specify which operating system you want to start from, which additional tools and libraries to install, which files from your computer to copy to the image and so on.
The success of Docker containers has created a full ecosystem of technologies and companies, providing services and products building further on this technology. For example, 95% of the code developed by the company of Docker, is not directly related to the Docker containers, but to the surrounding tools to accelerate and simplify the usage of containers.
Some examples of the most important tools developed by companies on top of Docker containers are:
- Docker Hub: a way to share containers with the rest of the world. Docker makes containers reusable and shareable (just like GitHub did for source code). Over 500,000 Dockerized applications are already deployed on Docker Hub.
- Docker Compose: define which containers to run and how they are linked together. The tool allows to run all the linked containers with one single command.
- Cluster Management Systems (also called "Container Orchestration Tools"): allow to automatically manage a distributed system, by spinning up and down containers based on the resource needs. The most known container orchestration tools are Kubernetes, Mesos and Docker Swarm, with a clear market consolidation on Kubernetes.
- Service Meshes: allow to control service-to-service communication over a network. Common features provided by a service mesh include service discovery, load balancing, encryption and failure recovery. The most known services meshes are Istio, Linkerd, Consul Connect and Kong Mesh, with a first tendendy on consolidation towards Istio.
The explosive success of Docker is even surpassed by the exponential rise of Kubernetes, for which an impressive ecosystem has been built out in a matter of a few years. Kubernetes is now becoming more and more a sort of operating system for distributed systems, abstracting away all the complexities of managing distributed servers.
Important to note is that these trends go hand-in-hand (all enforcing each other) with other evolutions in the market, i.e.
- The rise of cloud players like AWS (Amazon Web Services), GCP (Google Cloud Platform) and Azure (Microsoft). The use of containers and container orchestration tools is perfectly in line with the philosophy of the cloud, where resources can elastically scale upon the needs.
- DevOps principles, with principles like Continuous Integration and Continuous Deployment, are highly facilitated by containers
- Micro-service architectures are ideal for containers, as each micro-service can be bundled in a container, which can be easily spinned up or down based upon the business needs
The result is that the typical lifespan of a virtualization is decreasing considerably. According to a study of Datadog, VMs have an average lifespan of 23 days, Docker containers without orchestration of 5.5 days and Docker containers with orchestration of less than a day.
This trend is likely to continue, ultimately resulting in "Functions as a Service" (also called serverless functions or lambda functions). This technology allows companies to pay only per function call, i.e. each time a function is called a container is spinned up to run the function and afterwards spinned down. This is the ultimate abstraction of infrastructure, where companies have no notion at all anymore of the underlying servers (infrastructure).
This trend is likely to continue, ultimately resulting in "Functions as a Service" (also called serverless functions or lambda functions). This technology allows companies to pay only per function call, i.e. each time a function is called a container is spinned up to run the function and afterwards spinned down. This is the ultimate abstraction of infrastructure, where companies have no notion at all anymore of the underlying servers (infrastructure).
The above description shows the importance of these new technologies, but also of the speed (faster than any other IT technology in the past) in which this space is evolving and maturing. Banks should therefore invest in specialists in these new technologies, but also consider more and more a switch to public clouds, where these evolutions are followed by specialists of the cloud-providers and abstracted away in managed (container and Kubernetes) setups.
This comment has been removed by the author.
ReplyDelete