Podcast: Orchestration & Automation Between Public & Private Cloud


In the fourth episode of our Get IT: Finding Success with Hybrid Cloud in Canada podcast, KJ Burke and Michael Traves from CDW and Parth Pandit from VMware discuss the landscape of tools that are available to automate and orchestrate app portability, as well as containers, Kubernetes, GitOps and how to connect on-premises and multicloud environments. Here are some of the highlights of their conversation:

What should customers understand about orchestration and automation between public and private cloud?

A lot of customers come to us looking for a way to move to cloud. They’re looking to transition how they deploy workloads in their environment, and at a director level or CXO level, someone has come down and said “Thou shalt be cloud-first.”

And then, we get involved to help them with that transition. It’s really about trying to understand what workloads are running in an environment, what the dependencies are between various applications, what makes sense to move to cloud and how to actually restructure those applications, whether it’s a virtual machine or a container, to make it portable, so that it’s easily transitioned to a public cloud environment – but also, able to transition to multiple clouds.

If we can look at a workload, break it down into its components and start making those portable, such that they can run in multiple locations, that is the goal.

Do containers and VMs work differently across public and private cloud?

Automation is the key to success when you need to grow and scale. But it’s a difficult problem to solve when it comes to infrastructure automation, because there are different flavours of cloud, APIs and nomenclature.

We have tools like vRealize and Terraform trying to solve this problem, but we really need a layer on top of all the different clouds, which would provide uniform capabilities, uniform APIs, on which you can put your automation. That’s where VMware Cloud would come in, which hides the complexity in different  instances of different public clouds.

When it comes to containers, there is a great tool in Kubernetes, which would solve the container orchestration problem. If you have the same version of Kubernetes, you can be confident your application would work, no matter where the cluster is deployed. But you need to be careful that whatever Kubernetes platform you choose, it should be free from any vendor-specific features that would tie you to that particular flavour of Kubernetes, which could be a problem for you when deploying applications across a multicloud environment.

How to evaluate your multicloud environment

Some customers might think they’re running a multicloud environment, when maybe their production workloads are running in AWS, and the account email runs in Office 365 as their second cloud. And it’s not really the same thing. Understanding what multicloud actually means is the first step.

Once you’ve gotten past that, the next question is “Does it make sense to have a multicloud environment?” It certainly makes sense to put in that infrastructure layer that allows you to run your app in any of the clouds. Leveraging tools like Terraform, you can automate the deployment of your infrastructure in each of those clouds and deploy your application. And if you code all that upfront, it makes portability very easy, and that’s really important.

But at the same time, do you want to run infrastructure in the cloud, or do you want to run your application in the cloud? There’s an important distinction there. Whether it’s AWS, Google, Microsoft Azure or any public cloud vendor, they all have their strengths and weaknesses. It might make sense to run certain applications or certain workloads in each of those clouds.

You’ll also want to look at your own bench, at the skills you have in-house, and realize that if you go to your team and say “We’re going to put these apps in Azure, but we also want to put this other app in AWS, and we’re thinking of GCP for something else,” can you realistically expect your staff to really be experts at three different clouds, let alone one?

How does VMware approach reducing that level of complexity?

VMware takes the multicloud as a step-by-step process, with different things that you’re meant to consider at different levels.

The first thing is, how do you build your application containers using technologies that are cloud-agnostic? For example, using Cloud Native Buildpacks, which is not provided by a particular cloud vendor.

Then, what packing services will you use for your application? Perhaps you might use RDS instead of Aurora DB, which is AWS-specific.

Then, the next challenge would come when you need to manage multiple clusters that are deployed across different environments. A tool that gives you the ability to manage all the different clusters across different environments is the key to success.

The next step is, how do you monitor everything together? You need a single tool that gives you the single point of visibility for all the different apps and infrastructure, which may be deployed anywhere.

And finally, how would you integrate these different services? These might be running on multiple public clouds, or even a private cloud and public cloud model. In that case, technologies and tools like Spring Cloud Gateway or Istio service mesh would come into the picture. VMware’s Tanzu portfolio of products are also well suited for all these different concerns.

For more orchestration and automation insights, listen to Episode 4 now. And tune in weekly for additional podcasts in this series!