There were a couple of interesting pieces in the trade news yesterday, and the combination of the two may be more interesting yet. One piece was from SDxCentral, commenting on the reported difficulties associated with container deployments, and the other piece from Light Reading on the addition of zero-touch provisioning to SD-WAN. Combined, these articles point to some trends that are further evidence of a major shift in networking.
Containers are the most important development in application deployment in recent times. A container deployment is a kind of packaged union of the deployable, operations-centric, vision of an application with the developed components themselves. Think of it as a plug-and-play wrapper around what would otherwise be a complex and variable set of technical stuff. That containers can make things a lot easier is a given, and it probably isn’t a surprise that container adoption across the full range of deployment environments is proving more difficult than expected.
Docker is the container baseline, and yet it deploys apps in what most users would consider a trivial environment. Swarms, the Docker extension for clustering, is a little better but most enterprises would still find it way short of the mark. Kubernetes, an orchestration tool that acts as a kind of over-Docker layer (also over other container systems, by the way) is a more enterprise-grade tool, but even Kubernetes has its issues, as SDxCentral’s article shows.
There are two separate things going on, container-wise. First is the obvious fact that in containers as in other tech things, we started at the bottom and we’re only slowly making our way up. I think it’s clear that the problems that SDxCentral points out are problems of scaling, problems that arise when the little part you start with doesn’t quite fit the glorious whole hole you end up with. Like SDN and NFV, containers have growing pains that a top-down approach could have solved.
The second thing that’s going on is also the thing that ties our two articles together. In SDN and NFV, the problem is that we have enclaves of SDN/NFV technology that don’t scale within limited “control domains”, and there’s no accepted, proven, way to connect the domains. In addition, the domain-specific automation doesn’t cover the full range of operations tasks, which means that there’s limited operations benefits.
Kubernetes does a good job of orchestrating larger resource clusters. It lacks two critical things. The first is a sense of business integration, integration that ties the applications together because that tie is essential in the way the business operates. Related applications often share components and nearly always are involved in integrated workflows. A microservice could be a piece of a hundred different apps, so you can’t treat it as a part of the container deployment of any of them. It can scale across multiple hosts, some part of the clusters used for each of those apps, or perhaps across a cluster of its own. The second is a sense of network integration. You can add SDN plugins to Kubernetes, but the whole question of unified, enterprise-wide, address management is then a kind of add-on rather than a full partner to container orchestration.
Container systems are about application resources and components, and in our current world of onrushing virtualization and microservices and functional computing, application boundaries are being lost and resources are all abstractions. We don’t have application resources or components, we just have resources and components. That second missing piece, a unified enterprise networking model, is a hard technical barrier to full realization of container benefits.
The first missing piece is a benefit risk. The operational complexity of transformed network technologies means that if we did nothing but transform with them we’d almost surely increase operations costs more than we could hope to reduce capex. That’s because both SDN and NFV leave too much on the table with respect to scope, and that’s exactly what containers in particular, but DevOps tools in general, are doing. So if zero-touch automation (ZTA) solves the SDN/NFV problem, and if it could contribute to networking unity, why couldn’t it solve those problems for container as well?
SD-WAN is a potential virtual CPE (vCPE) NFV application, one that can also obviously be deployed on a general-purpose server or perhaps even a P4 switch. As such, it could naturally connect with any NFV ZTA processes. SD-WAN is also a natural companion to SDN because SDN services could be enveloped in an SD-WAN wrapper for some or all of a network, and nobody would see that it wasn’t a legacy network service everywhere.
SD-WAN should be able to solve the container networking problem. Like most SDN implementations, SD-WAN is an overlay technology. It’s hosted or appliance-based, so you can put it in a container host, in the cloud, on bare metal, and in branch offices. It can impose a logical, unified, addressing scheme, just as easily as SDN, and perhaps more so because of higher-layer features. If you added management hooks, you could integrate SD-WAN automation with ZTA overall, and with any SDN or NFV automation that was in place or planned.
What 128 Technology has announced is a deal with Lanner and Arrow Electronics for a complete appliance solution, zero-touch provisioning, but not full lifecycle management. The announcement doesn’t include integrating with SDN or NFV ZTA, and there are no ETSI ZTA specs yet to guide that, but most SD-WAN products have elements of self-management or “autonomous operations” and the more higher-layer functionality a product has, the more it’s capable of being, in effect, intent-driven. If it can be made to report on the SLA compliance of the lower-layer transport on which it’s overlaid, it’s a good start in the ZTA direction.
Why stop there? If a container is a step toward creating deployable units, why not add networking and higher-layer behaviors and create something for containers that’s a lot more plug-and-play. My favorite container strategy, Apache’s MESOS and DC/OS, takes some steps toward facilitating that at least, and more steps could be taken by assuming that resource virtualization and application/service virtualization had to be interdependently orchestrated while retaining policy controls over each, independently.
Containers could be “packaged” too, with a combination of servers, operating systems, middleware, and networking tools. The package approach actually makes ZTA easier because it reduces the number of variables. You may recall that HPE, who had a key integration deal with Telefonica, lost the deal suddenly over a difference in approach. My contacts told me (as I’d blogged at the time) that the difference was that HPE wanted to ease into the complexities of NFV integration by creating packages.
SD-WAN is a pathway to virtualizing networks, which virtualizes the binding element between applications/services and resources. Some early SDN products (Nicira, now NSX under VMware, for example) had a broader network harmonization mission, and Nokia/Nuage supports that mission too. SDN, though, may be a harder road to take, given that all the things that users want in “application networking” are already offered in at least some SD-WAN products. Complete the migration from zero-touch provisioning to zero-touch automation and integrate the result with containers, and you get a potential solution to container scaling and integration—at any scale.