Hybrid Cloud Decisions: When to Target Public and Private?
Introduction
The hybrid cloud model by definition has both private and public elements. In the context of IBM’s hybrid multi-cloud approach, this means that there is an OpenShift-based Kubernetes platform available in both the private environment and via the public cloud or public clouds that are chosen to be part of the overall architecture.
The value model that makes hybrid cloud more compelling than a public cloud-only strategy is based on offering landing zones that have different costs to establish and run as well as a level of consistency across those landing zones. The returns are also conditioned by the modernization effort involved in targeting these landing zones. Choosing to land applications or components of applications onto the private cloud landing zone versus the public cloud landing zone is a strategic choice. This choice is informed by technical and business level analysis of the applications being targeted for the cloud. The rest of this article provides guidance, based on our experiences in the cloud engagement hub, on how to make this strategic choice.
In a future article, we will then cover the tactics involved in executing on the strategic direction that is chosen for a given application or component of an application. A hybrid model in fact, as you will see in the future article, offers opportunities to leverage some interesting tactics.
Strategic Decision
Placing an application or component of an application onto a private cloud versus a public cloud is a strategic decision. This means that it would be the expectation that applications would run in the selected landing zone for the foreseeable future. In the private cloud space, the foreseeable future should be thought of as 4 or more years. This is because we know that as time progresses, thinking evolves, data center strategies change and there will always be ongoing questions asked about when and how a move to public cloud can be achieved. We also know that there is some general necessity to commit to capital and maintenance of a private platform. With that in mind, this figure represents the bigger picture and the thought process that needs to be followed:
Making the decision to choose a private cloud versus a public cloud is based on a number of key factors. These include:
1. Data gravity — the operational data for some applications may need to reside on-premises for regulatory and/or data privacy reasons. Some countries require that data physically reside in the country where the data is collected or processed. If a public cloud data center is not available in that country, then the data and its related applications may need to stay on-premises. Applications should typically “follow the data” and be located in the same physical site as the data in order to avoid any latency issues in accessing the data. This is a strong suggestion for applications which are being containerized. Applications that are refactored can be built using techniques that reduce the latency concern.
2. Security and Compliance — While the options are improving in terms of public clouds supporting various compliance requirements, there is still a lot of work, cost and time required to really ready a public cloud to run compliance workloads. Workloads and data are typically more secure when run on-premises since they are running in a dedicated environment, versus running a shared environment in the cloud.
3. Integration/Dependencies — Existing applications that are candidates for modernization may have requirements for low latency access to existing data stores and/or applications, or the requirement to bring lots of data into the application for processing. As mentioned in point 1 above, applications should typically be located in the same geographic location as the data in order to minimize data latency. Applications may also have dependencies on on-premises middleware (e.g., DataPower, MQ, Kafka, etc.) in order to integrate with other applications, driving the need to keep these apps on-premises. These existing middleware installations may also be shared services which are leveraged by applications that are not being modernized.
4. Hardware accelerators — some applications may utilize hardware accelerators for specialized processing that may not exist in the public cloud, especially at a price point that make public cloud deployment feasible.
5. Operations — some applications may have built-in dependencies on operations tools and capabilities that are not readily available in the public cloud. This is typically true of home-grown utilities that cannot be deployed to the cloud, or other proprietary tools that cannot be deployed to the public cloud due to technical or licensing limitations.
6. Use of custom protocols — Non-HTTP based protocols used between application code and backend dependencies might not be as public cloud friendly.
7. Availability/Resiliency — applications with higher availability requirements may be better suited for the public cloud, as a cloud provider can often provide multiple availability zones that span multiple geographies at a lower price point.
8. Ephemeral/Bursting Workloads — application workloads that need to scale up quickly for short periods of time are a good fit for the elasticity of the public cloud.
As can be observed, some of these factors favor public clouds while others suggest a private cloud landing zone is preferred.
For the factors that favor private clouds, it should be pointed out that many, if not all of these factors can be overcome by investment in various modernization techniques. The question becomes one of return on investment. For applications that are categorized as maintain or stable, making changes so that the application can run properly on a public cloud may not provide sufficient return on investment. The sweet spot might just be to run the application in containers on-premises in a private cloud, near to dependencies.
Most if not all of the factors described above relate to and apply to running production workloads. Our experience suggests that development and other non-production workloads, irrespective of where the production cluster is, are very good candidates for the public cloud landing zone. They can leverage the elasticity of a public cloud and seldom have the same regulatory and security constraints of production workloads. The only exception are those non-production environments that truly need to replicate production in areas like scale and the use of production caliber data.
Final Word
A combination of business and technical work is required to take advantage of all that a hybrid cloud approach has to offer. Current Modernization techniques are leveraged in either case, but the modernization investment required when going to a private cloud is usually less than the investment required to target a public cloud landing zone. That said, the cost of establishing and maintaining a private cloud platform will be higher than that of consuming cloud-based OpenShift services.
Careful assessment of the applications under consideration must be done to determine the proper landing zone. This short article has outlined a number of criteria that we have established based on our experiences.
With this knowledge now on board, the next article will talk about the tactics involved in getting to the public cloud.
Thanks to Greg Hintermeister and John DeMarco for helping me prepare and review this article.
