Ask any three people to define the “cloud” and you will get three different versions. Developers often scoff at the term, dismissing it as marketing speak. Companies don’t agree either. EMC, HDS, and Nasuni each have slightly different and nuanced opinions on what the cloud is exactly, and how it meshes with traditional IT. This post is the first in a series that will explain the differences between public and private clouds, but before I get into those details, I’d like to address those conflicting opinions, and introduce the five key attributes of the cloud – what makes it “The Cloud” today.
First, the cloud is not a catchall term. It shouldn’t be used to include the likes of Hotmail, Gmail or even Facebook. These are simply applications that are hosted elsewhere, and including them in the definition of the cloud, well, clouds things up. Hosted applications and services define the Internet. They are the Internet. There’s no need to add them to the cloud bucket.
In fact, we should discard applications entirely from our definition of the cloud. That means Gmail and Hotmail, but also Bitbucket, Github, and a whole host of applications and services are out. Applications can be built on the cloud. The cloud might be the foundation of the application, and that architecture may bring certain features to that application it might not otherwise have. But the application should be excluded from the definition of “cloud”.
Instead, we need to constrain the definition of the cloud to the “foundation” of applications and services. Think about what you need to build and deploy modern applications (including web applications). You need the basic components: network, storage, CPU, an Operating System, maybe a database and code.
In a pre-cloud or traditional environment, your path to building a new application, no matter your role (IT, HR Department, Developer), followed roughly the same basic steps
- Identify needs
- Find the hardware resources
- Develop, test
- Acquire deployment hardware
- Release
- Buy more hardware to scale
If you’re lucky, you know your exact requirements ahead of time and only buy the hardware you need. Typically, though, you don’t buy or find enough and you fail at launch. Or, if you’ve got money, you buy too much and it sits idle and your capital expenditure rots.
There’s risk and pain at every step – especially when it comes to the allocation of resources. If you don’t buy enough, you die, but if you buy too much, you burn through your cash. It’s very hard - if not impossible - to know how and what to buy for most projects. This is hardly a new story: Overspending on IT infrastructure is almost how the industry runs. Distributors want you to spend $5M upfront on infrastructure you probably won’t need. If you do, and you outstrip it, you’re locked in, so they can charge you more in a few years.
This is where the cloud comes in.
When Amazon first announced Amazon S3, a few other Nasuni folks and I were working at Archivas on a distributed storage archive (now called HCP or Hitachi Content Platform). At the time of the announcement, our product sold for a few hundred thousand dollars and could easily scale to petabytes of data. It was object-based, had a REST interface, etc. – the point is that it had many of the same attributes as Amazon S3 (at least on its face). Distributed storage clusters/archives weren’t new. The Archivas/HDS product, Centera, and a whole host of large-scale systems were on the market or being developed (EMC, HDS, Netapp, among others). There was even plenty of open source competition!
In a single announcement, though, Amazon changed the game. What they did was something no one had thought of - or at least had not weaponized and sold. But in hindsight it makes perfect sense. Amazon had spent millions of dollars developing their own internal distributed object store (S3) and infrastructure and in doing so had also scaled it out too much. They had excess resources. They then made the critical decision:
Sell the excess.
What we didn’t realize at the time was that this was the tip of the iceberg. Amazon quickly iterated the API, and began releasing other services. EC2 (compute) and others soon followed, all based on the excess “foundation” materials Amazon had amassed in building their giant online empire. Amazon’s new offering was simple to understand and easy to use. (Once they got past the SOAP API.) Not to mention that they had the account management system just sitting there. Every single Amazon customer could use it. That’s built-in critical mass!
Amazon had taken the first, biggest step, into building out the cloud. They fundamentally changed the infrastructure game, though I doubt whether they knew in advance what they had unleashed. They obviously continue to be the dominant force in the cloud market.
Back to the cloud itself - yes, we’re focused on the foundational aspects of the cloud, but I think it’s fair to say that the cloud as it now exists, thanks in large part to Amazon, has these core attributes:
Self-Service
This is the concept that users do not need to ask permission to allocate or free resources. They can consume resources as they need and only what they need. This allows them to keep costs low, but scale out. They do not need to involve six layers of management and IT organizations. There is no middleman.
Ease of Use
The cloud has to be easy to use. Any vendor married to complex APIs (I’m looking at you, SOAP) is going to fail. A good self-service model takes into account not only sophisticated developers, but someone in a large organization just trying to get a simple task done.
Scalability
Say you’re building a website that stores pictures of cats. You need the foundation or architecture that will allow you to store millions of pictures without missing a beat. Sure, you’re going to start small, but you’re going to want to leave room for growth. You should never discount the need for scale for what you’re building.
Speed and Agility
The cloud must be reasonably fast. It must be fast to provision and fast to use. Sure, at scale there will be latency, but it has to be as fast as possible, allowing the applications on top of it to optimize as needed. Provisioning must be lights on in terms of speed and ease of use. It must be equally easy to release and destroy those resources for billing reasons.
Pay as You go / On Demand
One of the massive annoyances people have with traditional hardware allocation and purchasing is that you invariably dump a lot of money into buying and building out infrastructure, when you only end up using a tiny fraction of it. The storage industry is notorious for this. The cloud has given power to the “pay only for what you eat” idea that has been sorely lacking for decades.
These five attributes, simply applied to the foundation of modern applications – Operating Systems, CPU, Memory, and Storage - are what make the cloud so powerful. Applications or systems built on these virtualized computing resources – such as the Nasuni Filer – gain these attributes as features, leveraging them to bring users “mega-features” such as instant recovery of critical data. The cloud is a technical reality, and a critically important computing trend.
The interesting bit is that these attributes apply equally to the concepts of “Private” and “Public” clouds. At the same time, there are critically important distinctions between the two. I’ll get into all of this in my next post. For now, sound off in the comments or send any questions to feedback@nasuni.com.
Part II: Defining Public and Private clouds