Reader Workshop In the last article we looked at whether virtualization provided a springboard to that loosely knit set of capability some refer to as 'cloud services'. But, as we've found previously when discussing such topics, cloud is a can of worms (if that's not too much of a mixed metaphor).
So, what is meant by cloud services? As we have said, some elements are not particularly new, but 'cloud' offers an umbrella term to capture the idea that they share the internet as a delivery mechanism. A number of sub-categories are shimmering into some semblance of clarity:
Infrastructure as a Service (IaaS). Discussed previously, IaaS offers a cloud-based substitute for major elements of your IT infrastructure – that is, server and storage hardware, storage. In short, this will be attractive if you are short of space and/or you want to lose the hassle and capital/operational cost impact of owning and maintaining physical boxes.
Platform as a Service (PaaS). In this case 'platform' means an application (as opposed to hardware) platform. This enables you to grab application resources on demand to prototype, test, pilot, etc. It is also handy for deploying externally-facing applications on the web, which potentially require the ability to deal with wildly fluctuating demands.
Software as a Service (SaaS). A cruel but accurate assessment of SaaS is that it has become a fairly meaningless catch-all term for a range of application services, from business application services such as CRM, ERP, to productivity tools, analytics, backup and archiving. You name it, it's all in there.
There are some good things to be had from all of the above. However, from a purely techno-algorithmic perspective there is nothing inherently better about a specific capability being delivered as a cloud service, versus it running on a server in the corner of the office.
In the previous discussion around IaaS, we highlighted a number of reasons why an organization might choose to adopt one mechanism over the other. But a cloud service is just as capable of being badly put together, badly managed or poorly secured as anything we could do ourselves.
This eyes-wide-open starting point helps us see "Cloud" as an option, an additional delivery mechanism for a capability we have decided we need. So, why might we choose it versus keeping a service in-house? Criteria include:
- How well the service can be managed and kept up to date
- Capital and operational costs, including staff training
- Space and power constraints
- Security risks and legal compliance aspects
- Integration requirements with in-house and external systems
- Access to skills and expertise
Some of these points are being used to sell cloud services today, but they can equally apply to in-house capabilities. You may happen to have all the space and power that you need for example, or you may not.
Similarly, you may be fortunate to possess certain skills, or you may find yourselves lacking. Indeed, your IT department and environment might already be organized and delivered in a the same way as an external service provider - in today’s parlance this would equate to an ‘internal cloud’.