In modern software, few names are as white hot as Docker and Kubernetes.
Take Docker for starts: the platform has essentially become synonymous with the container technology at its core. These days, you might very well hear a developer say “Docker” when they’re really referring to containers generally; that same developer most likely assumes Docker is the container platform of choice.
Kubernetes, meanwhile, has been referred to as one of the highest velocity projects in open source history, a claim that holds up upon closer inspection. First developed as an internal tool at Google called Borg, Kubernetes was later spun off as an open source tool for container orchestration.
Early adopters have had a significant head start in their learning curves, but many software professionals and organizations are just now getting to know containers, container orchestration, and related trends. In this post, we’ll explain the what and why of both Docker and Kubernetes. We’ll dig into some of the biggest trends and use cases for these tools, and also cover the fundamentals, including basic questions like, Do I have to pick one or the other? (Spoiler alert: No, you don’t. And we’ll tell you why.)
Let’s jump in!
Docker and containers
According to Docker’s own definition, a container image “is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings.”
In other words, a container wraps up everything an application needs—not just your code but all of its dependencies, libraries, and configurations—and abstracts it away from any of the environments, physical or virtual, in which it will run. Ideally, that means your code runs consistently across environments—from dev to test to production, from a local machine to a cloud instance—without needing to be retooled. Some refer to this as operating system-level virtualization, though “container” is the more common, popular term.
A key reason why Docker has become the household name among container platforms is that it was the first to package advanced Linux kernel features together in a way that allowed software teams to more readily create packageable artifacts that they could run on different servers.
Docker containers made it significantly easier for developers to enjoy parity between their local, testing, staging, and production environments. Essentially, developers can now run the same artifact or Docker container image across all of those environments, from their laptop to production and everything in between.
That makes development workflows and deployments much more streamlined; instead of building out an entire server to run a service or app, you can run a Docker container image on a host and use a small amount of that host’s resources to run that service or app, even across multiple environments.
Especially compared to traditional virtual machine images, containers are “lightweight” and ephemeral, meaning that they are meant to be spun up and down as resources increase or decrease, or as your app needs to scale.
Containerization is hugely advantageous in the age of DevOps, cloud architectures, and increasingly distributed computing environments, all of which has led to Docker’s rapid and widespread adoption.
Kubernetes and container orchestration
Of course, containerized workflows can be complicated. Early adopters of Docker—New Relic among them—found that they were soon running hundreds or even thousands of workloads inside containers. This quickly became an operational challenge; scalability isn’t free.
If you have 10 containers and four applications, container orchestration isn’t that big of a deal. If you have a 1,000 containers and 400 services, it’s a much more complicated picture. Continue increasing those numbers and the complexity follows.
Enter Kubernetes and container orchestration. Kubernetes is a tool for automating the deployment, management, and scaling of containerized applications. And automation is key; it’s one reason why Kubernetes is increasingly a go-to tool for site reliability engineers and other infrastructure and operations pros. Kubernetes makes the ongoing orchestration of potentially thousands of containers manageable; it’s what helps ensure your service is always running.
In the early days, organizations turned to one of several open source tools, Kubernetes included, or built their own tools for managing containers at scale. Kubernetes, however, is becoming to orchestration what Docker became to containers: virtually synonymous.
So, Docker and Kubernetes are emphatically not an either-or choice; rather, it can be helpful to think of Docker and Kubernetes as two significant pieces of a larger system. In fact, a recent survey conducted by The New Stack found that Kubernetes adoption tends to go hand-in-hand with container adoption, with the latter driving the former. (We’ll dig into that a bit more below in the market overview.)
Kubernetes vs. Docker Swarm
If there’s a misconception that Docker and Kubernetes are competitors, or an either-or proposition, it’s not entirely without reason. That’s largely because the Docker ecosystem includes its own container orchestration solution, Docker Swarm, that functions as an alternative to Kubernetes.
Whether or not there’s a clear “winner” in the container orchestration, Kubernetes is becoming the closest thing in 2018. The evidence? Docker added robust support for Kubernetes earlier this year when they unveiled Docker Enterprise Edition 2.0, which enables users to run both Kubernetes and Docker Swarm on the same cluster.
In certain non-production use cases, such as using containers only in test or development environments, using Docker without Kubernetes might be perfectly fine. Docker Swarm has a reputation for being easier to use, whereas Kubernetes typically comes with a steeper learning curve for most users.
But once organizations move large containerized workloads into production, they often find that Kubernetes is the best option (you’ll see some data on that in a moment). Now that Docker has made it easier for enterprises to use Kubernetes, the pairing is almost certain to become even more popular.
Container market overview
Let’s shift gears and quantify the value of containers in dollar terms. 451 Research predicts the application container market will approach $2.7 billion in 2020, up from a projected $1.5 billion in 2018. Not bad considering Docker is only five years old and Kubernetes 1.0 was released in July 2015.
Hard data on container market share is a bit tough to come by because it’s still relatively early days for containers. But the numbers we do have all suggest the same thing: adoption is growing, and it’s growing fast.
451 Research’s quarterly Voice of the Enterprise survey, for example, recently found 23.7% of respondents were already running containers. In a recent New Relic survey, we found this trend was even more pronounced with public cloud users, with 26% more likely to use containers, and 39% more likely to use container orchestration. 451 Research also points to a growing number of enterprises running containers in production environments, indicating that we’re likely at a tipping point where more and more companies will expand their container usage from dev and test environments to production.
As Docker celebrated its fifth birthday in March 2018, the company said there were more than 37 billion container downloads, 3.5 million Dockerized apps, and more than 450 customers of its Enterprise Edition.
Kubernetes adoption is also growing. The New Stack’s ebook, The State of the Kubernetes Ecosystem, captures the experience of many container adopters, noting that many organizations don’t realize how important orchestration is until they begin deploying containers to production environments.
The site shares survey data to underscore this relationship: 60% of organizations that report broad container usage in production also report broad Kubernetes usages, with another 19% saying they’ve begun initial production use of Kubernetes in production. Similarly, 58% of companies that are in the early phases of running containers in production also report being in the initial phase of using Kubernetes in production. Another 22% of respondents are evaluating Kubernetes.
Latest trends: Docker and containers
So what’s driving the demand for containers? There are significant and often intersecting use cases where containers make great sense:
- Multi-cloud environments: You’ll likely hear the term “multi-cloud” more and more, and it means exactly what it sounds like: using multiple cloud services from multiple vendors. When it comes to building applications for multiple public cloud environments, containers (and orchestration) allow a “build it once” approach. The portability of containers also holds considerable appeal in multi-cloud environments.
- Cloud migrations and application modernization: While plenty of organizations are building “cloud native” apps—and, increasingly, containerizing them—plenty of organizations are still running legacy apps. While there are multiple paths to modernizing older applications, often for the purposes of migrating them to a cloud environment, updating legacy apps is another potential driver for container use. David Linthicum, chief cloud strategy officer at Deloitte Consulting, breaks down the potential benefits of using containers for legacy app modernization in From Containers to Microservices: Modernizing Legacy Applications.
- Microservices: As microservices architecture—essentially, breaking down applications into a multitude of smaller, independent services—becomes more popular, many companies are finding that containers and orchestration make a logical strategy for packaging, deploying, and maintaining those microservices, especially at scale.
- Growing community: Like Kubernetes, Docker is open source. It’s virtually inevitable that the Docker community will continue to grow in concert with overall adoption. Docker Hub, for example, allows users to publicly store and share Docker images for others to use, a potentially rich resource for newer users who want to speed up their learning and adoption.
Latest trends: Kubernetes and orchestration
Perhaps the most significant reason for Kubernetes adoption is, in fact, container adoption. As noted above, many organizations are finding that significant container usage, especially in production environments, requires robust orchestration.
There are a couple of other key trends that contribute to Kubernetes’ growth.
- Major platforms embracing Kubernetes: Docker has moved to support Kubernetes in its Enterprise Edition, which is a big deal. But that’s indicative of widespread support in the industry, including from big names. The most recent example is Amazon Web Services (AWS). By far the largest public cloud platform, AWS just launched Amazon Elastic Container Service for Kubernetes, or Amazon EKS for short. Amazon EKS enables users to run containerized apps with Kubernetes on AWS, without having to install or manage their own Kubernetes clusters.
- Kubernetes is a good career move: Site reliability engineers and other operations pros are realizing that adding containers and orchestration expertise—especially Kubernetes expertise—is a smart career choice. On the flip side, savvy enterprises are realizing that Kubernetes usage can help attract cutting-edge talent. Docker touted that there were more than 15,000 Docker-related job postings on LinkedIn.
- Emerging service meshes: Kubernetes isn’t a silver bullet for all things microservices and containers. Critically, Kubernetes and containers have little to say or do regarding service-to-service communication from a routing, security, or discovery perspective. Emerging open source projects like Istio (which has major backers like Lyft, IBM, and Google) handle many service-to-service communication functions by integrating them into the network in a language-agnostic way. The mesh allows developers to focus on business logic and worry less about where the application itself is running. Network-specific features like security policies or routing are provided by the service mesh integrated with the orchestration layer.
Monitoring containers with New Relic
As early adopters of Docker, New Relic is keenly aware of the need for robust, efficient monitoring at all layers of the system: the application or service inside of the container, the container itself, and the orchestration layer. From an ops perspective, we’re especially concerned with providing the ability to see the whole picture, not just one layer. Full-stack visibility is crucial; deploying a container, after all, means having one more thing to monitor.
For software engineers, monitoring containerized apps and orchestration with New Relic provides feedback on how their code performs. When issues occur, they can better understand if it’s a problem in the code, the container, or the orchestration layer.
We’re always working to ensure that, as new capabilities and platforms emerge in the Docker and Kubernetes ecosystems, we’re delivering the monitoring capabilities software teams need to realize their potential, as shown in our Amazon EKS integration.
Indeed, these are exciting, evolving technologies. Docker and Kubernetes are still very young. Many companies and DevOps teams are just scratching the surface of their potential, and there’s still so much more to explore.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.