Inventory of the Cloud: It’s Just Vapor Without It

Imagine you run a logistics business, complete with warehouses, lorries, ships and cargo aircraft. However, you quickly notice that your customers are completely up in arms. They are saying that it seems to take absolutely forever for deliveries, and even when they eventually are made they often are delivered to the wrong place or are the wrong items. Your staff say they are moving everything as quickly as they can, but there just are not enough hands or vehicles to deal with the demand. They point to some of the warehouses where there are packages stacked high in the parking lot. Just at this point, a critical order from your most important client hits. You realize that not only do you not know where the inventory is, but aren’t even sure where the vehicles to transport it are, or how much capacity each of those vehicles can hold.

There can be no argument that this is an extremely ineffective way to run a logistics business. Logistics requires knowing where everything is at any given time, whether it is product, capacity or capability. A mom-and-pop operation might be able to manage their operation in their head or with intuition, with perhaps only a couple sets of hands that handle a package from beginning to end. As soon as the number of moving parts increases beyond what one can easily see and count, and the number of actors involved increases beyond a small handful, tracking becomes difficult and the business can no longer be managed so informally.

I would argue that a Cloud service provider has exactly the same challenges. A traditional IT house can probably manage a small pile of applications on a few dozen servers with a small handful of people who all know each other. Tracking and managing of rather simple services with a smattering of dependencies can usually be brute forced to resolution by restarting and tweaking various bits. However, the scale and dynamism of Cloud causes the number of dependencies to not only explode, but also becomes impossible for anyone to track the entire constantly changing dependency map in their head.

Much like a logistics company, what is required are means for managing and tracking all forms of inventory as they flow and change throughout the service lifecycle. The first form of inventory are facility capabilities. Logistics requires always knowing the various qualities of warehouses and distribution hubs in logistics. Logistics companies have learned, much like some more advanced Cloud companies, that warehouses and hubs need to flex to the needs of business dynamics. While there will always be some core facilities, large contracts or changes in regulations require the ability to flex capabilities up and down, either through building temporary facilities or stationing container yards in strategic locations. Cloud requires knowing the location, capabilities, as well as real time capacities and environmentals of datacenters. Flexing these sorts of facilities has become increasingly important with the shifting nature of the global economy and regulatory landscape around data protection and taxation.

The second form of inventory are those capabilities of the workhorses of each of the respective industries. In logistics this would be the lorries, ships and aircraft. The capabilities, configurations and locations of these assets must be constantly tracked to allow the business to know how best to service their customers, both when the capabilities are available as well as when they are carrying customer product. Missing a lorry with refrigeration capabilities in a particular location could mean the difference between whether or not a product is delivered fresh. If a ship rather than an aircraft is available, delivery speed is compromised in exchange for bulk. In Cloud, this second form of inventory would be the servers, virtual machines, networks, and storage. Without understanding and constantly tracking at this level could hinder an organisation from maximizing its capabilities, or worse lead to service failure.

The third form of inventory are the actual packages themselves. Whether this is a physical package as in logistics, or a software package and its configuration in the Cloud, these are both in fact little more than mechanisms that are dynamically configured to handle the actual items that the customer cares about. The contents of a single package can be meaningful in itself, or only useful when bundled with other packages of relevant components. They come in all sorts of configurations, though standards exist in both industries (albeit much more nascent in IT) and are preferred. The quality and knowledge of those configurations, as well as the attributes attached to the package, whether in a shipping label or a software configuration, will heavily determine the level of success or failure of the job from the customer’s perspective. The customer can manage the quality of service through paying for higher or lower service levels, and can prioritize more important things over the less important.

All this might sound like a bit of a stretched metaphor, but there is one other detail that these two industries share. Both these industries look to heavily track and tune all of these forms of inventory, and their optimisation throughout the system is absolutely key for success. However, while the customer might be curious about the details of the inventory, and may even have a hand in creating and managing the package, none of these things is what is perceived as the actual thing of value to the end customer. In fact, the customer only cares that the service was delivered on time, at an acceptable price point, with the quality and security that they would expect. Both industries must never lose sight of this, but all the same they must know that inventory configuration management are their means for managing the service.

Cloud Doesn’t Necessarily Mean a Hypervisor is Involved

I spend a lot of time speaking with customers, vendors, analysts, and "cloud providers" about IT Cloud services. It never ceases to amaze me how many equate Cloud with a guest Operating System running under a VMWare or Xen hypervisor. This incredibly narrow view not only entirely misses the point of Cloud, but focuses on a particular instantiation that has an incredibly low barrier to entry into the market.

Let me provide an example from another field that most people would understand: transportation. Imagine you were to describe transportation. You might talk about moving people and/or things, individually or together, long or short distances, fast or slow, by air, ground and/or water. You might cover some of the various methods, like cars versus trains, ships versus barges, helicopters versus fixed wing aircraft; or the ways that they are powered, like petrol versus coal versus diesel versus wind or some such. All are valid ways to describe such a topic. One might argue that focusing in on any one segment could hinder your understanding of the topic.

Say that people started to equate transportation with a petrol powered bus, not only ignoring but eliminating all the other options out there. Immediately there would be problems. Some people would complain that a bus doesn’t help them easily move things that are not people, and that transportation must be a bad thing because sometimes buses get overcrowded, too slow, or don’t go where they want to go. Companies start labelling themselves “transportation leaders”, because they too can easily go out and get a bus and a driver, and add their own pinstriping or unique seats to their offering. Potential customers start to roll their eyes and say “transportation was so yesterday” because they too dabbled with buying their own bus but couldn’t see what all the excitement was about when they packed their employees in and out of it.

This might sound silly, and so does equating Cloud with a hypervisor. Cloud is the ability to consume a service, whether it is a simple infrastructure service like an OS on a hypervisor, or a much more complex one like CRM or billing, that a person or company can consume on demand (i.e.- as soon as one wants it, like electricity or telephony) as much or as little as they want, when they want it, and know that it will work predictably within certain service level thresholds (electricity will be there, with the right wattage; bandwidth will be there with the right agreed throughput with acceptable interference and uptime). The power really comes from the speed, cost, and flexibility that those services can be provided. It needs to be as easy to build out one’s back office by simply going to a web page with a credit card and selecting where your customer information is (say, in Salesforce), tying it to logistics information (provided, say, by UPS) and accounts receivable (provided, say, by HSBC), into billing, inventory, and integration platforms that can flex as demand shrinks or grows. It should also be easy to immediately select and provision IT and telephony items for a new office, as well as creating and rapidly resizing a new web presence in a far flung market to support the waxing and waning of new marketing campaigns.

A guest operating system under a hypervisor can provide some of these capabilities, much like a petrol powered bus can provide some transportation capabilities. Cloud is far more than that.