Since the dawn of the computer era complex hardware and software systems have been plagued by a fatal shortcoming that leaves them far less effective than they might have otherwise have been. The designers of these systems often failed to develop them with a critical feature in mind – Management. Management as a feature you might ask? Indeed it is and yet it’s always the feature last thought of. It’s no surprise then that users complain about the management capabilities of most complex systems’ so called management products.
The Management of a thing is often more costly and complex than the thing itself, yet management of any technology that’s worth its weight in tin has always been an afterthought. Why is this and what does it mean for the cloud? In part, management is not well understood so the folks that design systems don’t focus much effort there. But beyond that, management is often thought to be provisioning. Or monitoring. Or security. Rarely is it looked at as a life cycle that encompasses those activities and more.
The result is that management technology has traditionally been bolted on after the product is developed (HP Openview) or rendered so simple as to be difficult to use (SNMP). It almost always ends up as an arcane CLI to cover the basic “management” check box. In an odd way this is understandable. Design teams focus on features – feeds and speeds and other, sexier, line items on the data sheet. They then ship the system and move onto the Next Big Thing. In the meantime customers have to install and operate” the thing” and subsequently have to manage it.
So, left to fend for themselves, they create their own DIY way to manage the technology.
This happens because vendors of “The Next Big Thing” typically have no idea how customers will actually use their products.
About a decade ago customers started asking for “APIs” to interface with the complex systems and, being nothing if not customer focused, the product folks obliged. Unfortunately they still didn’t know how customers used their products so the first generation of APIs where very heavy, complex things that were not very useful. Script controlled CLI lived on.
But a funny thing happened as a result of the IT vendor rush to the cloud. Companies like Rackspace developed their cloud products as if they were going to use it themselves (in fact they do!) and APIs became a significant feature of the product. Good, fast, useful APIs even became part of the definition of what a cloud was! Suddenly, the API as a feature became the API as a product and the API as a service. Rackspace now has a robust, supported, well documented API and is a pioneer in perpetuating APIs via the OpenStack project.
The rise of the API has become critical because it allows customers to use products in ways the vendor never could have imagined. APIs enable a thriving partnership ecosystem like the Rackspace Tools Program so that companies like Smartscale can innovate and rapidly develop feature that customers think up. Smartscale adds value on top of the Rackspace platform so that users don’t have to. But most importantly the Cloud API starts a conversation about what customers really want a product to do and it gives them a way to express their requirements with code.
We have moved from SOAP to Open Flow, baby steps to a brave new world that has seen open religious wars over the importance of API compatibility in the cloud. The power of the cloud comes from the API so we can define the management we want without having to wait for a vendor to update the clunky CLI.
Filed under: Cloud Computing
