When in-house IT wins out over cloud, is that the right question?
There is one thing where I agree with Jonathan; I don’t like cloud zealotry. It’s not “cloud or nothing.” Agreed. However, the reality is somewhat more complex than how it is portrayed in this article. In-house IT addresses where the IT function is located and who manages and operates it, while cloud computing speaks about a way to deliver and consume IT. So, we are on two different fronts here.
Let me come back to something I’ve stated several times in my blogs. We need to be extremely precise with terminology. There are multiple cloud approaches. Three key ones are typically highlighted:
- private
- managed
- public cloud
But particularly in the private cloud there are multiple ways to implement/use the cloud. That is where Jonathan’s in-house IT comes in.
Cloud for the IT department
IT departments spend a lot of time setting up environments to deliver applications to users. Staging servers typically takes 4 to 6 weeks, when the servers are already in house. IT cloud technologies (automated provisioning in particular) can help them speed that process up. I cannot tell you the number of IT departments, and in particular infrastructure teams within those departments, who have the reduction of server provisioning down to one day in their objectives.
This is fundamentally an IaaS play, where you automate the provisioning of the infrastructure on which you will then install the required software environment. Some vendors, including HP, are providing detailed descriptions and automation templates to perform such tasks, making it easier for the IT department to embrace automation and provisioning technologies. HP calls such templates Cloud Maps.
Here is, for example, a template allowing the provisioning of a 5000 user Microsoft Exchange Server 2010 gold tier service. In practice, you provision three virtual client access servers (each with four cores and 8GB memory), two virtual hub transport servers (each with four cores and 4GB memory) and two physical 8core, 32GM memory mailbox servers.
With that, you facilitate the job of the IT department, but to the end-user, there is no real difference. If he wants his mailbox configured, he will have to ask IT to set-up the mailbox within the provisioned environment. Actually, what we do here is provision applications, not services.
So, the fundamental question is whether this can be considered cloud or not? I believe it can, as it ultimately uses virtualization, automation and provisioning technologies. It’s in line with the NIST definition of cloud computing: “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”
Does it take full advantage of cloud? Actually no, as it does not allow the end-user to initiate the direct provisioning of the services he needs. I believe this is what Jonathan describes as in-house IT.
Cloud for the end-user
Whether using a private, managed or public cloud, the end-user may want to provision anything like a mailbox, a small SharePoint site, access to the enterprise salesforce.com, social media analytics tools, etc. He’d like to do this at the click of a button, in the same way he chooses his mobile applications in an apps store. You may argue he first needs to get approval prior to being able to claim such access. Sure, that can be part of the provisioning process. The fundamental difference is that the end-user is now leading the charge.
And obviously, the user may happen to be the 5001st requestor of a mailbox and that implies a new Microsoft Exchange Server which needs to be provisioned (to stick to the above example). IT may need to give its green light in that case prior the new environment being provisioned. The template described above will be used. But the main difference is that things are triggered from a request for a service initiated by an end-user.
You may argue you always want to keep a buffer of 200 mailboxes in case. Well then, when user 4801 requests a mailbox, the provisioning of a new server is initiated. Whether the requesting user ends up on the “old” environment or on the new one depends the way IT set-up the automation workflows.
Starting from a “service” thinking rather than an “application” one changes the way IT is performed. Increasingly (and BYOD will actually fuel that) service thinking will become the norm for new applications.
Cloud is not one size fits all
The third element I want to raise is that I believe looking at in-house IT or cloud is the wrong question. Indeed, cloud is not one size fits all. There are a number of applications whose consumption is quite stable that may be easier and cheaper to run in a traditional environment, not even going for an IT oriented cloud. Other applications, with highly variable consumption levels, are better off in cloud based environments where additional resources can be provisioned quickly and de-provisioned when not required.
Last but not least, business users will use external tools to perform specific functions. They will consume services delivered by external providers. What the IT department may want to do is take this under their control by allowing the users to consume these services right from their main portal. Using tools such as an enterprise service broker, are ideal for this. End-users will consume “shadow-IT” not for the stake of it, but because they do not get the services they expect from their IT department. So, starting from the needed services and identifying the best environment to run each of them provides IT not only with a way to ensure information technology is consumed in a secure and compliant manner, but also with the possibility to demonstrate to the business they can address their needs.
Conclusion
Jonathan differentiates between in-house IT and cloud. I assume in this context, cloud means public cloud. I hope I demonstrated to you it’s not an either or, but that both should co-exist together. For the forcible future, larger enterprises should combine their traditional environment with private, managed and public clouds to optimize the way they address their needs. In doing so, they will also improve agility while keeping costs under control.
