Today, we are very excited to announce the general availability of Oracle Container Cloud Service (Container CS). It’s been an exciting journey to take the StackEngine container management software that Oracle acquired and transform it into a cloud service – Container CS.

I was part of the original StackEngine team and am personally excited that our core design principle, ease of use, prevails as the major differentiator for Container CS versus our competition. For me, the ease of use translates into a few key differentiated features for Container CS.

First, Container CS can be easily provisioned with whatever IaaS compute capacity that you need to power the worker nodes that run your Docker container applications. After provisioning you have a ready-to-use platform – just you bring your own containers and run them with ease. Additionally, I believe that customers will want to have multiple Container CS instances at their disposal to use as they need. Deploy a set of instances for various dev and devops teams and deploy others for individuals. This gives our customers the ability to get Docker workloads off of their laptops and into container environments, easily.

Second, Container CS comes with many examples of container applications that can be deployed in a click. These examples can be simple, with just one image and its runtime information in a ready-to-run template called a Service. Or they can be multiple image applications, with defined orchestration that can deployed across multiple hosts. These are called Stacks. The beauty of these Services and Stacks, is that our customers can utilize these examples and the way that they are built, to help model their own applications.

The third is the Container CS UI. The UI, through many of its native features, including TCP checks, and easy to understand color-coded health checks, gives context to the status and state of running containers. But, I think the most context is given through the function of Deployments. A Deployment is created when you run a containerized application and allows you can see the individual containers in the context of what they are actually doing along with the overall health of the deployment.

Contrast the information that is delivered in the terminal window, with a standard “$docker PS” command. In the screenshot below, the information that the user can quickly ascertain is limited. Pretty much a list of containers, their native Docker names and the uptime. Does the terminal window observer really have a good idea of what the containers are actually doing?