IntegrationWorks Head Office - Wellington Central

Anyone who hasn’t been living under a rock has heard of the ubiquitous “Cloud” and the various benefits that taking advantage of it is liable to provide. Most organisations by now will at least have some flavour of “Cloud Strategy” in place or under development to reap these benefits so they can drive their business towards a glorious future.

But of course nothing is ever as simple as travelling salespeople would have us believe, and pretty quickly the clean “Cloud” darkens with turbulent prefixes of “Hybrid”, “Multi” and even the Grecian “Poly”. What do these modifiers mean, and how can we incorporate them into an appropriate Cloud Strategy?

The Cloud

“The Cloud”, without modifiers, refers to one or more of the “Big Players” public offerings. Amazon Web Services, Microsoft Azure and Google Cloud Platform have been the “Top Three” of such Clouds for several years. There are other players on the map though, looking to carve out a slice of the pie for themselves. The oft-referenced Gartner quadrants identify seven major Public Cloud providers.

A Cloud provides Compute, Storage, and Networking services – taking advantage of massive economies of scale to offer these at a price and stability point that quickly undercuts the option of hosting these services in a local data center or “Private Cloud”. A company that can host their IT services on a Public Cloud will benefit from a reduced operational expenditure, extreme availability of resources, and access to the latest in shiny tools to reimagine their workflows.

Hybrid Theory

One definition of “Hybrid” is “a thing made by combining two (or more) different elements”. For example, a Mule is a hybrid animal of a Donkey and a Horse, “Television” is a hybrid word pulling from both Greek and Latin, and a Prius is a hybrid vehicle powered by the combination of internal combustion, electricity, and an Uber driver.

A “Hybrid Cloud” then, is a deployment which combines both a Public Cloud from one of the Big Players, and a Private Cloud such as an on-premise server farm. Such a deployment tends to be the result of tactical necessity or is a transitional state, rather than an ideal situation.

As a case in point, in New Zealand – which is where I call home – many Government departments have strict “Data Sovereignty” requirements which restrict what data they can store off-shore. However, no major Cloud Providers have yet set up a region in our neck of the woods yet (although this will change, and soon) so a full Public Cloud deployment is not possible.

Although the data itself may be destined to remain deep in a basement under a sheep farm, often stateless services which access this data aren’t bound by the same geographical restrictions. We can then deploy these services to The Cloud, with a private link such as a VPN providing access to the data they require from Aotearoa. This gives us at least some technological flexibility when architecting and engineering solutions.

Multi Cloud

The prefix “Multi”, as you are no doubt aware, is Latin for “Many”, so Multi-Cloud naturally translates to Many Clouds, which sounds like a great way to ruin a trip to the beach.

In computing, though, Multi-Cloud is using the same type of cloud services from two or more public Cloud providers. Organisations may have done this to avoid cloud vendor Lock-in, provide extreme availability or disaster recover, or even through “Shaddow IT” where the lack of an organisational standard has resulted in separate teams deploying to their preferred provider.

Redundancy and lack of vendor lock-in may sound like valid reasons to adopt a Multi-Cloud approach, but it is worth balancing these perceived benefits with the corresponding cost of doing so. For instance, how available and resilient do you really need? A single AWS region comprises several geographically distinct “Availability Zones” – where each Zone represents a data center. So, even if you deploy to a single region, you still achieve a high level of availability and disaster recovery, provided you make sensible architectural decisions and don’t place all your cloud eggs in a single availability basket. Availability can then be further enhanced by replicating your deployment globally across several regions, each with their local availability stack.

Similarly, “vendor lock-in” sounds like a ‘Bad Thing’. But how bad is it really, especially through the lens of Public Cloud Providers, with The Big Three becoming ever more similar in terms of features offered? The overhead of architecting and managing your services so they can run on a set of Public Clouds instead of just one can often negate any amorphous “happy feels” you get from ticking the “Cloud Agnostic” box on your strategy document. Also, limiting yourself to technology which can run on any Cloud (such as sticking with containerised services instead of adopting a serverless deployment) can reduce the cost and performance benefits you might otherwise enjoy by utilising specialised Cloud-Native components. 

Poly Cloud

The prefix “Poly”, as you are no doubt aware, is Greek for “Many”, so Poly-Cloud naturally translates to Many Clouds, which sounds like… wait, haven’t we been here already?

Despite the linguistic similarities, Poly-Cloud isn’t just Multi-Cloud for Graecophile’s. Where Multi-Cloud means designing applications to run on several Clouds, taking a Poly-Cloud strategy means intentionally choosing specific components from different Public Cloud providers. For example, Azure AD is a widely adopted tool for Identity Management, and you want to take advantage of AWS Lex for its powerful speech processing engine. A Poly-Cloud strategy determines the best Cloud to provide particular functions and capabilities that make up your applications. By analysing the various offerings of each cloud, and selecting what best fits your organisations requirements from each component you can build a catalog of strategic cloud services which cover multiple cloud providers.

As mentioned before though, the services offered by the main Cloud Providers are becoming increasingly similar in scope. If your applications and services are straightforward enough, you probably find that services taken from a single Cloud Provider are sufficient for your needs, and you avoid the overhead of managing accounts with multiple Clouds.

How to Strategise 

A Cloud strategy is almost a requirement in today’s deployment landscape. Removing deprecating hardware from the list of IT assets that an organisation maintains is a sure path to reduced costs. The Public Clouds benefit so much from extreme economies of scale that it is impractical to self-host similar capabilities. 

A Hybrid-Cloud strategy is appropriate when there are on premise services, data, or applications which either cannot be, will not be, or haven’t yet been migrated to a Public Cloud. Adopting a Hybrid-Cloud strategy allows you to combine these systems with the requirements of global distribution and low latency.

A naïve Multi-Cloud strategy is likely to be more effort to manage and operate than it is worth. Unless your application has requirements for hyper-scale and apocalyptic levels of disaster recovery, then limiting your tech-set to services common across multiple Clouds reduces the benefit that deploying to a single Cloud provides.

A Poly-Cloud strategy allows you to choose the best of breed components from the various Public Cloud providers. This allows you to take full advantage of the set of Cloud Native components without locking yourself into a single Cloud Provider. However, with the gradual homogenisation of the Cloud Providers, you may find it just as convenient just to stick with a single provider.

Jonathan White
Integration Architecture