How to orchestrate containers in OpenStack

Containers are a hot topic in computing right now. They are an effective and efficient method for deploying applications. However, things can get a little complicated when complex applications are split between multiple containers. When that happens, containers need to be able to work together effectively, which is where container orchestration comes in. Orchestrators facilitate the management of containers and make sure they they can connect and collaborate in the manner they need to in order to properly function.

There are many different tools for container orchestration in a cloud environment, so how does an administrator pick the solution that is best for them? Nati Shalom, founder and CTO of Gigaspaces, and a couple of his colleagues will help administrators answer that question with their talk at OpenStack Summit Vancouver. Their talk will explore the differences between several different container orchestration tools: Kubernetes, Heat, Fleet, MaestroNG, and TOSCA, and provide best practices for picking the ideal solution for different use cases.

We caught up with Nati to learn more about the talk he will be giving at the OpenStack Summit Vancouver and his thoughts on what the future holds for containers, orchestration, and OpenStack.

Without giving too much away, what can attendees of your talk at OpenStack Summit expect to take away?

The talk is going to focus on the popular approaches for orchestration, outline the general differences and potential synergies—and then dive into some best practices on how to choose the right tool for the right job. Since we ultimately have a time limit, we will likely not be able to show a live example of each tool or compare the overall user experience, but will primarily focus on the differences between the various approaches for orchestration that often lead to semantical differences.

To answer this question—the cloud admin would need to ask themselves some key qualifying questions to begin with. And each of these would bring with it the best possible tool/solution for the job. I'd split these questions based on your environment to begin with, and then ask which tools you're using to manage these environments, and finally what level of orchestration you're looking for—one off for a project, or something more long-term or global, and application stack considerations.

So first and foremost, you'd need to consider whether your environment will be OpenStack only, container only, or a hybrid model such as legacy infrastructure (i.e. vSphere or physical hardware).

If you're in an OpenStack only environment your first choice would be Heat plus the integration of other complementary stacks for handling software configuration, monitoring, workflows, policies, etc. Some of these may come as projects from OpenStack, and in some cases it would be best to pick a related open source project. If you're planning to move to a container only environment, your first choice would probably be Docker. As it stands today, you would need to integrate a large set of complementary stacks for handling logging, monitoring, workflows—Kubernetes, for example, provides a more advanced orchestration specifically geared toward microservices. If your world is more a mix of containers, and configuration management tools—Puppet, Chef, SaltStack—as well as mix of private cloud (OpenStack, VMware) or public cloud (Amazon, Google) then your best choice would be TOSCA-based orchestration—that is also infrastructure and tool chain agnostic. Obviously, it goes without saying that if you're already heavily invested in Chef or Puppet then your best choice would be an orchestration tool that comes with built-in support for such frameworks.

Next, the question is whether you are looking for orchestration for a specific product/project, or as a general purpose solution for many apps, and this is where it becomes more tricky.

Many products come with their own orchestration that is tailored for a specific use case of that application—a good example is Cloud Foundry/Bosh or Hadoop/Yarn. Other orchestration tools come with a general purpose solution, and built-in templates for specific applications, and these each have certain sweet spots. For example there are orchestration tools that are more tuned for network apps such as NFV, or those that are tuned for Big Data, so in this category even if I would go for a general purpose orchestration tool, I would look for those that best fit my target workloads.

Another important criterion is embeddability, having an orchestration tool as part of another product is fairly different than choosing an orchestration tool for running your data center operations. In such a case, I would look for a lightweight solution that can be used with minimum runtime overhead, potentially as a library only. You'd also need to decide whether you are looking for a full lifecycle orchestration that also includes post-deployment aspects (monitoring, self-healing, and auto-scaling), or mostly installation or configuration.

Some of the orchestration tools limit themselves to dealing mostly with the installation stage, however some orchestration tools provide a broader aspect of the post-deployment management tasks that cover the full lifecycle of the application—including monitoring, update policies, scaling and self-healing.

Finally, it would be important to understand what your stack looks like in terms of networking, DevOps tool chains, monitoring, and languages. Many DevOps environments consist of a series of open source projects for handling the logging, monitoring, and other aspects of the lifecycle. This set of tools tends to vary fairly quickly. Some orchestration tools comes with built-in integration for such tools, but are ultimately fairly limited when it comes to adding new tools to the mix. This is specifically true in cases where the tools happen to be a cluster of their own, and therefore require a more advanced relationship between the application orchestration and the tool-specific orchestration. In this case, we end up with orchestration of orchestration—a good example is application orchestration and network orchestration, or application orchestration and big data orchestration where the application orchestration would need to interact and delegate responsibility to the tool orchestration.

Do you see a convergence between formats coming? Or will one or two win out above the rest of the cloud?

From what I've seen, I would venture to say that there will likely wind up being three main camps:

• Docker only (or mostly)—Tools that will written in Go and will be an extension of the current Docker project. The most dominant frameworks would probably come from Docker itself (Swarm, Compose, or Machine).
• Infrastructure-specific—These tools will provide mostly the core functionality that maps to a specific infrastructure, this group is targeted mostly for those that are interested in deploying apps only on a specific environment. Amazon Cloud Formation or OpenStack Heat are good examples in this category.
• Hybrid—Orchestration for environments that are hybrid in nature, and include other technology stacks other than Docker, such as Chef, Puppet, or Ansible, or clouds such as VMware, OpenStack, AWS etc. I think that it makes sense that TOSCA will become the main orchestration specification choice for this group given its built-in neutrality.

Looking at the broader OpenStack Summit, what are you most excited about in Vancouver? What big themes do you think we'll see emerge?

NFV (Network Functions Virtualization) and customer use cases where we learn how customers are actually using OpenStack are exciting. I also hope to hear more on the OpenStack roadmap—gain insights on the things that are scheduled to shape the next release and be part of those discussions. Finally, networking: The summit is always a unique place to meet both developers and decision makers, and just discover all the exciting ways people are involved and contributing to this project.

What is going to be important for OpenStack as a project to focus on for the next release? What might the Liberty release bring, particularly in regards to orchestration?

My personal belief is that OpenStack will be much more successful if it will find a way in which more cloud providers will be able to add support for OpenStack, including those considered rivals to OpenStack such as AWS, Google, and Azure. Similarly, it will be more successful if it will find a way to encourage native support for OpenStack by other popular open source projects.

I think that so far there has been lots of focus on making OpenStack an alternative to Amazon. That strategy has led to spreading the OpenStack project too thin into many projects, in my opinion. I think that the VMware support for OpenStack is a good example for how a potentially rival infrastructure can become compatible with OpenStack. If we would make it easier for other infrastructure providers to add OpenStack compatibility to the OpenStack API we will gain much more than if we only focus on making OpenStack a viable competing alternative. Basically, I'd say inclusivity is of the essence, and not exclusivity: The open source way.

In the context of orchestration, I think that it would be best if Heat could become the integration point for other orchestration frameworks to OpenStack, such as the ones mentioned in my talk. In that context, adding support for TOSCA to Heat sounds like a step in the right direction via the Heat translator project.

The exciting features that OpenStack Kilo and Liberty brings in my opinion are things that add unique performance capabilities that best suit private cloud environments or NFV. This includes support for bare metal (Ironic) and also the upcoming shared file system (Manila), alongside advanced scheduling rules that will allow better control of resource utilization. I personally believe that Ironic in conjunction with containers will bring an order of magnitude of better performance and utilization, and would therefore, make ROI argument behind the choice of OpenStack significantly stronger.

Having said that, I think that the main news in the Kilo announcement is that there isn't so much news! Clearly this is a strong indication that the OpenStack project is finally heading toward stability and completeness of its existing core services rather than continually expanding into new territories.

Is there anything else you'd like to add?

As the topic of this talk can be fairly broad I would welcome any comments or suggestions for those interested in seeing us cover specific areas of interest. I would also appreciate pointers from those who have already gained experience with any of these tools you can find me on Twitter I'm happy to target my talk for what the audience wants to see.

In addition, this is a good opportunity to mention that there are other OpenStack events around the world with great talks for all those who aren't able to get to Vancouver, and I would encourage everyone who isn't able to attend to check them out here just as an example, there is an excellent EMEA tour of OpenStack Days almost immediately following the summit. I'm specifically involved in the organization of OpenStack Israel, which is one of these, where we're going to have a great line of speakers from all over the world—the main one being Axel Clauberg from Deutsche Telekom, who in my opinion is leading one of the most ambitious OpenStack projects to date.

This article is part of the Speaker Interview Series for OpenStack Summit Vancouver, a five-day conference for developers, users, and administrators of OpenStack Cloud Software.