Over the last few months, I've noticed a number of service service providers and enterprises that are building cloud offerings struggling to articulate their offerings, often late in the project.
These are all smart people who've spent months or years planning their cloud project (public and private). They've bought servers, networks, storage, various software (but not self-service) and then are somewhat stumped as to what their packages should be.
They are know the general class of service: infrastructure as a service. They know what the core elements are: computing, network and storage. They know it should be on-demand, but it isn't yet (which is why they are talking to newScale).
Beyond that there's less certainty about what packages to offer, what boundaries those packages have and what to do with all traditional configuration. And they are unsure as to how to enable their customers to order, consume, and configure the offerings.
To use an analogy, they know they'll be selling burgers, but don't know exactly the business model. Are they are going to be like MacDonalds (no change, fixed bundles), Burger King (have it your way), 4 star restaurant (foie gras with rare unicorn cheese) or catering (what kind of food would you like?).
What's missing is the product marketing and product management view to accompany the technical and process views. In other words, someone to figure out who are the customers, what do they want, and what are the competitive offers they need to match and exceed.
In the spirit of helping out, these are my working observations thus far on how to approach a cloud service definition.
First, the service offering should be consistent with accepted customeror competitive market definitions.
This means the offering should match, be like or somewhat like exising offerings from well-known vendors.They should be measured, priced according to common measures that are accepted.
For example, AWS uses VM instances prices which have become the new benchmark so it's not a bad beginning. Others use RAM, or GIgabytes of storage. The whole point is that the offering should be comparable to what's in the market. Doesn't have to be a copy, but roughly comparable. It can't be both a dessert topping and a floor wax.
Recently, I talked to the engineering head of a data center who was convinced the right metric for charging was IOPS (don't ask me) because it was a more accurate picture of customer value. Maybe. But there are no other providers out there offering that metric so going with that metric would result in long sales cycles as the customers tried to figure out comparison models.
As a first step, put your offering on a grid vs a few others. Here's one from a newScale page.
See where your offering matches features of existing offerings. Your offering can't be so unique that you don't play the game, because you'll be out of the game. Check out "What T-Shirt Sizes Taught Me About Cloud Standards" for some ideas on packaging.
Second, extend the Service Offering definiton with unique, value-add differentiators.
Unless you are the lowest cost provider, you need a reason why a customer should choose you. You need features that differentiate you from your competitors and that the customer considers valuable.
The good news is that cloud computing is not going to be a commodity for a long while. For the next few years, there's going to be a fair amount opportunities of innovation and differentiation.
There are differentiation opportunities in service levels, network performance, complementary service offerings, professional services, bundles, security and configurations available. And that's just a list off the top of my head.
As I wrote on "Differentiated Service Levels," just the basic add on service of picking up the phone for support is subject to differentiation. In the case of Amazon it's the difference between Bronze Level at $49/month or Platinum level at $15,000/month.
The network another juicy area for differentiation. As Chris Hoff writes in his blog about the current state of public clouds.
Not supporting multiple virtual interfaces, not supporting multiple IP addresses per instance/VM, not supporting multicast or broadcast capabilities for software-based load balancing (and resiliency of the LB engines themselves)…these are nasty issues that in many cases require wholesale re-engineering of app stacks and push things like resiliency and high availability into uncertain waters.
So there you have a nice list of differentiation just for the network. But don't focus solely on being different and ignore features your competitors tout.
For example, a hosting company started their cloud offering with very strong network and security configurations as their differentiator. This makes a lot of sense, as security is real customer concern.
But the customer also wanted the storage options they saw other vendors. So they had to go back and fill in the basics of their offering and then figure out how to provide a storage self-service interface in record time. Which they did.
Third, your Service Offering needs be delivered via self-service
And this means automation needs to be considered. Which causes the team to look at their processes and... get paralyzed.
The cloud teams tend to have strong technical staff and good process people but don't have any customer experience or product marketing people to help create packages, experiences and guides.
The paralysis sets because all the configurations possibilities look like an overwhelming number of choices. Which they are.
It is the job of product marketing to figure out which packages to offer and which variations to allow. And it's the job of the service catalog tool to enable the self-service configuration, guided shopping experience which results in an order than can delivered automatically.
So in a nutshell, the obstacles to self-service tend to be:
- What packages and how much variability will offer?
- How do we make it "easy" for the customer to select, configure and order?
- How do we automate the back end to maket it automagical for the customer?
- What do we do with all manual steps, API-less firewall, and other stuff we never worried when provisioning was a multi-week process?
If the variability of service offerings is infinite, automation is impossible, but if your offerings are more like Burger King--base models with variability (extra cheese)--then self-service automation becomes very straight-forward.
There are other issues, like the fear of the fat finger aka capacity management. And how to create a compelling end user experience (See "I can mathematically prove you are attractive" for a good tip on that.)
And finally there's a whole bunch of information that needs to be presented to the customer and they are unclear. They need a service portal that mashes up different sources of information, like this:
These are my observation thus far. Service Offerings need to be worked on ahead of time or the hardware is going to sit on that datacenter and not get much utilization for a while. The servers are humming, the hypervisor is working, etc, etc. It's just waiting for an order. May I take your order?
I'll update as I learn more