Formerly known as Wikibon
Search
Close this search box.

Docker is the Least Interesting Part of Docker

Impact: Containers have dramatically changed the way that application developers package and deploy their software. Over the past three years, Docker has become the dominant standard in containers. But IT operations teams need to understand the simplicity of containers brings with it significant new challenges that need to be understood before containers can be widely deployed for production applications.

Understanding Docker Means Knowing about Much More than Docker

In November 2015, Docker, Inc. stated that the Docker Hub had surpassed 1.2B pulls (downloads). Having achieved this in just over two and a half years is an incredible achievement, highlighting the breadth and velocity of community adoption for the Docker container format. For many developers and ISVs, Docker is becoming the de-facto description and packaging format for Cloud Native applications.

 

Image 1: From Artifacts to Applications to Operations – The Stages of Application Deployment (Source: © Wikibon, 2016)
Image 1: From Artifacts to Applications to Operations – The Stages of Application Deployment (Source: © Wikibon, 2016)

But getting an application from a developer’s laptop to a common deployment format is only part of a complete Application Deployment lifecycle. In essence, Docker (the container format) addresses the stage from Artifacts to Applications. But getting that Application into functional Operations is a steep hill to climb, not only technically but also in managing the handoff between Dev and Ops. The following items are needed to move from Applications to Operations:

  • Containers should be digitally signed to ensure a valid source of origination.
  • Containers must be scanned to ensure that they do not contain malware or other known security vulnerabilities.
  • A Container Registry framework must be in place, and should follow security best-practices for any centralized, shared services that distributes digital assets.
  • The container environment must be able to dynamically assign service names and IP addresses to individual containers.
  • The container environment must have a service-discovery service that allows containers to announce their availability, and avoid having to embed service-names or IP addresses within container files.
  • The container environment should have the ability to identify containers not only as individual “hosts”, but also as groups of “clusters”. Clusters should have the ability to easily incorporate load-balancing or proxy services to avoid single points of failure.
  • Since containers should not maintain local data, the container environment should have the ability to offer persistent storage volumes, either through native storage services or database services.
  • The container environment must give Operations the ability to manage the underlying compute resources, whether these are bare-metal, VM or cloud resources.
  • The container environment must give Operations the ability to secure and update the underlying compute resources, with a specific focus on OS updates patching and vulnerability mitigation.

 

Image 2: The Container Technology Stack (Source: © Wikibon, 2015)
Image 2: The Container Technology Stack (Source: © Wikibon, 2015)

 

How Developers and Operations are Modeling Applications at Scale

Beyond these Operational elements within the container environment, there is an emerging technology segment which is focused on how to “model” application environments. While this is often called “Orchestration”, it does not align to the traditional model to deploying and updating live resources. In contrast, these modeling technologies (e.g. Kubernetes, Apache Mesos, Apache Aurora, etc.) are focused on deterministic ways to describe how applications must run in container environments. These modeling frameworks define interactions between services, expected performance, and expected availability. In essence, they are attempting to create a contract (or a “promise of service levels”) between Applications and Operations.

The Breadth of the Container Ecosystem is Growing

At any given time, taking a snapshot of the container ecosystem will result in logo slide that looks something like this:

The Container Landscape (Source: CustomerUP)
Image 3: The Container Landscape (Source: CustomerUP)

Wait an additional three months and that landscape will have changed significantly through acquisitions, new startups emerging and open-source communities evolving. While the community is attempting to keep up, it can be difficult for IT organizations to understand which technologies make the most sense for their business and where value can be added. Unlike the VMware ecosystem of 2005-2010, where Diane Greene famously said, “For every dollar of VMware sold, there will be an additional $8-10 of hardware and services sold.“, the container ecosystem is still trying to figure out how to drive meaningful revenues. The industry is already beginning to see smaller companies move from tool-centric offerings to solution-centric offerings, including Docker’s recent announcement of Docker Data Center. These new offerings are attempting to simplify the deployment and operational challenges of containers, but they will have an impact on ecosystem companies that do not have a platform-centric offering of their own, and are expected to integrate with Docker’s platform.

The Evolution of Structured vs. Unstructured Platforms – Introducing “Composable”

In late 2015, Wikibon identified that the market for Cloud Native application platforms could be segmented into Structured and Unstructured platforms. Even in the short time since that research was published, the market has rapidly evolved. While the Structured platforms are still structured, the Unstructured platforms have evolved to become more opinionated, while maintaining a level of composability. Many of the vendors that Wikibon identified as Unstructured have evolved through organic innovation or acquisition. As such, we expect to revise those research definitions to Structured and “Composable” platforms. The Composable term better reflects the solutions-oriented state of the platform market, while still allowing for the flexibility that some platforms require in their architectures.

Is Your Operations Team Ready for Containers?

In the past six months, a number of independent surveys have been published to identify the level of usage of containers. These range from single digits to mid-teen percentages primarily being driven by Application-centric teams using public cloud resources. Many CIOs have stated that they are not prepared for containers, and in many cases are not aware of the use-cases where containers solve business problems.

There is no doubt that DevOps, Cloud Native applications, microservices and containers are becoming common within Silicon Valley and startups, but how far behind are Enterprise companies? Data from the recent DevOps Survey shows that DevOps is evolving in the Enterprise for VM-centric environments, but it still lags behind for understanding containers. Wikibon sat down with the leaders from the DevOps Enterprise Summit to better understand how large companies are adopting to these faster-moving trends within IT (all videos can be found here):

Action Item: As the use of containers evolves, Operations must begin to understand the technology and the challenges it brings to their current environment. The learning curve needed to gain parity with managed container services may be steep for many IT teams. Wikibon recommends that not only do Operations teams build an internal proof-of-concept environment, but also reach out to the Operations teams of vendors that offer both on-premises and off-premises services. Understanding the way that managed services are delivered, from an operational perspective, will play a critical role in successful interactions between Cloud Native Application and Operations teams.

theCUBE will be at DockerCon http://siliconangle.tv/dockercon16/. Feedback on this research note can be sent to brian.gracely@wikibon.org or @bgracely.

Book A Briefing

Fill out the form , and our team will be in touch shortly.

Skip to content