Link Search Menu Expand Document
Cloud Adoption Patterns

Hybrid Cloud Model

One of the earliest decisions many teams make (although perhaps too early) when moving to the cloud is deciding what destination that they should move to. A common misconception is that moving to the cloud means moving workloads to a specific public cloud. The problem is that this is too simplistic to reflect the real world - you can have cloud computing without necessarily moving to a public cloud, and what’s more, systems can actually cross multiple clouds, both public and private.

How do you balance the needs of security, productivity, cost-effectiveness and skills development when moving to a cloud computing approach?

In order to understand why the simplistic model of “cloud==one public cloud” is insufficient, let’s go all the way back to the 2011 National Institutes of Standards (NIST) definition of Cloud Computing. NIST defined cloud computing as “a pay-per-use model for enabling available, convenient and on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” Now let’s break that apart. Pay-per-use does NOT necessarily mean you are paying another company - pay-per-use is a statement of the accounting on the user side. Many large IT shops have cost accounting systems that allow them to bill resources by the use, per user. What’s more the self-provisioning statement also does not necessarily imply that the computing resources must be held by a separate company. Again, many large IT organizations also pool resources, and provide self-provisioning capabilities within their IT infrastructures.

In short, cloud computing can embrace multiple models, both on-premise and off-premise. While there are obviously many cases in which a public cloud provider is exactly the right choice for many projects, there are perhaps just as many in which it is the wrong choice for a particular workload. There are several factors which weigh on this:

  • Security and Data Residency: While public cloud security has improved to the point that it is possible to build cloud-based systems that are as secure if not more secure than on-premises systems, the fact remains that the perception of cloud-based systems as being less secure remains. So long as that perception remains, many companies will be reticent to put their most important data onto a public cloud. However, while the overall security perception is only in the mind, what is a hard reality is the fact that many countries have a data residency requirement that insists that private information about their citizens remain within their borders. This means that for those solutions that are based in a public cloud that does not have a presence in that particular country that the best choice for compliance in storing that data remains in an on-premise data store.

  • Productivity and Skills: Teams that have built and operate entirely cloud-native systems can be enormously productive, as research such as Forsgren has decisively proved. However, being that productive requires that teams aquire a skill set around Agile methods, particularly the technical practices of Agile methods, DevOps and cloud native technologies such as Containers and Automation. Many teams do not yet have that skill set. What’s more, they do not have the support within their organization to enable them to acquire that skill set. What we have seen is that there is no magic in the cloud - if you build, manage, and operate a system on the cloud in the same way in which you have built, managed, and operated systems on-prem, then there is no net new benefit derived from being on the cloud in this regard. It will take just as long to build systems, it will take just as long to test them, and tit will take perhaps even more time to operate them and solve production issues due to the extra complexity added by an unfamiliar VM, storage and networking environment.

  • Cost-Effectiveness: No myth is more persistent than that that the cloud is always cheaper than any on-premise option. The fact is that the cloud can be cheaper, and substantially so, but only if an application is designed and enabled to take advantage of the technical features that make the cloud cheaper. There are many of these, but the simplest to understand is elasticity - if your application is able to scale horizontally both up and down in response to traffic, then you can save a substantial amount of cost related to compute infrastructure by only paying for the infrastructure you need, when you need it. However, all applications are not designed to take advantage of horizontal scalability. If an application is built around the assumption that servers are forever fixed in size, number and connectivity to one another, then this cost savings is illusory.

Therefore,

Choose a Hybrid Cloud model that allows project teams to choose the right location, on-premise or off-premise, private or public, that fits their needs for security, data protection, cost-effectiveness, and skills

Existing systems that were not built to take advantage of the cloud will gain little from being moved to the cloud without change. In fact, they may become harder to manage, debug and operate. On the other hand, there are many ways in which you can gain advantages if you consider a model that may mix the public cloud with on-premise private cloud and traditional models.

If you have an existing system that contains valuable data that could be useful to your clients or customers, then it may be helpful to expose that data as an API from your on-premise system to a new application that can be built in a cloud-native way. You can then deploy that application in a public cloud, or perhaps in a private cloud.

Another common option when modernizing an application is to apply the Strangler Application and to deploy the application in a split mode across both a traditional environment and either a public or private cloud. This may be combined with Containerize the Monolith if adoption of containers and a Container Orchestrator such as Kubernetes is also part of a long-term strategic plan.