Hybrid clouds are mixed computing environments that allow applications to use a combination of compute, networking, storage, and services in public clouds and private clouds, including clouds running on-premise or at a plethora of edge locations.
To accomplish this, hybrid cloud platforms must be designed to expose the best of the public clouds they support and present the advantages of private clouds while presenting a cohesive interface to the application developer—and preferably the cloud admin, too. A cloud admin can install a cloud instance called a cluster, consisting of a control plane (at least one instance) to manage the cluster and multiple compute instances that run applications on them.
In the rest of this article, "developer" specifically refers to a hybrid cloud platform developer, not an application developer. As a developer working on OpenShift, Red Hat’s hybrid cloud platform, I have found that designing features around a few key tenets ensures the cohesiveness that hybrid cloud platforms wish to achieve.
Here are three high-level considerations to keep in mind when designing a new feature for the hybrid cloud.
On-premise versus public cloud
It seems obvious at first glance that a developer would know immediately if the feature that they are working on is for a hybrid cloud offering on a public cloud or for an on-premise private cloud. In practice, it is possible that both types of offerings might need the same feature, with it being used differently in each setting. This might result in different implementations for public and private clouds with a unified interface presented to the cloud admin or application developer.
For example, the cloud platform is responsible for creating and configuring any load balancers it needs. The hybrid cloud platform might end up using the load balancer service provided by the underlying public cloud platform but starts its own in-cluster load balancer for on-prem clusters.
Startup versus runtime configuration
While designing a feature, it is important to consider if a specific piece of configuration that the feature depends on is known at the time of installation and does not change after that or is something that can change during the life of the cluster. After all, hybrid clouds are distributed systems where one component can affect the configuration that a different component acts on. Suppose your feature depends on a configuration that can change during the lifetime of the cluster. In that case, the feature's design should include a way to monitor changes to this configuration and take action based on that. On Kubernetes-based cloud platforms, this can be accomplished using the Kubernetes Operator pattern.
A simple example of startup configuration would be the platform on which the cluster is being created. That will not change for the duration of the cluster, but the number of worker nodes within the cluster can change during the lifetime of the cluster.
Admin pre-configured versus cloud platform configured
In some instances, the feature developer has to determine if the cloud admin can be enlisted to pre-configure some cloud components before the cluster can be installed with this feature. This is a great option for cloud components that do not change during the cluster's life cycle. On the one hand, a one-time pre-configuration by the cloud admin would not only simplify the implementation of the feature but also provide the cloud user the flexibility to replace this pre-configured component with a different one in the future. In this scenario, we should consider equipping the cloud administrator with the right credentials to perform these pre-configuration steps and separately the support costs associated with resolving misconfigurations in the field.
On the other hand, from the cloud administrator’s perspective, letting the cloud platform be responsible for all the resources it can configure and manage would result in a more hands-free solution with limited to no flexibility in accomplishing that. This is a trade-off that needs to be considered carefully. In some instances, a hybrid solution might emerge where the cloud platform manages all the resources that it can, with the cloud admin being able to choose amongst a limited set of options without the burden of pre-configuring resources.
The bottom line
With many dedicated solutions available for cloud functions like DNS and load balancers, you can now choose between in-cluster, cloud-provided, or custom solutions, and the hybrid cloud platform should be able to support all of these options.
Last updated: November 29, 2023