Nati Shalom's Blog

Making Hybrid Cloud Simple and Real with vCloud Air, TOSCA and Cloudify

 

 

While hybrid cloud has been a mainstay discussion in the cloud world for quite some time now (note this post of mine on hybrid cloud from 2011, when CloudStack was still Cloud.com), the reality is that setting up hybrid cloud has proven a fairly complex process. Therefore we've seen only a few real implementations of true hybrid cloud in the wild.

In this post, I  wanted to describe the joint work that we've invested together with the VMware cloud team to change this reality and finally make the hybrid cloud story simple and possible.

vCloud Air makes hybrid cloud truly simple and real

While most public clouds started as independent public cloud services, and only later started to add private cloud connectivity; the exact opposite is true for vCloud Air, which was designed primarily as an native extension of VMware private cloud. In this context, users are able to use the same tools currently in use to manage their local VMware environment in order to manage their public cloud resources, as well. This makes the hybrid cloud story significantly simpler, as there is no longer the need to worry about the connectivity between the two sides of the data center, and at the same time we get the cost benefit of using resources on-demand on a pay per use basis.

The ability to make hybrid cloud so simple fit well with the Cloudify pure-play orchestration vision, and made the integration with the two platforms a perfect fit.

In this post I wanted to spend some time on what that means for VMware and OpenStack users.

Putting vCloud Air, TOSCA and Cloudify  together

 

vCloud Air users needed a simple way to deploy and manage their applications on vCloud Air using DevOps tools similar to Amazon Cloud Formation.

As the landscape is still being shaped, and there’s no clear winner yet, it is very important for these users to have tools that will allow them to keep their options open.

TOSCA seemed to be a great fit in such a context, as it provides a standard templating language that doesn’t tie users into a particular platform.

On top of this, TOSCA orchestration also aims to go beyond the installation part of the application and covers all the aspects of the application lifecycle through the addition of workflows and policies that can be used to handle continuous deployment, self-healing, and auto-scaling processes.

On a similar note, many Cloudify users comes from Enterprise and Telco markets. Such users are already heavily invested in VMware. These customers are actively looking for a more agile and cost effective way to run their data center.  The ability to bring capacity on demand seamlessly into private cloud makes the entire private/hybrid cloud story truly attainable.

By putting vCloud Air, TOSCA and Cloudify together we’re getting the cost benefit of using on demand resources for our private data center in a way that doesn’t tie us to a specific platform and at the same time provide a more complete application lifecycle and management solution that enables full automation of our deployment and DevOps processes.

Extending the solution to the rest of the VMware stack

VMware provides three kinds of platforms today, the vCenter/vSphere environment that serves many of the enterprises data centers today, and VMWare Integrated OpenStack, which provides API compatibility with OpenStack for vSphere/vCenter environments.

Cloudify comes with native TOSCA support through plugins that allows you to use TOSCA blueprints as a templating language across both vCloud Air, vSphere and OpenStack that provides a consistent way to manage applications across all three environments.  On top of this, it also makes it simple to build mixed resources of all three environments all with the same blueprint.

Having pure-play orchestration and management that is backed by an industry standard, TOSCA, enables the decoupling of the way to manage applications from the underlying infrastructure. While there is still the need to rely on specific APIs and features of the specific infrastructure, they are now at a point where the cost of the switch isn’t as significant compared with the alternative of binding themselves directly into the specific underlying infrastructure.

The benefit for OpenStack users

Many OpenStack users are Enterprises and Telco customers who are known to be heavy users of VMware platforms. This integration makes the ability to mix and match existing VMware environments together with OpenStack and vCloud Air, providing greater flexibility to decide which applications and workloads fit best in which environment while using common and consistent management for their applications across environments.

What should we expect next?

Through our partnership with VMware we’re planning to make this integration simpler for vCloud Air users by allowing them to use TOSCA directly through the vCloud Air public cloud service. In addition, the plan is to make the hybrid cloud story between vCloud Air, vSphere and OpenStack as seamless and simple as possible so we will be adding more examples and tighter integration for all three platforms.

How should I get started?

• TOSCA Orchestration for VMware - Hybrid Cloud Made Simple
• vSphere Plugin Docs
• VMware Hybrid Cloud with Cloudify

Do I Need PaaS if I Use Docker?

In my recent post on OpenStack  “Do I Need OpenStack if I Use Docker?” I covered the confusion that has emerged around one area of disruption that Docker has created. In this post, I’d like to segue into another similar topic that has emerged around the same concept where I sense similar disruption and confusion: the use of PaaS in its traditional form vs using a straight Docker approach.

Background

PaaS in its simplest form is a platform that enables developers to develop and deploy web applications into production fast by abstracting many details of the underlying infrastructure, whereas Docker provides a generic container for packaging software stacks in a portable way.

A Traditional PaaS Stack

Many of the traditional PaaS implementations use Docker or LXC as the underlying container to enable multi-tenant applications on a shared infrastructure. Usually PaaS relies on web containers that are specific to a certain language (Tomcat, Jetty/Java, modephp/PHP, Rails/Ruby, Django/Python,NodeJS/JavaScript…..) to host the user’s code, and Docker or LXC containers as lightweight VMs that hold these web containers, and provides the required isolation level between the various web containers. This architecture lends itself nicely into simple web applications which are often built out of a web front-end, and a database as a backend persistent model. As far as I know, Docker actually initially emerged from one of the PaaS’ provided by DotCloud, and evolved into its current incarnation.

The introduction of Docker as a simple abstraction to containers, has turned Docker into a portable software container that isn’t tied to a specific language or framework. It can not only be used as a web container, but also as a more general purpose software container for all sorts of applications such as microservices, big data analytics, stream processing, as well as legacy applications.

Some PaaS implementations, such as CloudFoundry, have already started to offer support for running Docker containers as one of the software components that are supported by the platform.

Having said that, PaaS provides a fairly opinionated model for the way we should model and package our applications. Often times, our packaging is too limiting as we start to grow to more scalable models, such as microservices.

This causes many users today to question whether there is enough added value in PaaS in order to justify these limitations, when users can simply run their software directly on Docker.

Using Docker as an Alternative to PaaS

Using Docker with a combination of orchestrations engines such as Kubernetes (in the case of GCE), Heat in the case of OpenStack, or Cloudify (for multiple clouds such as OpenStack, VMware, AWS, as well as bare metal)

can provide a relatively simple way to package, deploy and manage applications in an automated fashion.

Unlike the traditional PaaS stack - it doesn’t force a specific opinionated architecture for deploying apps although it does lend itself very nicely into both web applications and microservices architecture.

My Take

The main promise of PaaS is in the speed of development and simplicity. Traditional PaaS implementations achieve that goal through extreme abstraction of the underlying infrastructure, as well as by promoting an opinionated architecture, which provides a fairly optimized and consistent deployment experience for applications that fit into that model. The combination of the two ultimately does help achieve this promise, but for a fairly limited set of applications.

Using Docker coupled with orchestration as an alternative provides a more general purpose platform for achieving a similar goal. Unlike the traditional PaaS approach, this use of Docker with an orchestration engine does expose the user to more knobs and infrastructure details, which makes the user experience for developing and deploying simple web apps more complex than with the PaaS alternative, however it does provide the added benefit of flexibility - like with the onset of OpenStack, and open source cloud in general..

The right way to think of PaaS and Docker

In my opinion, the right way to think of the two is in a layered approach in which both the PaaS containers and Docker fit together as outlined in the diagram below.

As seen in the diagram above,  PaaS becomes one use case for deploying simple web apps. For more complex application deployments, it makes more sense to use Docker directly. In this context orchestration becomes a central piece for managing both use cases. Orchestration also provides a layer of abstraction between the application components and the underlying infrastructure.

The important realization is that in this context the role of PaaS as we know it becomes more of a niche role, yet still remains a fairly common and important use case. It is also important to note that the two models are not mutually exclusive. An application that runs on a PaaS container could interact with services that are managed directly through a Docker container, just as you would use other cloud services such as database as a service, load balancer as a service or any other on-demand resource.

Another important note is that the combination of Docker and orchestration opens a new path to manage dynamic workloads not just on an IaaS environment, but also directly on bare metal. I’m starting to see more use cases where this option becomes more popular, specifically for managing dev and testing environments where the use of a full blown cloud infrastructure may just  be overkill.

Final Note

When we started the journey into the cloud world a few years ago, the underlying cloud infrastructure was very complicated. As a result, the only way possible to simplify the application deployment experience was to take extreme measures in the level of abstraction, as well as by forcing an opinionated architecture to ensure that the application fits into typical cloud architecture. As the underlying infrastructure and tooling evolves,  those extreme measures are no longer needed for all use cases. What we’re now seeing is basically a shift of of pieces in the PaaS architecture that was previously embedded within the "PaaS Box" such as containers and orchestration that have becomes more generic, along with independent services that have their own right to exist.

The good news in all this, is that as users we are finally beginning to receive the simplicity of PaaS, that was previously limited only to greenfield web applications, for use with a  much broader spectrum of applications and architecture styles.

So to answer the question from the opening note, do i need PaaS if i use Docker? The answer is, yes. It makes sense to have the two combined, but the role of PaaS as we know it has narrowed down significantly.

Do I need OpenStack if I use Docker?

 

Docker has broken a record in the speed in which it moved from being a disruptive technology to a commodity. The speed of adoption and popularity of Docker brings with it lots of confusion.

In this post I wanted to focus on a trend of commentary that has been gaining popularity, that I’ve started to hear more often recently from users who just started using Docker.  Whether it makes sense to use OpenStack if they’ve already chosen to use Docker.

Before I give my take on this, I wanted to start with a short background for the rationale behind this question.

Background

In its simplest form, Docker provides a container for managing software workloads on shared infrastructure, all while keeping them isolated from one another. Virtual machines such as KVM do a similar job by creating a complete operating system stack of all the OS devices (through a Hypervisor). However, unlike the virtual machine approach, Docker relies on a built-in feature of the Linux operating system named LXC (Linux Containers). LXC utilizes the built-in operating system features of process isolation for memory, and to a lesser degree, CPU and networking resources. Docker images do not require a complete boot of a new operating system, and as a result, provide a much lighter alternative for packaging and running applications on shared compute resources. In addition, it allows direct access to the device drivers which makes I/O operations faster than with a hypervisor approach. The latter makes it possible to use Docker directly on bare metal which, often times causes people to ask whether the use of a cloud such as OpenStack is really necessary if they’re already using Docker.

This performance difference between Docker and a hypervisor such as KVM is backed by a recent benchmark done by Boden Russell and presented during the recent DockerCon event.

The benchmark is fairly detailed, and as expected, it shows a significant difference between the time it takes to boot a KVM hypervisor to a Docker container. It also indicates a fairly big difference in the memory and CPU utilization between the two, as can be seen in the diagram below.

This difference in performance can map to a difference in density and overall utilization difference between the two in similar proportion. This difference can easily map into a big difference in cost that is directly affected by the number of resources needed to run a given workload.

My Take:

• This question has nothing specific to do with OpenStack and can be applied similarly to any other cloud infrastructure. The reason it is often brought up in the context of OpenStack, in my opinion, is due to the fact that OpenStack is fairly popular in private cloud environments which is the only environment in which we can even consider a pure Docker alternative.

• It's about the hypervisor stupid:

Many of the performance benchmarks compare Docker versus KVM, and have little to do with OpenStack. In fact, this specific benchmark of both KVM images and Docker containers was running through OpenStack which shows that the two technologies works nicely together. In that context, most of the utilization  arguments become irrelevant when I choose to run OpenStack on top of a Docker based Nova stack as illustrated in the diagram below taken from the OpenStack documentation.

• Cloud infrastructure provides a complete data center management solution in which containers or hypervisors, for that matter, are only part of a much bigger system.  Cloud infrastructure such as OpenStack includes multi-tenant security and isolation, management and monitoring, storage and networking and more. All of those services are needed for any cloud / data center management and have little dependency on whether Docker or KVM are being used.

• Docker isn't (yet) a full-featured VM and has some serious limitations like security, Windows support (as indicated in the following email thread in the Red Hat mailing list), and therefore cannot be considered a complete alternative to KVM just yet. While there’s ongoing work to bridge those gaps, it is safe to assume that adding the missing functionality may come at an additional  performance cost.

• There’s a big difference between raw hypervisor performance/containerization and application performance, as indicated in the following graphs from the benchmark results. A possible explanation for that is that applications often use the caching technique to reduce the I/O overhead.

• If we package Docker containers within a KVM image the difference can become negligible. This architecture often uses hypervisors for managing the cloud compute resources, and an orchestration layer such as Heat, Cloudify, or Kubernetes on top to manage containers within the hypervisor resources.

Conclusion

This brings me to the conclusion that the right way to look at OpenStack, KVM and Docker, is as a complementary stack in which OpenStack plays the role of the overall data center management. KVM as the multi-tenant compute resource management, and Docker containers as the application deployment package. 

In this context a common model would be to use Docker for the following roles:

• Docker provides deterministic software packaging and fits nicely with the immutable infrastructure model.

• Docker for excellent great containerization of microservices pods

• Using Docker on top of OpenStack as well as a bare metal environment

Having said all of the above, I do see cases mostly for well defined workloads, where the use of cloud infrastructure isn't mandatory. For example, if I were to consider the automation of a small shop development and testing environment for DevOps purposes, I would consider using Docker directly on a bare metal environment.

Orchestration can be a great abstraction tool between the two environments

One of the benefits of using an orchestration framework with Docker, is that it can allow us to switch between OpenStack or bare metal environments at any given point in time. In this way, we can choose either options just by pointing our orchestration engine to the target environment of choice. OpenStack Orchestration (Heat) declared support for orchestrating Docker starting from the Icehouse release. Cloudify is an open source TOSCA based orchestration that works on OpenStack and other clouds such VMware, AWS and bare metal, and recently included Docker orchestration .  Google Kubernetes is associated mostly with GCE but could be customized to work with other cloud or environments.

References:

• Using Docker as and OpenStack compute resource (Nova)

• Orchestrating Docker containers through OpenStack Heat

• Orchestrating Docker containers on OpenStack, VMware, AWS, bare metal and Other clouds through TOSCA/Cloudify

• Docker limitations as indicated in Red Hat mailing list

• The boring truth: full virtualization and containerization both have their place

• Using Docker as immutable infrastructure

• Docker drops LXC as default execution environment