The definition of Hybrid Cloud is changing dramatically

There is a new definition of hybrid cloud evolving. #hybridcloud 

In the first few years of the cloud hybrid cloud has referred to companies that use multiple clouds, i.e. public, private or on-premise. 

Over the last year a new definition of hybrid cloud is emerging.  The ubiquitous nature of Kubernetes now means that people are deploying mainly to Kubernetes and the environment that the Kubernetes lives in is not as important.

Each of the clouds lets you deploy and run Kubernetes yourself on virtual machines.  They also for the last year have created hosted Kubernetes environments where they run and manage the Kubernetes for you.  

In addition, many companies are deploying Kubernetes on-premise. They may do this in a similar way to cloud companies on VM's or they may have hardware based Kubernetes deployments.

On top of this, companies such as Redhat with their product Open Shift and Pivotal with Cloud Foundry now embed Kubernetes.

The point is that when you build an application or service you now can assume that Kubernetes is provided and that you are deploying to a Kubernetes environment.

However, each of these Kubernetes may be different and the commands and DevOps to automate deployment of your service or application depends on what specific Kubernetes you are deploying to.

Agile Stacks, my company, supports this new definition of hybrid.

Your application or service is what we call a "stack." This may be composed of components and automation that sit on top of the assumption of Kubernetes and some basic services like networking and ingress, service mesh or other things.

The underlying Kubernetes is what we call the "Infrastructure stack layer" and your "stack" sits on top like a layer.

Ideally deploying your layer should work on top of any imported Kubernetes infrastructure stack regardless of if it is on AWS, GCP, Azure, hardware Kubernetes or a Kubernetes running inside OpenShift on-premise or in the cloud.

Why is this important?

When different groups build their services they have different requirements. When they deploy the application there may be reasons why you want to deploy it in different environments. For many reasons different groups may require or prefer different cloud providers or even to deploy on-premise.

This may be because of edge computing desire related to privacy and regulation. It may be because your customer desires to deploy it in their environment. It may be because you have to scale it across different regions of the world on different environments. It may be because you are distributing the application to different outlets of your company as major retailers do, or on your car platform as car companies want to.

In all these scenarios if you want to build a container based service or application that has the ability to do more than one thing at a time you will want Kubernetes to manage some of this. Therefore, your problem is building your service or application to run on the the cloud and Kubernetes.

Traditional Cloud Management platforms and DevOps tools do not understand this level of hybrid cloud. They are designed to operate either at the Cloud API level or at the VM level but they don't understand containers typically and they don't understand the different Kubernetes environments available to be deployed or what is running.

Agile Stacks is focused on helping you build your stack of containerized application or service and making it transparent which cloud or Kubernetes environment you want to deploy into.

Today we support a number of these environments and our goal is to support all Kubernetes environments. This means you can concentrate on your service and spend less time thinking about the DevOps to deploy it into whatever environment you choose for whatever reason to deploy it into.