I’ve been in IT since 2001 and countless times I did notice that people are confused by all these “Cloud” “Buzzwords”. Therefore, in this brief article I want to give a short explanation what actually is a “Hybrid,- Multi Cloud Approach”?
In our new digital world, digitalization needs to be adapted in every company, regardless of sector and size of the company. Everyone is in need to get adopted as the new market demands are changing at a dizzying speed, a kind of speed we have never seen before. And a lot of companies are struggling to adapt to these new trends with their existing infrastructure and their established long-proven (on-premises) processes.
Just start off with “pushing” apps/services in the cloud? Is it really that easy?
No, as you for sure already know, it isn’t, it never has been in IT. Your whole Infrastructure, your workloads, applications and processes, those things are all unique in every enterprise and therefore, every single hybrid cloud strategy must be tailored to your own specific needs and desires.
Once you start adding some cloud services to your company, e.g. with Microsoft Azure or AWS, you become a Hybrid Cloud consumer, maybe without even realizing. So you have to get prepared for this scenario, it will be a really challenging journey and you will encounter a lot along this way.
Are you afraid of moving into the cloud? Don’t! 🙂 It will make your life easier and reduce some of your concerns & worries.
Hybrid IT is the new normal. Most companies are doing it already, as mentioned, without even noticing. Whatever you are looking for, e.g. build the next high-sophisticated Datacenter, getting control of your shadow IT or building the next future application consisting of several Microservices (whereby each single microservice represents a dedicated asset for the company).
But even though it is the new normal, a standard approach does not exist for many partners & customers. No enterprise can simply leap into the (hybrid) cloud without even considering some of the typical characteristics of a reasonable hybrid cloud environment.
The Important 5 points for a successful hybrid Cloud approach are:
- Integrated network services between the different cloud layers and your corporate network, so that you have to manage ONE network. It just extends the corporate network in a way.
- ONE Identity provider which is capable to authenticate users & groups across multiple Cloud / on-premise environments. You absolutely want to avoid managing several user environments. This has to be centralized.
- Make sure that you have a reliable and stable connectivity between the Cloud Provider(s) and your local datacenter / enterprise.
- ONE solution to monitor all your resources and objects across the Cloud / Local Datacenter.
- Unified Management Layer to administer and operate all resources across the different Clouds
So the most common example for that kind of mixed Hybrid Computer environment is by combining your own local datacenter computing environment with a public cloud provider.
And of course, taking those five points above (The Important 5 points for a successful hybrid Cloud approach) into consideration and surprise surprise, you already have some kind of a Hybrid Cloud environment!
But wait a second….. Where does “Multi Cloud” come into the picture actually?
As you can see, a multi-cloud deployment might also include local compute environments in your company. But why did we choose 2 public cloud environments here (in this example Public Cloud 1 and Public Cloud 2 (AWS and GCP)?
There is a very easy explanation for this approach.
Never put all your precious data in just one basket & also avoid a vendor-lock. Therefore, always go with a multi-cloud strategy instead of just “one” public cloud provider. The Cloud(s) have been getting really mature and they still do. Especially the big hyperscalers like AWS, Azure, GCP, Alibaba have already provided and proved great agility and flexibility for your business assets.
But nevertheless, the famous statement “‘ONE Big Cloud Service’ fits it all” runs counter against the initial promise of “Agility” and “flexibility”. Therefore, mix it up due to several reasons. To name just three:
- Reduce your risks, with using Multi-Cloud providers. This way you might maintain a service even in the case of an outage with one provider
- Using the “best of breed” is always a good idea since every single Cloud Provider does have their weaknesses and strengths when it comes to services and feature offering.
- Dependence on only one provider can put us in a risky situation for several essential aspects of our business such as workloads, applications, user management,…. Redundancy is the key word here!
You see, this way YOU can make the cloud fit your needs, not the other way around.
So, in a nutshell summarized:
Is actuell when you split up your workloads across multiple datacenters (Cloud, on-premise, co-location, your private basement at home etc etc,…). It means that your application is divided into several pieces (Could be Microsservices within a Kubernetes Platform) and they have to interact with each other to do something right here.
This is, as briefly mentioned above, just your workloads, running within more than just one datacenter or cloud provider. But basically (unless I consider the 5 big points above to build up a Hybrid Cloud Approach) these workloads which are distributed have nothing to do with each other.
But, wait a sec – again…. Didn’t we forget something here. Of course! These two (Hybrid and Multi) can be combined! Which means a logical and physical combination of the both of them. It might seem like this:
This situation has been, in the past, often just a temporary thing to facilitate a simple migration of good old-fashioned workloads between clouds. But in my point of view this style of setup actually represents the future state of many many organizations since they have been building new applications in a new style, the so called “Cloud Native Approach”.
In a nutshell this means (Cloud-Native-Approach) that everything is broken down into different layers and henceforth Disaster Recovery methods are no longer achieved on the Hardware layer “or” Operating System layer but at the application layer itself.
This means that any kind of dependencies on hardware or the operating system just “disappear”. Those new developed “cloud-native” applications (provided in containers) are designed to exploit all advantages a cloud can offer to you including all of its flexibility, agility and elasticity.
But be careful….. Because of all those glittering marketing buzz words here.
For years all the marketing departments have not been asleep but invented a lot of glistering names and buzzwords for all sorts of Cloud promotions. And at the raise of all those great buzzwords and companies who are peddling with it and ringing your doorbell too, please do not get blindsided. Take the Journey yourself and dig into it which will take quite some time. Just try to avoid the often huge vendor influence from the big players in the market.
So, bottom line, look it up yourself how your cloud strategy could be, involve all necessary technical experts from your IT departments (internal and external) and start off with some kind of brainstorming and go from there the next mile. Do that on a regular basis until all points and considerations have been taken into account.
Create Independence within your organization!
In my point of view, one of the most important decisions about “which pattern to use” within a Cloud Approach is to make your application portable! So in a worst case scenario you might just push your application workload into another cloud (e.g. from Azure to AWS). This way you can really avoid any kind of vendor lock-in and it gives you the power to negotiate with the vendors in an even more attractive way.
To make this a reality and to create this kind of independence within your organization please do have at least two different thoughts in your mind:
- Look out for the right tools / software that runs on nearly every cloud. A really good thing here is to make use of open-source software. Open source software generally runs on every platform/cloud. Normally you have no technical constraints with OSS and no license-technical limitations.
- But to make point “1)” even feasible, we need some kind of abstraction between the Cloud Layers in a Multi-Cloud Approach. So what we need is an abstraction framework like a Kubernetes Plattform (e.g. OKD/OpenShift) straight on top of the Infrastructure/Hardware layer. And with this unified approach we are enabled to develop our application just once and deploy it to any cloud environment afterwards.
To dig a bit deeper into the different patterns of the “right” Multi-Cloud Approach there is a really good article below:
“Multi Cloud Architecture: Decisions and Options – Dissecting a Multi-Cloud Architecture” (Link below)”.
Conclusion – where does it leave us with our own journey into the Cloud?
I’m quite sure that we will see, furthermore, a tremendous increase in moving data & applications into the cloud. Especially the utilization of colocation-locations and public cloud providers will increase dramatically, since building up our own data centers and infrastructure on-premise is already becoming less cost effective, less reliable and less elastic.
That being said and with the focus on hardware investment and scale, we are getting practically forced to move into the Cloud. So, don’t miss the trip and do it on-time! :).
More on Cloud Architecture:
The State of Multi-Cloud in 2020
Multi Cloud Architecture: Decisions and Options – Dissecting a Multi-Cloud Architecture
Hybrid and multi-cloud patterns and practices
Hybrid and multi-cloud architecture patterns