Docker put Kubernetes inside the enterprise operating model
Docker Enterprise Edition 2.0 put Kubernetes alongside Swarm, with shared permissions, networking and image governance. The enterprise case rested on helping existing teams adopt it without rebuilding their operations.
On 17 April 2018, Docker announced that Enterprise Edition 2.0 was immediately available. Kubernetes joined Swarm inside a platform intended to manage containerised applications across enterprise environments. Docker was selling a way to bring Kubernetes into the permissions, registries and operating routines that an organisation needed around its applications.
Docker's own operations team said it had already moved selected production services onto Kubernetes while retaining others on Swarm. The example showed a possible adoption path inside an existing environment, although one internal migration could not establish how widely enterprises had adopted the release or how easily other companies would make the change.
The operating team gained another choice
Docker described Kubernetes and Swarm running simultaneously within the same cluster, with applications managed through a common control plane. Developers could use native Kubernetes interfaces, while administrators had graphical workflows for cluster and registry management and permissions assigned by role. The commercial proposition was to make another deployment option available without requiring a wholly separate operating structure.
For an enterprise buyer, that could change the shape of a trial. A team could investigate whether Kubernetes suited an application while retaining familiar administration around it. The relevant benefit was continuity of operating practice. It would still depend on the customer's starting environment, the capabilities it needed and the effort required to support both orchestrators during a transition.
Docker's migration was deliberately partial
Docker engineer Brett Inman said the team selected a few services for Kubernetes while leaving others on Swarm. The company retained its existing logging and monitoring systems and made minor routing updates to support the two alongside each other. Its application teams translated existing service definitions for Kubernetes, without changing application code in that particular migration.
Those details were more useful than a general claim that Kubernetes had become easy. They identified work that could be preserved and work that still changed. They also came from the supplier's own operations. Another organisation needed evidence from its own applications before assuming equivalent effort, reliability or access to expertise.
Shared infrastructure needed explicit boundaries
Docker's account described Resource Sets, permissions assigned by role and Kubernetes namespaces as tools for organising workloads and access across teams. The product announcement also described integration with corporate LDAP and Active Directory systems. These capabilities addressed a recurring enterprise issue: giving developers useful autonomy while keeping administration and access aligned with organisational responsibilities.
A namespace, however, should not be read as a universal security boundary. Account permissions, placement on particular nodes and network communication are distinct controls. A buyer needed to examine which of these its policy required and how each was enforced. The release's support for mixed infrastructure similarly did not mean every operating system, application and Kubernetes configuration had identical capabilities.
The image had a route to production
The platform extended beyond scheduling a running container. Docker described image signing, vulnerability scanning and policies governing promotion between repositories, with deployment rules controlling which approved images could run. It also introduced registry caching and mirroring for distributed organisations. An image could therefore be governed while moving from development toward production and across locations.
Scroll to view all columns
| Comparison | Running applications | Moving application images |
|---|---|---|
| Platform work | Schedule workloads and administer clusters | Store, promote, cache and mirror images |
| Governance | Roles, resource access and workload placement | Signing, scanning and deployment approval rules |
| Team responsibility | Set access and operating policies for the application | Decide what evidence permits an image to reach production |
Docker EE 2.0 combined controls for running applications with controls for distributing their images.
This made the software artifact itself part of the operating model. A geographically dispersed team needed to know which image it was using and whether a local copy matched the approved one. Caching and mirroring could help distribute artifacts; neither established that the software was free of defects. Scanning results and signatures supplied different kinds of evidence and required policies about how to act on them.
A supported platform still left a systems problem
Bundled networking and registry administration reduced the number of components a team had to assemble independently. They did not remove the need to understand persistent data, application dependencies and failure recovery. Moving a container between schedulers can leave its database, external services and contractual availability commitments exactly where they were.
For a startup adopting the platform, the migration scope should address an actual operating problem. A stateless internal service and a system that serves customers and retains their data need different evidence before moving. Teams could evaluate the supported configuration against those needs before deciding whether to replace working infrastructure.
The surrounding market became more demanding
The release created a sharper question for companies selling infrastructure tools. If the enterprise platform already included basic administration, image governance and networking, a standalone supplier needed to show where its additional product mattered. Support for demanding storage requirements, deeper security analysis or visibility across several environments could provide a more specific buying case than general enthusiasm for containers.
The economic test was whether that additional capability reduced work or risk enough to justify another supplier. A credible demonstration would involve a customer's workload and operating team, with the cost of integration included. Docker EE 2.0 made Kubernetes easier to consider within an enterprise purchasing decision. It also made clear that the durable business was supporting applications through their operating life, with the orchestrator as one component of that responsibility.
Investment implications
- Enterprise adoption depends on the systems and responsibilities surrounding an orchestrator.
- A shared platform can support a gradual migration, but each application's dependencies still need examination.
- Infrastructure startups face pressure to explain the value they add beyond features bundled into the platform.
Sources
- Docker Advances Container Management and Security for Applications on Kubernetes with Docker Enterprise Edition 2.0 (opens in a new tab)
Docker, preserved by Internet Archive
- Running Docker on Docker Enterprise Edition 2.0 (opens in a new tab)
Docker, preserved by Internet Archive
- Announcing Docker Enterprise Edition 2.0 (opens in a new tab)
Docker, preserved by Internet Archive
Published
