Usually when a product or service shouts about its low pricing, that’s a bad thing but in Google’s case there’s unique value in its Sustained-use Discounts program which just might make it worth your consideration.
It was five years ago, March 2009, when Cisco formally announced “Project California,” its (possibly intentionally) worst-kept secret, as Cisco Unified Computing System. At the time, I was working at Hewlett Packard, and our collective feelings as we realized that Cisco really did intend to challenge us in the server market were a mixed bag. Some of us were amused at their presumption, others were concerned that there might be something there, since we had odd bits and pieces of intelligence about the former Nuova, the Cisco spin-out/spin-in that developed UCS. Most of us were convinced that they would have trouble running a server business at margins we knew would be substantially lower than their margins in their core switch business. Sitting on top of our shiny, still relatively new HP c-Class BladeSystem, which had overtaken IBM’s BladeCenter as the leading blade product, we were collectively unconcerned, as well as puzzled about Cisco’s decision to upset a nice stable arrangement where IBM, HP and Dell sold possibly a Billion dollars’ worth of Cisco gear between them.
Five years later, HP is still number one in blade server units and revenue, but Cisco appears to be now number two in blades, and closing in on number three world-wide in server sales as well. The numbers are impressive:
· 32,000 net new customers in five years, with 14,000 repeat customers
· Claimed $2 Billion+ annual run-rate
· Order growth rate claimed in “mid-30s” range, probably about three times the growth rate of any competing product line.
I know, more control is an axiom! But the above statement is more often true. When we're talking about configuration control in the public cloud it can be especially true, as control over the configuration of your application can put control in the hands of someone who knows less about the given platform and thus is more likely to get the configuration wrong. Have I fired you up yet? Then you're going to love (or loathe) my latest report, published today.
Let's look at the facts. Your base configuration of an application deployed to the cloud is likely a single VM in a single availability zone without load balancing, redundancy, DR, or a performance guarantee. That's why you demand configuration control so you can address these shortcomings. But how well do you know the cloud platform you are using? Is it better to use their autoscaling service (if they have one) or to bring your own virtual load balancers? How many instances of your VM, in which zones, is best for availability? Would it be better to configure your own database cluster or use their database as a service solution? One answer probably isn't correct — mirroring the configuration of the application as deployed in your corporate virtualization environment. Starting to see my point?
Fact is, more configuration control may just be a bad thing.