A lot has been written about containers, especially Docker and the Open Container Project. People think that this is a very fast-paced technology, but it has been around since the inception of Linux. In the early days, we called these cgroups and then userspace. The fundamental concept was to partition the processes running on an operating system in their environment.
Docker has taken this concept further. Last month, the industry launched the Open Container Project within the Linux Foundation. Its sponsors are Apcera, AWS, Cisco, CoreOS, Docker, EMC, Fujitsu, Google, Goldman Sachs, HP, Huawei, IBM, Intel, Joyent, Pivotal, the Linux Foundation, Mesosphere, Microsoft, Rancher, Red Hat, and VMWare. The key to this project is not to splinter the concept into multiple implementations. In this blog, I will discuss the implications of containers and discuss its future.
It would be best to call containers "beyond virtualization," and the two major operating systems, Linux and Microsoft Windows, have taken a position on creating containers. In its simplest form, a container allows a developer to put in a box all the components and associated packages to enable an application to run in an isolated environment abstracted away from the base underlying operating system. There should be no confusion that to make a container work, there must be an operating system involved in the package. It solves a major problem that application developers have been dealing with, which is application dependencies being isolated from the environments they run on. In deploying applications, the developer does not have to worry about the issues related to the environment that the applications are running in. As stated before, this is an issue that has plagued developers since the inception of developing and implementing applications.
Google employs more than 2 billion containers across its data centers every week, according to Miles Ward from Google. If the company are to be concerned about dependencies, this would be an impossible task. Google came up with projects like Borg and its successor, Omega. Containers help companies like Google deal with migration, continuous deployment, portability, and scalability in a hyperspace.
No wonder the container project has 650 contributors already improving containers. The excitement has come from the portability and the deployment methodology. For example, the container can be installed on a Red Hat Linux or even a Debian Linux and the developer does not worry about the dependencies are resolved within the isolated container. This why it goes "beyond virtualization." In a virtual machine environment you have to continue to worry about the dependencies when you deploy an application. Novel problems arise, such as container lifecycle management, the ability to roll back applications within a container and especially security.
The containers virtualize the OS so that all components and dependencies are within the container. It enables much lighter-weight operating system inside the container. Red Hat have introduced the atomic platform; VMware has announced Bonneville, which is its version of containers; Google has Google Containers; and Microsoft has announced its version of containers within Windows the Nano Server. Since each container is self-contained, they can all speak to each other.
The container is a lightweight and portable box that has all the components of the application. The concept is why you can move containers from multiple environments whether it is a private, public, or hybrid environment. In later blogs, we will discuss composition will applications where services are in either virtual machines or containers. The fact of the matter that containers are so lightweight the ability to put multiple containers in an environment will create a whole new concept of hyper-scale.
This significantly reduces the cost of licensing for shared resources. The main point is that containers change the entire lifecycle of application development. They also bring a completely new model that finally bring us to a service-oriented application deployed without regard to the underlying hardware. You will see applications being composed of multiple services from multiple platforms on disparate hardware. The network containers and most of all storage containers are connected through federation in a single application. This frees the application gets submitted in any of the languages in the current platform-as-a-service environment; this enables there to be an ISV community to grow up as a container provider.
So with this new environment, it's no surprise that these companies created the Open Container Project because forking or splintering this concept will diminish the value significantly. It also enables Windows and Linux to be relevant to the implementation of the application concurrently and transparently. This group is working on workflow components based upon some of the work did at Google known as Kubernetes and also changes the entire paradigm of management that we've used over the last 30 years.
A developer starts with an environment-based operating system and starts to define the packages that are needed to enable their application. Here's where the magic and irrational exuberance comes from once a container is created it can be moved to a live image and other users get to compose an application. Lifecycle management becomes extremely facile because the components or containers get managed in the customer's lifecycle. So the OCP project will make repositories and directories of containers used with services such as Google maps, search engines. It becomes a powerful yet subtle way of incorporating services into an application. Public repositories defined around containers. When a developer is developing he can, decide on whether or not to use one of the public services that are hosting containers.
A whole new concept of production and operating environments will come with this environment. The concept of publishing containers is one of the key foundations of the open container project. It also prevents multiple formats to use in containers and prevents splintering a proprietary APIs. We will be watching the work closely of the OCP. Theses concepts have begun to ship by some of these vendors in their products.
In calling this the application-centric cloud, we can note that we are in the early stages of seeing any seismic change in application development which are containers.
This article is published as part of the IDG Contributor Network. Want to Join?