For anyone still looking to “get started” with cloud, or anyone seeking to take charge of pre-existing , ad-hoc cloud deployments it’s useful to look at what other IT organizations are doing; with a feel for where the easy successes have come from, where the obstacles lie, and what type of planning you should put forward to optimize your initiative.
In some cases, and this is definitely a more recent and still rare trend, here EMA we have seen CIOs working to integrate cloud with broader business transformation initiatives. What’s more often the case, however, is an executive move to restart or fix “broken” cloud initiatives that began as tactical, random exercises in the data center.
For related articles, please visit Internet.com’s new cloud computing site.
So for starters, let’s look at some use-cases to give you some sense of where pre-existing cloud deployments may already be in place, and where, I think it’s safe to say, toe-in-the water approaches to cloud adoption have been most successful. Towards the end of the list we’ll look at more enterprise-wide adoptions that are in the “least likely” category for now. But just to be clear, this list is descriptive rather than proscriptive and based on data from EMA’s Q1, 2010 report Responible Cloud.
These use-cases are ranked from “most pervasive” to “least pervasive.”
Storage – Storage has been virtualized in some manner for years. So it’s no surprise that it’s a cloud-natural, especially for data that’s not required for dynamic access in time critical applications. Even most cloud related storage providers will tell you clouds are not good for all your data unless you’re indifferent to performance.
Test and development environments – These are probably the most famous examples of early phase cloud deployments and for good reason. They are directed not at true business users, but at application development professionals seeking facile and flexible resources for creating applications. Here cloud is a natural choice. And there are a couple of lessons already to be learned from these deployments.
One is a variant of the 80/20 rule — most developers are happy to get 80 percent of the software/hardware platform requirements they need if they can get it in an hour or so versus five days … or more. A corollary of this is a growing acceptance of standardized platforms with, in some environments, actually a five-to-one or greater reduction in requirements for customization. And finally (believe it or not) application developers are more likely to return systems after use because the waiting period is shorter freeing up unused hardware.
Production Web hosting – At this point we are entering an arena where strict NIST definitions for cloud don’t always apply. Many IT professionals view off-premise Web hosting as cloud, whether or not it leverages a virtualized infrastructure and whether or not it’s strictly billable on a per-usage basis. The bottom line here is that the NIST definitions are secondary to pragmatic decisions about value and use.
Generally speaking, production Web hosting divides into two categories: Public or off-premise is clearly the lion’s share in perceived cloud usage, whether it’s 100% “cloud” or not. The other is in on-premise Web deployments that utilize dynamic, virtualized resources optimized to support variances in demand and activity. Both can be effective (or ineffective) depending on SLAs, on the one hand, and application design and infrastructure requirements on the other hand.
Production database – As it is often tied to application servers and associated middleware, it shouldn’t be a surprise that database came in next based on our research statistics, with similar caveats and adoption criteria to application web hosting.
Specific applications – These often come as unique SaaS packages that probably don’t count as pure NIST-level cloud, but come close enough in terms of flexibility and responsiveness to count. They can also be disruptive offerings that circumvent IT and in some cases still depend in part on IT infrastructures for their delivery. These SaaS intrusions, no matter who brought them in in the first place, should still be visible, defined and understood in terms of SLAs by the IT organization.
Messaging and collaboration – This SaaS capability follows a similar pattern to the above, especially when it’s used within targeted groups within the broader organization. Internal cloud delivery for these applications over virtualized infrastructures should also be considered.
Security services – SaaS solutions targeted at a wide variety of security requirements are already an area of strong growth in the industry.
Order entry/ Sales – Applications for specific marketing and sales processes follow a similar pattern to payroll and HR.
Packaged ERP – As you might expect, business strategic, cross-domain applications are the least likely to have cloud-related deployments, either through external SaaS providers, or through internal, private cloud infrastructures. The risks of moving these applications onto cloud in broader operational environments is high on two counts. First of all there are issues related to far more complex cross-domain interdependencies than any of the above use cases. Secondly, these cross-domain interdependencies are mirrored by challenges in terms of politics, ownership and process. However, this doesn’t mean that over time critical ERP solutions might profit from some of the resiliency and responsiveness that cloud environments can offer.
To be honest, none of this truly answers the question “Where should you begin and why?” But it does offer some useful frames of reference in attacking that question. In my next column I’ll address some of the other pieces of the puzzle relevant to establishing your beginning point: barriers to cloud adoption, base-lining, defining phases and setting metrics.
Dennis Drogseth is VP of Boulder, Colo.-based Enterprise Management Associates, an industry research firm focused on IT management. Dennis can be reached at [email protected].