Hype for future of container development gets dose of reality
Realistic timelines have replaced the big promises of container disruption. Virtualization administrators should expect security and microservices features as the market matures.
After the container revolution that didn't come in 2017, virtualization administrators need to evaluate realistic container development roadmaps that have replaced the hype and made space for the technology to deliver and potentially disrupt.
Developers and testers have reset expectations and started building timelines that enable them to meet promises and build a robust app infrastructure for container development. This new infrastructure will pose an existential threat to VMs and hypervisor-based cluster platforms. Both will have to adapt to support a containerized workload if they are to remain valuable.
Security improvements are incoming
You can describe containers -- at 35,000 feet -- as VMs capable of supporting a single OS, whereas traditional virtualization offers a VM-by-VM process. This might seem restrictive, but the OS ecosystem tends to be relatively static in large pools of servers. Parsing Windows and Red Hat Linux containers in advance, for example, isn't difficult, especially because you can quickly reboot the core servers to a different OS.
By using hypervisor VMs as hosts for the containers, you can speed up that reboot. This adds security against multi-tenancy hacks as long as the CPU has specialist hardware to separate tenant memory spaces. This is the typical deployment today, which provokes discussions about licensing costs and overhead for the future of containers.
Open source developers will certainly pay attention, with both Docker and Red Hat's rkt -- an application engine acquired along with CoreOS -- possibly evolving to directly take advantage of CPU hardware security assists.
As with all things x86, the spectre of Spectre complicates operations. The need for hypervisors that underpin containers engenders a security issue that requires additional licenses and support to fix.
Running VMs or containers in a single tenant mode on any given server essentially negates Spectre. A lack of efficiency makes the sheer number of containers that can be created on any one server a barrier to single tenant operation. I predict security fixes that address both Spectre and container development are in the pipeline at Intel and will land in 2018.
Container infrastructure in a maturing market
Kubernetes is the leader in container orchestration. This is largely good for the development of containers, since this focuses adopters on coding. Docker currently dominates the container platform market, but Red Hat rkt is a strong contender.
The overall technology is still new, so VMware might surprise us and become a major player.
VMware is a latecomer to containers and Photon is struggling to gain share. The overall technology is still new, so VMware might surprise us and become a major player in the future of containers. We'll likely know by the end of 2018 if that's going to happen.
The design of containers orients them for automatic running via orchestration. This will change the emphasis of admin work and might lead to organizational downsizing even as the number of instances increases. This makes a demonstrable knowledge of containers a survival skill for admins.
Expanding container features
Leading container companies are building out the core infrastructure with tools for image manipulation and scripting. This area will expand rapidly in 2018 and offer choice, but also confusion about the likely market leaders.
Current container platforms are weak on storage interfacing. This is likely the result of an emphasis on core operations, but it's critical that container development eventually prioritize storage.
Containers foster a microservices approach to applications. Code is modular, and microservices chain together to build the complete app. The APIs involved tend to be proprietary, which results in chaotic communications. You can expect many translation gateways, but the difficulties of syncing versions and handling new APIs will persist.
This is fertile ground for startups and standards committees, but my advice is to build API interfaces as shim microservices wherever possible to make upgrades easy.
