Decrypting Cloud for the Future – Part 2

By Nathan Bennett  
Cloud Practice Lead

In this three-part future-feature journey, we’ll look at the connections between “cloud,” “multi-cloud,” and even more nebulous terms, like “super-cloud.” We’ll start at the basics, talking first about what is meant by “cloud,” and then build on that inquiry so we can better understand the new terms and determine whether they are ‘new’ at all.

My previous blog covered what “cloud” really means. Discerning how “cloud” is used in a written or spoken context is a first step, but the real definition I’m developing is the premise that “cloud” is built around a “self-service portal.” This in turn will build toward “multi-cloud,” and finally, in Part Three, I’ll take a look at the near future and “super-cloud.”

Multi-Cloud

Because you can see clearly now on “cloud” [after Part One of this blog] [hyperlink on ‘blog’], “multi-cloud” should be easy to understand. It means what it says: “more than one cloud.” So, if you have a private cloud and also use a public cloud, you are a multi-cloud customer. There is more to unpack here, however, as multi-cloud can also be defined as multiple cloud services. “Cloud services” may make “cloud” seem a little fuzzy again, but I’ll always refer to “self-service platform” as essential to the definition of “cloud.” If you’re accessing a self-service platform for your IT software or solution/s, then I’d say you’re ok to call what you have “cloud.”

Granted, things get foggier when you bring up a service like Microsoft 365. Some will say it’s a model — not “cloud” — because it doesn’t include infrastructure. However, the concept behind Microsoft 365 is that of an SaaS — a self-service platform that allows access to multiple pieces of software while also granting identity management.  That’s pretty much “cloud” to me. Notice that this definition also opens the field to many other “cloud” vendors. Anything running a software model that allows you to configure it in a self-service way (but not manage it) and that also runs on a platform you do or do not own, is a cloud service. Clear as a blue sky? I’ll repeat: If a resource can be granted via self-service, provided by a platform, then it is a cloud.

Other “Cloud” Terms

This leads to other cloud-based terms, such as “poly-cloud” or “hyper-cloud,” in which clouds are defined by how you consume them and the service/s you utilize. Once we’ve clarified “cloud” and “multi-cloud,” we start understanding cloud not in terms of where it is consumed but how. Understanding how your organization consumes cloud is a great thing because you can start viewing “cloud” less by what it is and more by what it does for your organization. The battle-cry of yesteryear (“We’re going to the cloud!”) is going away and is being replaced by terms like “cloud-smart” and “cloud-specific,” which indicate not that you’re moving information to some other location, but that you are specifically picking and choosing what services you need and will adopt for your enterprise.

Microsoft 365 is, again, a great story in this cloud journey. Did anyone ever love managing their email server? All the different components needed to keep it running created so many frustrations. I remember staying up late many nights, hoping to fix the email proxy because the region it covered was down and the execs were crying for blood. Then Microsoft comes along and says, “Oh, let us do that for you,” and IT folks jumped at the offer. The solution just fit. It allowed clients access to their productivity software suite, granted domain access for identity management and single-sign-on (SSO) authentication for multiple areas, and has nearly made the email-admin role go extinct (it is still around, but much reduced).

So, it makes sense that many organizations utilize the Microsoft 365 cloud service. The problem comes, however, when you’re consuming Microsoft 365 and have to figure out how to make that identity work in GCP (Google Computing Services/Google Cloud) or AWS (Amazon Workspace). That problem is the same when you are consuming AWS, and the identity provider doesn’t work with the domain you have provisioned. Complexity again rules, and the idea of “cloud-smart” becomes more difficult to achieve.

Chart Description automatically generated

Making multiple services cooperate with each other involves more and more complexity. For instance, I need databases, so I might use AWS Aurora, but I also need identity, so I might use Microsoft 365. Then I need data analytics, so I might use GCP BigQuery. Multiple clouds, different services, but they don’t connect easily. The question “How do we connect these together?” floats up, which will lead us into a future state, which may not be too far off in “super-cloud.”

.

.

.

.

Share the Post: