I completely agree with that. In fact, I actually helped a company in San Francisco, where the man who was running IT at the time did the equivalent of bursting. We were using bursting at the time. I think that that can work in a hybrid model. But I think that's almost the only time I would ever consider the idea of hybrid cloud as a reality. Otherwise, you're talking about what it sounds like Tim is saying, which is the idea that multi-cloud is actually one application spanning multiple clouds. Not one application, but an environment of applications, may be spread across multiple clouds as each cloud provides some level of benefit, unique to that application for the customer. But not that you're taking your ERP system as a unit, and splitting its parts across multiple clouds, or writing code for your own applications and running it in multiple clouds. Simply put, hybrid cloud is having some form of automated infrastructure, cloud-like or not, internal or in a hosted environment somewhere, co-location facility or something, that is allowed to, or capable of, bursting out some level of demand, normally just compute to nearby cloud resources. So if you don't have the latency covered in your compute, then what's the good of sending it out there and killing your application? So those are my simple takes on multi-cloud and hybrid cloud.
So I'll just maybe augment that a little bit, Mike, and say that the multi-cloud, I agree with you, there's a specific reason why you might choose a second, or third, or fourth cloud provider, but there's an advantage to focusing on one. And most enterprises that I work with focus on one, and then come back, second or third for specific reasons. But getting to that hybrid cloud, I actually don't see a single-use case in production today that I'm aware of, for cloud bursting specifically. And I haven't seen that play out in the enterprise. What I have seen play out is where things like regulatory and compliance and privacy requirements start to come into play, sometimes cultural issues. We've all faced the cultural norms that fly in the face of what we can do versus what we want to do. I would love to be able to use public cloud for a given application or given data set, but I can't, for a specific reason, and so then it's pulled back locally. Whether that reason is valid or not, we can argue until the cows come home.
Overall I find that having a common definition is helpful for architects, security teams, reliability engineers or such to understand what they are discussing. Otherwise, the ship for us to have one definition has been sailed by marketing long ago.
NIST does not have a definition of multi-cloud. But a general definition is the use of multiple cloud computing/storage services in a single network architecture.
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
1. Hybrid cloud includes data center virtualization, private and public cloud. Onnpremise to cloud connectivity plays important role here
2. Multi cloud is existence of multiple public clouds such as AWS, Azure, GCP or other hyperscalers in technology architect of a organization.
However, as mentioned, now a days it's most used almost with interchangeable meanings
Interesting question, looking for opinions of others. Thanks for asking.
Content you might like
Poor efficiency of the detection and threat hunting solution (SIEM/SOAR, EDR solutions)49%
Too much time wasted on false positive alerts64%
Lack of security skills and defined processes46%
Not enough demand in the market6%
Adding MDR and other advanced security28%
Consolidating vendors48%
Expanding product breadth33%
Automating processes52%
Outsourcing strategies (ex: SOC or NOC)19%
Differentiating from competitors25%
Focusing on reputation building14%
Moving more to the cloud17%
Redefining MSP metrics3%