Posted by: Brian Gracely
Remember “Cloud in a Box”? It has come in various iterations over the past 4-5 years:
- “Pre-Defined” or “Pre-Validated” all-in-one racks of equipment
- Hardware Reference Architectures
- Hardware + Software Reference Architectures
- Software-Only Design Docs that are “hardware agnostic”
Lots of vendors or systems integrators have promised to deliver a cloud to their customers in a pre-defined package, but it is typically missing one critical component – OPERATIONS. And when you think about it, the operational model is cloud computing, so it begs the question – are cloud operations transferable?
Recently GigaOm wrote about the latest round of Cloud Providers trying to bring their version of cloud to a new set of customers. Others have tried this or are currently using a similar strategy for both IaaS or PaaS platforms, including Apprenda, Joyent, Rackspace, Virtustream, and VMware (both CloudFoundry and vCloud).
While operations does include elements of technology, the vast majority is driven by people skills and company specific processes. This is why you’ll see cloud pioneers like Netflix open-source many of their internal tools, or Rackspace give up leadership in OpenStack to the OpenStack Community, because their expertise and learning-curve advantages are in the operations of their cloud environments. The AWS APIs are open (documented), but they don’t expose much of their internal operations.
But what makes the operations so difficult to transfer?
Business Models – While there are some cloud providers that have similar business models, the reality is that almost none of them have identical business models. How customers engage with the cloud can vary quite a bit – direct via API; directly through a Service Catalog UI; initially via a Systems Integrator or VAR then via Self Service. Some clouds target developers, some target vertical industries and others target certain sized customers. Understanding how well your “cloud in a box” aligns to the provider’s business model is an important first step.
Onboarding – How does the cloud get the user from the Service Catalog to using the service? Does it have to integrate the cloud platform with existing CRM/Catalog systems, or will it be a greenfield system?
Products/Service Consumption - What are you planning to offer your users? Is it a set of raw services, or bundles with variable sizes, or some mix of ala carte and bundles? Are the products targeted as developers or other types of users? Who is responsible for supporting the service, the cloud provider or the end-user?
Capacity Planning -> Budget Planning - Cloud Providers are able to spread the cost of infrastructure across multiple customers, but what happens when the cloud is for a single company? Have you figured out how to change the budgeting model to spread costs across multiple business-units, or get budgeting that allows for “expandable capacity”, or are you stuck buying hardware &/or software on a project-by-project basis?
Billing – How hard could it be to create a bill? First, make sure you can identify the customer by a unique number that aligns to other systems. Then make sure you can align to a cost-center for the accountants. Next you need to make sure you can bill for both products (setup, dependencies) as well as usage (mins, months, contract terms, etc.). And of course you need to have excellent logging so that you can manage repudiation (those angry customer refuting their bills). And all of this probably needs to link into some sort of payment system, or at least budgeting dashboard so that users and leaders can see billings, chargebacks or showbacks. Pretty simple, huh?
And all of this assumes you have the right skills in place (technology, project management, product management, financial analyst). Not as simple as buying a standardized set of hardware…