Hybrid cloud: Weighing up what to run in the cloud and on-premise

Within large, enterprise IT environments, senior management are increasingly pushing their IT department to pinpoint applications and services that could be pushed off into the cloud for performance, cost and resiliency reasons. But how do you go about deciding what should run where, and which workloads might be better off running where they are now?

In some instances, these decisions may lead to enterprises embracing a hybrid cloud setup, whereby they retain some applications and workloads on-premise, while others are handed off to run in the public cloud.

When done right, hybrid cloud enables enterprises to tap into the best of what on-premise and public cloud have to offer in a highly dynamic way.

But the tricky bit is deciding how the parts of the puzzle – servers, services and the like – fit together, and which parts are best suited to life on-premise and which parts in the cloud.

When making these decisions, it may sound obvious, but the first thing to consider is the application’s suitability for running in the cloud – and not just from a cost perspective.

To most people, “a server is a server” – but it doesn’t always work out that way. For example, non-mainstream hardware that is only provided by a small group of specialist cloud providers is rarely a good fit for the cloud, and neither is legacy infrastructure.

Some examples of these include AS/400, RISC-based systems, and others. Of course, the field of available providers will be very much reduced based on our next point – data locality.

This is an extremely hot topic and a contributing factor as to why cloud-based providers offer multiple geographical locations. Depending on where the business is located in the world, there are differing laws and complexities around what data can be stored in-region and out-of-region.

A prime example of this is the General Data Protection Regulations (GDPR) and the importance it places on data locality. Failure to adhere to these rules – and keeping customers informed as required – can result in huge fines.

Similarly, the application infrastructure should be geo-located as close as possible to the application consumers. This is good practice because it helps the application performance for the end-user.

The fragility and complexity of the application or system being considered for migration is also another important consideration, and one that a lot of people either forget about or hope that moving to the cloud will remediate.

There are a number of issues that can affect the decision to move such systems. The more complex the system, the more resources it consumes, as well as being more fragile.

Another factor in this discussion is the age of the system. We are not just talking about servers that are a few years old, but applications that are running extremely old legacy code.

From personal experience, I have seen relatively modern operating systems shoehorned onto legacy infrastructure written on a long-dead language or application platform.

The long and short of such systems is that if they are working as they should, leave them alone.

Otherwise, moving such systems to the cloud can mean changes being made to what could be called antique applications. Such nasties can include licensing agreements tied to specific hardware, or whose terms differ when running on cloud-based infrastructure compared with on-premise deployments.

Problems can also occur as a result of hard-coded environmental configurations, such as hostnames and IP-related information, or applications that require some form of direct hardware-level interaction.

In short, such applications should be left alone, as modern applications are typically a much better fit for the cloud environment.

The best remediation path (and potential path to the cloud) is to re-architect the system. This may sound onerous, but bear in mind that it provides a clean-ish sheet that allows the designers and developers to architect around the dynamic nature of the cloud and the cost efficiencies that can come with it.

Hand in hand with the fragility of the application is tending to the interdependencies that exist within the infrastructure before migrating to the cloud.

The infrastructure often consists of many interconnected services. It is only an administrator who does not value his or her job or sanity that embarks on such a move without checking (and documenting) all the interactions between the application and supporting services.

And untangling this web can be quite an undertaking. If there are too many back-and-forth transactions between the on-premise site and the cloud, it can severely degrade application performance across the board.

The security aspect is vastly overlooked and often underfunded. Moving into the cloud means moving into a shared infrastructure. Although isolation is usually provided by virtue of the underlying hypervisor, there have been known instances of various exploits being available that can allow hypervisor escapes.

On a more practical level, depending on your agreement with your customers, you may have a legal requirement to use infrastructure as a service (IaaS) rather than shared platforms, such as shared databases.