For my role at Dell, I’m continually invited to seasons of meetings to define cloud, cloud architecture and cloud strategy. The reason these meetings go on and on is that everyone wants to make cloud complicated when it’s really very simple.
Cloud is infrastructure with an API.
That’s it. Everything else is just a consequence of having infrastructure with an API because API provides the ability to provide remote control.
What else do people try to lump into cloud? Here are some of my topic cloud obfuscators:
(inter)network. Yes, networks make an API interesting. They are just an essential component but they are not cloud. Most technologies are interesting because of networks: can we stop turning everything networked into cloud? Thanks to nonsensical mega-dollar marketing campaigns, I despair this is a moot point.
as-a-service. That’s another way of saying “accessible via an API.” We have many flavors of Platform, Data, Application, Love or whatever as a Service. That means they have a API. Infrastructure as a Service (IaaS) is a cloud.
virtualization. VMs were the first good example of hardware with an API; however, we had virtual containers (on Mainframes!) long before we had “cloud.” They make cloud easier but they are not cloud.
pay-as-you-go (service pricing). This is a common cloud requirement but it’s really a business model. If someone builds a private cloud then it is still a cloud.
multi-tenant. Another common requirement where we expect a cloud to be able to isolate users. I agree that this is a highly desirable attribute of a good API implementation; however, it’s not essential to a cloud. For example, most public clouds do not have true network isolation model.
elastic demand. IMHO, another word for API driven provisioning.
live migration. This is a cool feature often implemented on top of virtualization, but it’s not cloud. We were doing live migrate with shared storage and clusters before anyone heard of cloud. I don’t think this is cloud at all but someone out there does so I included it in the list.
security. Totally important consideration and required for deployments large and small, but not presence/lack does not make something cloud.
We start talking about these points and then forget the whole API thing. These items are important, but they do not make it “a cloud.” When Dave McCrory and I first discussed API Infrastructure as “cloud,” it was driven by the fact that you could hide the actual infrastructure behind the API. The critical concept was that the API allowed a you to manage a server anywhere from anywhere.
When Amazon offered the first EC2 service, it had to be a cloud because the servers were remote. It was not a cloud because it was on the internet; plenty of other companies were offering hosted servers. It was a cloud because their offering allowed required operators to use and API to interact with the infrastructure. I remember that EC2’s lack of UI (and SLA) causing many to predict it would be a failure; instead, it sparked a revolution.
I’m excited now because we’re entering a new generation of cloud where Infrastructure APIs include networking and storage in addition to compute. Mix in some of the interesting data and network services and we’re going to have truly dynamic and powerful clouds. More importantly, we going to have some truly amazing applications.
What do you think? Is API a sufficient definition of cloud in your opinion?
It’s impossible to resist posting about this month’s 451 Group Cloudscape report when it calls me out by name as a leading cloud innovator:
… ProTier founders Dave McCrory and Rob Hirschfeld. ProTier [note: now part of Quest] was, indeed, the first VMware ecosystem vendor to be tracked by The 451 Group. In the face of a skeptical world, these entrepreneurs argued that virtualization needed automation in order to realize its full potential, and that the test lab was the low-hanging fruit. Subsequent events have more than vindicated their view (pg. 33).
It’s even better when the report is worth reading and offers insights into forces shaping the industry. It’s nice to be “more than vindicated” on an amazing journey we started over 10 years ago!
Rather than recite 451’s points (hybrid cloud = automation + orchestration + devops + pixie dust), I’d rather look at the problem different way as a counterpoint.
The problem is “how do we deal with applications that are scattered over multiple data centers?”
I do not think orchestration is the complete answer. Current orchestration is too focused on moving around virtual machines (aka workloads).
Applications are a dynamic mix of compute, storage, and connectivity.
We’re entering an age when all of these ingredients will be delivered as elastic services that will be managed by the applications themselves. The concept of self management is an extension of DevOps principles that fuse application function and deployment. There are missing pieces, but I’m seeing the innovation moving to fill those gaps.
If you want to see the future of cloud applications then look at the network and storage services that are emerging. They will tell you more about the future than orchestration.
I’m posting my OpenStack bio here and asking for support putting me on the Policy Board by voting for me. NOTE: You can only vote if you’re registered and you got the “Poll: OpenStack Governance Elections” email.
Project Policy Board Objective
I am seeking a role on the OpenStack Policy Board to further the adoption of OpenStack within and beyond the community. As the OpenStack technology lead within Dell, I am the engineer who is most actively engaged with field deployments; consequently, I am uniquely positioned to represent our development community, hosters and enterprise user bases. I bring substantial process experience (Agile/Lean/CI) into my decision making. My focus will be on ensuring OpenStack is deployable and ready for use.
I am a Principal Engineer at Dell working as the lead for our OpenStack cloud initiative (http://dell.com/openstack). My team at Dell is responsible for bringing hyper-scale cloud solutions to market and works closely with our cloud optimized hardware division (DCS). Before working on the OpenStack project, I was involved in cloud projects for Azure, Eucalyptus, and Joyent at Dell.
My involvement with OpenStack goes back to the very earliest days before the project was launched where I was part of the evaluation team that advocated for Dell to join the project. Since then, I have been active participant at every design conference. It was my recommendation that Dell focus on making deployment capabilities for OpenStack and to ensure that those contributions are open sourced (Apache 2). At this point in the project, I am Dell’s technical authority on OpenStack for community and customer interactions.
My team is responsible for the Crowbarcloud deployer(http://github.com/dellcloudedge/crowbar). The purpose of this project is to ensure that OpenStack is be quickly and reliably deployed in a wide range of configurations on any hardware platform. I believe that ease of deployability is essential for the success of OpenStack as a project because it ensure adoption by non-developers. I also believe strongly in continuous integration and am working to adapt Crowbar as a CI platform. I have been the primary driver to ensure that the Crowbar project is open sourced and accepting of input from the community.
My team also designs technical reference architectures (RAs) for OpenStack. These RAs help drive adoption by providing crisp guidance on how deploy OpenStack. I am a vocal proponent of open operations (keeping best practices public) and following a DevOps approach for ongoing cloud deployment life-cycles.
In addition to my work at Dell, I work to ensure community access and communication. My independent blog provides technical detail and insights about the OpenStack and other cloud initiatives. My blog also focuses on Agile and Lean practices that I believe are essential to success in technology innovation.
I have been working with cloud computing since 2001. The company I founded with Dave McCrory (@mccrory), now owned by Quest, was the first multi-server VMware ESX deployment ouside of VMware. We pioneered the concept of elastic vm management (look up the patents!) so I have a very deep understanding of the problems and architectures required.
Sometimes a single sprint can deliver magic: when I signed up to document how to create a Crowbar module (aka a barclamp) two weeks ago, I had no idea that it would add a new flavor to Crowbar .
I’m proud to announce that the first public non-Dell Crowbar module will be supporting the VMware Cloud Foundry Open PaaS project.
Development is still in progress (on the Crowbar “CF” branch) and you’ll be able to watch us (even help!) collaborate on this project. Initially, the deployment will be to single server but we’re hoping to quickly expand to a distributed install that fully leverages the capabilities of both projects.
By creating a Crowbar module, Cloud Foundry™ is able to leverage the cloud deployment capabilities that allow it to be setup on any physical or virtualized data center. This is core to the Crowbar message: the value of a cloud solution can best be realized when it’s coupled with open practices for deploying it.
There are many significant aspects of this collaboration:
Cloud Foundry is taking the right approach to PaaS. Their team’s perspective on PaaS mirrors my own: A PaaS is a collection of application services. That approach makes it extensible and flexible. Plus, they are also multi-language and multi-platform.
Crowbar is proving our breadth of support. Last week we announced coming RHEL support and now adding Cloud Foundry is a natural extension. We did not design Crowbar to be a one-trick pony. It’s modular design makes it easy to extend while leveraging the existing body of work.
Big companies are acting like start-ups. Both Crowbar and Cloud Foundry are projects that focus on putting the core functionality out quickly to prove their value proposition, get feedback, and change the game. This collaboration is positive proof of these companies being Agile and starting a project Lean.
Big companies are acting in the open. Both Dell via Crowbar and VMware via Cloud Foundry are contributing their source and working on it in the open.
Stay tuned for that “how to create a barclamp” post (or check out the barclamp rake task).