What really is cloud? It sounds like a straightforward question, but the answer isn’t as simple as you think. Find out why in the latest episode of our Multi-Cloud Podcast.
Which came first? The NIST definition of cloud computing or AWS?
If you guessed NIST, you would be wrong. The first draft of the NIST definition of cloud computing wasn’t published until November 2009, more than three years after AWS was launched (March 2006). It’s funny to think something that embodies the NIST definition of cloud computing so well arrived on the scene much earlier than the definition itself.
In the latest episode of our Multi-Cloud Podcast, Eric Nielsen, Robin Querin and I dive into what cloud computing really is. In particular, we discuss the differences between the notions that ‘cloud is a destination’ and ‘cloud is an operating model’.
Robin is the global lead for VMware’s Cloud Management Technologists practice. A big part of Robin’s job is to meet with customers and help them figure out how they can architect a cloud that meets the needs of a broad range of stakeholders and works across a complex multi-cloud landscape.
What makes something a cloud anyway?
The NIST definition is a collection of attributes characterizing what many would consider the most important operational principles underlying cloud computing.
These attributes are: :
- On-demand self-service
- Broad network access
- Resource pooling
- Rapid elasticity
- Measured service
AWS certainly embodies all of these attributes, as do Azure and Google. In fact, these cloud providers offer a broad range of managed services that far exceed the scope of what the NIST specifically called out in its definition. That’s why it’s easy to understand how the idea that cloud is a destination took root. You simply pick a cloud provider and off you go without ever having to think about the underlying operating model at work at each provider.
Cloud as a destination falls short
The simplicity of the notion that cloud is a destination is extremely attractive. However, the idea starts to break down when organizations must satisfy the needs of a large portfolio of applications. As each application has specific and unique needs, you inevitably wind up using multiple clouds to satisfy the full range of requirements. Many analyst surveys indicate the vast majority of larger organizations are using two or more public clouds. Most are also trying to implement some level of cloud computing in an on-premises data center.
If you have multiple clouds at work within your organization and you think that cloud is a destination; what happens when you want to have a consistent approach to offering on-demand self-service (or some other cloud computing attribute) across multiple cloud environments? This starts to become a massively complex capability to deliver. The simplicity of moving to a single cloud, which is what made cloud as a destination attractive in the first place, becomes a feature of the past.
On the other hand, if you start with a different idea of what cloud is – i.e. an operating model – you won’t be locked into the idea that cloud must come from a single provider. From the start you are thinking about how youI can achieve a cloud operating model that best meets the needs of your application portfolio, internal users and customers.
You still have to do some hard work to make multiple cloud providers function in a consistent fashion, but you have the advantage of knowing that is your goal upfront. This gives you the chance to make smarter choices around how to implement the processes and technologies that support a cloud operating model that works effectively across a multi-cloud landscape. That’s the advantage of choosing cloud as an operating model over cloud as a destination.
Listen to the podcast
Robin does a great job explaining the differences between the two models and why thinking about cloud as an operating model is better than cloud as a destination. However, he also points out that focusing on the cloud as just an operating model is not enough.
There is another overarching principle that has to be considered if you’re going to architect a multi-cloud environment. That principle can be summarized as ‘cloud is personal’. This idea is obvious when you think about it. To successfully implement any cloud strategy, you have to be keenly focused on the needs of major stakeholders.
For instance, a top cloud related priority for the CFO may be the ability to easily control the cost of cloud. On the other hand, the CMO may be most concerned with the ability to leverage the cloud to reach new markets in different geographies. Meanwhile, the head of application development wants a cloud environment that makes it easy to implement DevOps best practices.
You need to take into account a broad set of perspectives as you make choices around how best to implement a multi-cloud environment. Complexity comes from the additive nature of the exercise – multiple applications times multiple stakeholders.
That’s why you inevitably wind up having to design a cloud operating model that must work well across multiple clouds. While this may seem obvious, experience shows it is far from easy and often not done well. Robin talks about how often he sees organizations adopt a ‘just build it and they will come’ attitude, only to find that they don’t come.
Eric and I had a lot of fun with Robin on the podcast. We hope you enjoy it too.
Listen to the latest episode of the VMware Multi-Cloud Podcast on YouTube or SoundCloud. You can find all the episodes on our SoundCloud playlist.
More on what cloud really is
In addition to the podcast, Robin delves into the topic in a blog series titled ‘Cloud is…’ .
Looking to better understand VMware’s unique approach to multi-cloud architecture? Get the definitive guide here.
