Tuesday, October 18, 2011

Cloud Goods And Services

What exactly does the cloud offer to consumers?  Is it goods?  Is it services?  Is it some combination of the two?  The cloud is a unique market — we're seeing compute resources offered as goods but, by their very nature, they're also a service.  Does there exist a means to cleanly separate the two?

Maybe there is no method by which the goods are divorced from the underlying service.  From a marketplace perspective, this introduces a problem for cloud consumers — paying for goods that require a service to make them worthwhile.

External cloud services
Cloud services aren't necessarily tied to one particular cloud provider — they can be cloud provider agnostic.  This is called an external cloud service because it doesn't explicitly require the unique features or capabilities of any one cloud provider.  It's external to both the consumer's organization and the provider's organization.  An external cloud service is really a consulting gig performed by experts.

To get your application off the ground, and into the cloud, you need a team of cloud experts.  The type of companies who employ a permanent cloud virtuoso unit probably haven't been around too long.  Starting a new company today means understanding that must useful technology you're going to want to use inhabits the cloud.  You might want to query cloud data, you might want to store your information there to make it globally available and redundant.  Regardless of what technology you're developing that makes your organization tick, new companies have the advantage of not being hampered by legacy technology that is difficult to migrate and otherwise adapt outside of where it was initially deployed.

Established companies are the inverse — using new cloud technology is difficult because of the investment in local computing power.  Making this stuff work in the cloud isn't easy — or perhaps not even necessary.  But even mature organizations with a rich technology history need to, at some point, develop new technologies that are going to appeal to newer audiences and newer devices and have a broader reach in general.  These companies didn't start off with cloud offerings at the forefront of their IT strategy.

The latter company type — the one that doesn't have cloud ingrained in their day-to-day development efforts are the one who benefit from external cloud services.  The market for such services is only made possible by companies that don't yet have a large stake in this new paradigm.

Migrating applications to the cloud requires knowledge of the cloud technology platform and knowledge of the application.  Without expertise in both, migrating to the cloud doesn't make sense because you're loosing efficiencies that you'd otherwise gain.  In fact, the exercise might even yield a loss if the required overhead in executing the migration runs for an extended period of time.  Additionally, the application that should be running, and the people responsible for it's continued operation can't focus their efforts if a migration is in progress. Seasoned experience is what we're looking for in migrating legacy applications to the cloud.

So what if you're able to take an existing application and successfully move it into the cloud.  Now that you're running on a cloud platform that allows you to scale out, allows you to pay for what you consume, allows you to integrate with new technologies seamlessly, do you still need these external cloud services?  You're in the cloud at this point — is there such a thing as internal cloud services, specific to the unique features your application now has at it's disposal?

Services and goods
You've muscled your way through the barriers of taking an application that's designed to run on legacy hardware.  Or, maybe less iniquitously, applications that weren't designed to take advantage of cloud features.  How do you take advantage of the services that your cloud provider has to offer?  Perhaps a good starting point is to separate the services you're paying for from the goods you're acquiring.

Services internal to the cloud provider are unique features they offer to customers.  As an example, a facility to manage and monitor your resources.  This might come in the form of a user interface, an API, or a combination of the two.  Regardless, this is a must-have feature of any cloud provider if they're going to operate your application.  The differentiation is the quality of the service — which provider has a better facility to maintain the ongoing functionality your your cloud efforts?

Even services that are exclusive to the given cloud provider are still external, to a degree, from the underlying goods.  The goods are the meat of the cloud — the computational resources that you'd otherwise have to purchase, store, and maintain yourself.  This is a whole other department of expertise that we're deferring to the cloud.  Sounds good doesn't it?  We've got our application running on someone else's hardware, they're providing us with the necessary services — their own monitoring and management tools — so that we're able to operate our cloud infrastructure.  And, we're able to consume computing resources as we need them.

So the separation of goods and services appears fairly clear-cut.  Goods — the cpu, the memory, the bandwidth, the storage.  Services — tools to manage and monitor the goods.  The checklist appears complete and we've now got an understanding of how we're saving money by operating in the cloud.  There is, however, one other consideration we should probably make note of — how are we ever going to survive if this provider were to disappear?  Or, maybe we're using a brand name provider that isn't likely to dissolve anytime soon.  But that introduces another potential issue for the cloud consumer — vendors that occupy a large portion of the market have more freedom to introduce changes.  These changes aren't exactly consumer friendly and they highlight how tightly coupled cloud goods and cloud services really are.

Goods are what matters
In the end, you're using cloud technology because it provides access to hardware that you wouldn't otherwise have.  You build your own applications that utilize this hardware, you build it in such a way that it'll scale out and take advantage of new hardware resources should they become necessary.  Everything else is secondary.  Like the services of monitoring and managing your cloud hardware resources — you don't need a fancy user interface, you don't need an API that'll outdo every competitor.  Just the essential services.

With essential services — methods to track what you're consuming and provisioning new resources — you're decoupling the services from the goods.  At the most fundamental level, controlling what hardware is available to your application and when, is what cloud computing is all about.  Everything else is superfluous — useful, maybe, but also limiting.  It might make more sense for organizations to focus in on what really matters instead of on the features the cloud provider offers to keep customers around.  Remember, the cloud is a cloud of clouds — a cloud of providers.

Even this practice — that of decoupling the service from the good is limited in cloud computing because the good being offered is still only virtual.  Underneath the virtual hardware you're purchasing is still an opaque service, responsible for carrying our provision requests.  Even though you can't see the mechanism responsible for generating the goods you need, it is helpful to understand that each provider implements these hidden services differently — some better than others.  So if you can manage to keep your cloud operations abstract enough that they focus on the goods, you're giving yourself enough freedom to explore the entire cloud — not just a subset.  Eventually, you're going to have your own technology, capable of grading goods for what they really are and what their real-wold implications are for your application.