While Docker has made containers easy for developers to use, there is still a way to go before containers are easy...
to deploy in most enterprises. Just as with other application development frameworks, the needs of developers are different to the needs of enterprise operations teams.
For enterprise deployment of containers, network connectivity and security must be manageable. To keep with the programmability of containers it is crucial that the network parts are also programmable. VMware has a programmable network offering called NSX; it is likely to be VMware's tool to manage container networking.
A container is simply an executable program that runs on an isolated file system on an operating system. Most often, the operating system is Linux, either in a VM or on dedicated physical hardware. That computer can run multiple containers that each have isolated file systems; all containers share the resources of the underlying computer, such as its CPU and RAM as well as disk and network.
Containers allow for cloud-scale apps
Docker has seen adoption in cloud services, where a single application may have hundreds of thousands of connections. For a lot of these early implementations of containers, there is no need for a lot of isolation between containers. Often all the containers on a single computer are parts of the same application. A single application might be made up of several different small programs, called microservices. It might have dozens of microservices and might need dozens or even thousands of instances of each microservice. The result is that many containers might be required to run one application.
In cloud-scale applications this might lead to hundreds of servers running thousands of container instances to deliver one application. At this scale it makes sense to dedicate a set of computers to one application and have separate servers for each application. Often network security is only implemented at the boundary of each application.
Sharing poses a problem
At a smaller scale, it may be necessary to have multiple applications share a set of servers. The applications will still need the same number of microservices. But since there will likely only be hundreds of users, the number of instances will be much smaller. If each application only needs a few dozen container instances, then dedicating hardware to the application will limit flexibility. Enterprise customers are likely to have the containers of multiple applications mingled together.
Now there is a need to provide isolation between containers that may share a host since they may be parts of different applications. The customer-facing ordering website needs to be isolated from the enterprise resource planning and payroll applications. This will require a firewall that can tell the difference between the containers running on one host. We have already seen NSX allowing different firewall policies for different applications on one VM. NSX should be able to identify applications running in containers and apply different policies for each application.
Programmability of security is key
One of the great values of containers is their volatility. New container instances can be created and destroyed by the application. When the website is getting busy, the application can create more Web server containers. When the website is quiet, those containers can be destroyed. All of this scaling should be handled automatically by the application. This volatility is a challenge to any manual processes, particularly security processes. To accommodate the programmatic creation and destruction of containers, the security tool needs to be programmable. When the application adds a container for the Web server, the security tool should add the rules that allow access to that container. This is where software-defined networking is critical to new applications. It should be a relatively simple matter for application scaling to directly contact NSX and direct the creation of firewall policies for containers as they are deployed.
VMware has shown a commitment to providing infrastructure for architectures based on microservices by developing projects Lightwave and Photon. Lightwave provides authentication for containers, allowing control of what containers are allowed to run in an environment. Integration with NSX will allow a set of security rules to be applied to a set of containers that make up an application. VMware seems to expect that container isolation will be provided by running a single container in each VM. This uses the VMFork technology -- at one time, known as Project Fargo -- which enables VMs to be created as fast as a container. VMFork addresses the file system security that containers need but does not address the network provisioning and security. VMware still needs NSX to deliver policy-based connectivity and security.
VMware is committed to enabling container-based applications in enterprises. I expect NSX to form a pillar of their programmable infrastructure for containers in virtualized infrastructure.
The answers to your VMware NSX platform questions
What you should know before investing in VMware NSX
How VMware NSX will alter the network admin role