Running containers at scale

Having a container strategy is only half of the core technology Red Hat uses for cloud computing. The other half deals with the problem of running containers at scale potentially over multiple hosts. For this, Red Hat uses technology from the Kubernetes project.

Kubernetes is an open source project that Google launched based on the experience gained running its own applications at scale. When Google notified Red Hat of their intent to launch the Kubernetes project for container orchestration and management, Red Hat saw the opportunity to collaborate and drive another standard to propel container technology forward. Multiple Red Hat developers are among the leading contributors for both the Kubernetes and Docker projects. According to Stackalytics, Red Hat is the second largest company contributor behind Google iself for the Kubernetes project.

Kubernetes helps developers and administrators by  packaging, instantiating, and running containers using a declarative model. This allows users to declare the desired end state that should be maintained. With this information available, Kubernetes uses automated, self-healing mechanisms such as automatically restarting containers, rescheduling containers on different hosts, or even replicating containers for use cases such as auto-scaling to make sure the desired end state is maintained. Best of all, Kubernetes works with Docker formatted images without modification. The technologies complement each other.

Pivotal relies on Cloud Foundry to provide a container environment that can be orchestrated. However, here again, like with containers, Pivotal is going their own technical way with orchestration technology known as Diego (after declining to adopt Kubernetes). Diego is designed to work with the Warden container implementation, different from Docker formatted containers. Most notably, Warden containers do not have layers. Layers allow a runtime to cache container components to reduce downloads and share cached layers with multiple container instances.

Every container run by Diego is in a Warden container format. Diego even repackages  Docker formatted images as a Warden container. In the process of doing this, it must re-download all layers in the Docker formatted image, which is a  very inefficient process, and it must be performed every time a Docker formatted image is run on Cloud Foundry.

Ultimately running containers at scale is hard to do correctly. Diego itself is a replacement  of other major components previously used in Cloud Foundry, such as the Droplet Execution Agent (DEA), the Health Manager, and several responsibilities of the Cloud Controller.

As mentioned previously in this competitive review, only half of the four IBM BlueMix service types are based on Linux containers. Each of those offers different orchestration technology.

Cloud Foundry Buildpacks

The first container orchestration to examine is associated with Cloud Foundry buildpacks. In this case, IBM relies on Cloud Foundry to provide a container environment that can be orchestrated. However, here again, like with containers, Cloud Foundry provides it own orchestration technology known as Diego. Diego is designed to work with the Warden container implementation, which is different than Docker formatted containers. Most notably, Warden containers do not have layers. Layers allow a runtime to cache container components to reduce downloads and share cached layers with multiple container instances.

Every container run by Diego is in a Warden container format. Diego even repackages Docker formatted images as a Warden container. In the process of doing this, it must re-download all layers in the Dockerdocker formatted image, which is a very inefficient process, and it must be performed every time you run a Dockerdocker formatted image is run on Cloud Foundry.

Ultimately, running containers at scale is hard to do correctly. Diego itself is a replacement  of other major components previously used in Cloud Foundry, such as the Droplet Execution Agent (DEA), the Health Manager, and several responsibilities of the Cloud Controller.

Container service

The second form of IBM orchestration to look at is associated with its container service. In this case, IBM is offering a mix of proprietary and open source technology. The proprietary technologies to create container groups, provide scaling, and load balance HTTP traffic have been part of the IBM container service since it was released. As of April  2016, IBM BlueMix also supports use of Docker Compose, but not Docker itself. Docker Compose provides IBM customers a way of defining a topology of applications that run across multiple containers. At runtime, IBM relies on proprietary technology to orchestrate the running of the topology defined using Docker Compose at scale with acceptable levels of reliability.

Unlike the Cloud Foundry component of BlueMix, the BlueMix container service uses technologies that natively interact with Docker formatted images. However, IBM is using proprietary technology to provide orchestration and does not benefit from the technical advances in this area being made in the open source community such as with the Kubernetes project.

As mentioned earlier, Oracle does not use containers as part of its Java EE application platform private cloud strategy. Instead, Oracle uses virtual machines, Oracle Traffic Director, potentially Oracle WebLogic Server Multitenant, and other unspecified technologies that are part of the Oracle Compute Cloud Service to run its public cloud offering at scale.

In relation to the core cloud technology Red Hat uses, Oracle does support use of WebLogic Server within Docker containers. This allows WebLogic users to craft their own private cloud based on Docker with a choice of orchestrating technology such as Kubernetes. However, such an effort would likely result in a custom cloud that does not match the technologies Oracle publicly discloses it used for its private and public cloud offerings. Specifically, there is no indication that Oracle uses Docker technology or Kubernetes for any of its cloud offers.

For using Docker with WebLogic, Oracle provides multiple examples via blogs and on Github. One of the more complete examples presents how to run a WebLogic cluster in a Docker Swarm cluster networked with the Docker Overlay network.

The example is quite detailed presenting all the manual steps required to build up a clustered WebLogic environment. While this can be useful to customers interested in using Docker technology with WebLogic server, it is important to note several points of potential concern:

  1. Oracle explicitly supports use of Docker images but not the associated Docker technology used in its example.
  2. Usage of Docker and associated technology is not part of the official Oracle WebLogic Server documentation.
  3. Oracle private cloud does not use Docker containers or any of the other Docker technology used in the example.

Finally, the many manual steps in the quoted Oracle example highlight just some of the complexity users can encounter when using raw low level cloud technologies, complexities that can be hidden when using a higher level cloud platform as a service. For example, developers using JBoss EAP running on OpenShift benefit from using Docker formated images, Kubernetes, and other cloud technologies without having to learn the low level details of how these technologies work individually or collectively. The time it takes for a developer to learn how to use OpenShift is far less than trying to learn the individual technologies used by the cloud platform. This leaves more times for developers to do what they do best: create applications.

Comments are closed.