The use of containers by developers — and now increasingly IT operators — has grown from infatuation to deep and abiding love. But as with any long-term affair, the honeymoon soon leads to needing to live well together … and maybe even getting some relationship help along the way.
And so it goes with container orchestration and automation solutions, which are rapidly emerging as the means to maintain the bliss between rapid container adoption and broad container use among multiple cloud hosts.
This BriefingsDirect cloud services maturity discussion focuses on new ways to gain container orchestration, to better use serverless computing models, and employ inclusive management to keep the container love alive.
Here to help unpack insights into the new era of using containers to gain ease with multi-cloud deployments are our panelists: Matt Baldwin, Founder and CEO at StackPointCloud, based in Seattle; Nic Jackson, Developer Advocate at HashiCorp, based in San Francisco, and Reynold Harbin, Director of Product Marketing at DigitalOcean, based in New York. The discussion is moderated by Dana Gardner, principal analyst at Interarbor Solutions.
Here are some excerpts:
Gardner: Nic, HashiCorp has gone a long way to enable multi-cloud provisioning. What are some of the trends now driving the need for multi-cloud? And how does container management and orchestration fit into the goal of obtaining functional multi-cloud use, or even interoperability?
Jackson: What we see mainly from our enterprise customers is that people are looking for a number of different ways so that they don’t get locked into one particular cloud provider. They are looking for high-availability and redundancy across cloud providers. They are looking for a migration path from private cloud to a public cloud. Or they want a burstable capacity, which means that they can take that private cloud and burst it out into public cloud, if need be.
Containers — and orchestration platforms like Kubernetes, Nomad and Swarm — are providing standard interfaces to developers. So once you have the platform set up, the running of an application can be mostly cloud-agnostic.
Gardner: There’s a growing need for container management and orchestration for not only cloud-agnostic development, but potentially as a greasing of the skids, if you will, to a multi-cloud world.
Harbin: Yes. If you make the investment now to architect and package your applications with containers and intelligent orchestration, you will have much better agility to move your application across cloud providers.
This will also enable you to quickly leverage any new products on any cloud provider. For example DigitalOcean recently upgraded our High CPU Droplet plans, providing some of the best values for accessing the latest chipsets from Intel. For users with containerized applications and orchestration, they could easily improve application performance by moving workloads over to that new product.
Gardner: And, Matt, at StackPointCloud you have created a universal control plane for Kubernetes. How does that help in terms of ease of deployment choice and multi-cloud use?
Ease-of-use increases flexibility
Baldwin: We’ve basically built a management control plane for Kubernetes that gives you a single pane of glass across all your cloud providers. We deal with the top four, so Amazon, Microsoft Azure, Google and DigitalOcean. Because we provide that single pane of glass, you can build the clusters you need with those providers and you can stand up federation.
In Kubernetes, multi-cloud is done via that federation. The federation control plane connects all of those clusters together. We are also managing workloads to balance workloads across, say, some on Amazon Web Services (AWS) and some on DigitalOcean, if you like.
That’s what we have been doing with our star product. We are still on that journey, still building more things. Because it’s moving quite fast, federation is shifting and changing. We are keeping pace and trying to make it all easier to use.
Our whole point is usability. We think that all this tooling needs to become really, really easy to use. You need to be able to manage multi-cloud as if it’s a single cloud.
Gardner: Reynold, with DigitalOcean being one of the major cloud providers that Matt mentioned, why is it important for you to enable this level of multi-cloud use? Is it a matter of letting the best public cloud services values win? Why do you want to see the floodgates open for public cloud choice and interoperability?
Harbin: Thousands of businesses and over a million developers use DigitalOcean — primarily because of the ease in provisioning and of being able to spin up and manage their infrastructure. This next step of having orchestration tools and containers puts even more flexibility into the hands of developers and businesses.
For customers who want to use data centers on DigitalOcean, or data centers on other providers, we want to enable flexibility. We want developers to more easily burst into public clouds as they need, and gain all the visibility they want in a common way across the various infrastructure providers that they want to use.
Serverless pros and cons
Gardner: Developers are increasingly interested in a serverless model, where they let the clouds manage the allocation of machine resources. This also helps in cost optimization. How do the container orchestration and management tools help? How does serverless, and the demand for it, also fit in?
Jackson: Serverless adds an extra layer of complexity, because the different cloud providers have different approaches to doing serverless. A serverless function running on Google or Azure or AWS — they all have different interfaces. They have different ways of deploying, and the underlying code has to be abstracted enough so that it can run across all the different providers. You have to really think about that from a software architectural problem, from that perspective.
In my opinion, you would allow yourself to get locked in if you use things like the Native Queuing or Pub/Sub, which works really well with a particular cloud provider’s serverless platform.
One of the recent projects I’m super-excited about is OpenFaaS, by Alex Ellis. What OpenFaaS tries to do is provide that cloud-agnostic method of running functions-as-a-service (FaaS). This is not necessarily serverless, you still have to manage the underlying servers, but it does allow you to take advantage of your existing Kubernetes, Nomad, or Docker Swarm Clusters. It then gives you the developer workflow, which I think is the ultimate end-goal, rather than thinking about decoupling the complexity of the infrastructure.
Gardner: Reynold, any thoughts on serverless?
Harbin: I agree. We are on this road of making it easier for the application developer so they don’t have to worry about the underlying infrastructure. For certain applications, serverless can help in that goal, but at the same time you’re adding complexity. You have to think about the application, the architecture, and which services are going to be the most useful in terms of applying serverless.
You have to think about the application, the architecture, and which services are going to be the most useful in terms of applying serverless.
We want to enable our developers to use whatever technologies will help them the most. And for certain applications, serverless will be relevant. OpenFaaS is really interesting, because it makes it easier to write to one standard, and not have to worry about the underlying virtual servers or cloud providers.
Jackson: The other neat thing about OpenFaaS is the maintainability. When you look at application lifecycle management (ALM), which not enough people pay enough attention to, Serverless is so new that ALM is still unknown.
But with OpenFaaS — and one of the things that I love about that platform — you are baking functions into Docker containers so you can run those as standard microservices outside of the OpenFaaS platforms, if you want. So you can see that kind of maintainability. It gives you an upgrade path, despite being completely decoupled from any particular cloud provider’s platform. So you gain flexibility.
If you want to go multi-cloud, you can run OpenFaaS on a federated Nomad or federated Kubernetes cluster and you have your own private multi-cloud FaaS approach, which I think is super cool.
Gardner: It sounds as if we would like to see the same trajectory we saw with containers take place with serverless, there is just a bit of a lag there in terms of the interoperability and the extensibility.
Baldwin: There is also the serverless framework they can use that helps to abstract out the serverless endpoints. So abstract at Lambda or Kubeless or any other, Fission; Kubeless and Fission are just two other projects that are more geared toward Kubernetes than others.
Gardner: Nic, tell us about your organization, HashiCorp. What are you up to?