You Can’t Have IT as a Service Until IT Has Infrastructure as a Service
The underlying premise of delivering information technology “as a service” is that the services exist to be delivered in the first place.
Oh, it’s on now. IT has been served with a declaration of intent and that is to eliminate IT and its associated bottlenecks that are apparently at the heart of a long application deployment lifecycle. Ignoring reality, the concept of IT as a Service in many ways is well-suited to solving both issues (real and perceived) on the business and the IT sides of the house. By making the acquisition and deployment of server infrastructure a self-service process, IT abrogates responsibility for deploying applications. It means if a project is late, business stakeholders can no longer point to the easy scapegoat of IT and must accept accountability.
Or does it?
WHAT does “IT as a SERVICE” MEAN ANYWAY?
We can’t really answer that question until we understand what all this “IT as a Service” hype is about, can we?
The way tech journalists report on “IT as a Service” and its underlying business drivers you’d think the concept is essentially centered on the elimination of IT in general. That’s not the case, not really. On the surface it appears to be, but appearances are only skin deep. What businesses want is a faster provisioning cycle across IT: access, server infrastructure, applications, data. They want “push-button IT”, they want IT as a vending machine with a cornucopia of services available for their use with as little human interaction as possible.
What that all boils down is this: the business stakeholders want efficiency of process.
Eric Knorr of InfoWorld summed it well when he recently wrote in “What the ‘private cloud’ really means”:
Nonetheless, the model of providing commodity services on top of pooled, well-managed virtual resources has legs, because it has the potential to take a big chunk of cost and menial labor out of the IT equation. The lights in the data center will never go out. The drive for greater efficiency, though, has had a dozen names in the history of IT, and the private cloud just happens to be the latest one.
In reality all we’re talking about with “IT as a Service” really is private cloud, but it appears that “IT as a Service” has a strong(er) set of legs upon which to stand primarily because purists and pundits prefer to distinguish between the two. So be it, what you call it is not nearly as important as what it does – or is intended to do.
Interestingly enough, VMware made a huge push for “IT as a Service” at VMworld last month and, in conjunction with that, released a number of product offerings to support the vision of “IT as a Service.” But while there was much brouhaha regarding the flexibility of a virtualized infrastructure there was very little to support the longer vision of “IT as a Service.” It was more “IT as a Bunch of Virtual Machines and Provisioning Services” than anything else. Now, that’s not to say that virtualization of infrastructure doesn’t enable “IT as a Service”; it does in the sense that it makes one piece of the overall concept possible: self-service provisioning. But it does not in any way, shape or form assist in the much larger and complex task of actually enabling the services that need to be provisioned. Even the integration across the application delivery network with the core server infrastructure provisioning services – so necessary to accomplish something like live cloudbursting on-demand – relies upon virtualization only for the server/application resources. The integration to instruct and integrate the application delivery network is accomplished via services, via an API, and whether the underlying form-factor is virtual or iron is completely irrelevant.
IT as a SERVICE REALLY MEANS a SERVICE-ORIENTED OPERATIONAL INFRASTRUCTURE
I’m going to go out on a limb and say that what we’re really doing here is applying the principles of SOA to IT and departmental function. Yeah, I said that. Again.
Take a close look at this diagram and tell me what you see. No, never mind, I’ll tell you what I see: a set of service across the entire IT infrastructure landscape that, when integrated together, form a holistic application deployment and delivery architecture. A service-oriented architecture. And what this whole “IT as a Service” thing is about is really offering up operational processes as a service to business folks. Just as SOA was meant to encapsulate business functions as services when it’s IT being pushed into the service-oriented mold you get operational functions as services: provisioning, metering, migration, scalability.
It’s Infrastructure as a Service, when you get down to it.
In order for IT to be a push-button, self-service, never-talk-to-the-geeks-in-the-basement again organization (which admittedly looks just as good from the other side as a never-talk-to-the-overly-demanding-business-folks again organization) IT not only has to enable provisioning of compute resources suitable for automated billing and management, but it also has to make available the rest of the infrastructure as services that can be (1) provisioned just as easily, (2) managed uniformly, and (3) integrated with some sort of human-readable/configurable policy creation tool that can translate business language, a la “make it faster”, into something that can actually be implemented in the infrastructure, a la “apply an application acceleration policy”. I’m simplifying, of course, but ultimately we really do want it that simply, don’t we? We’ll never get there if we don’t have the services available in the first place.
Sound familiar, SOA architects? Business analysts? It should. A complete application deployment consists of a set of dynamic services that can be provisioned in conjunction with application resources that provide for a unified “application” that is fast, reliable, and secure. A composite “application” that is essentially a mash-up comprised of infrastructure services that enforce application specific policies to meet the requirements of the business stakeholder.
It’s SOA. Pure and simple. And while rapid provisioning is made easier by virtualization of those components, it’s not a necessity. What’s necessary is that the components provide for and are managed through services. Remember, there’s no magical fairy dust that goes along with the hardware/software –> virtual network appliance transformation that suddenly springs forth a set of services like a freaking giant beanstalk out of a magic bean. The components must be enabled to both be and provide services and from those the components can be deployed, configured, integrated, and managed as a service.
WITHOUT the SERVICES IT IS IT as USUAL
If the only services available in this new “IT as a Service” paradigm are provisioning and metering and possibly migration, then IT as a Service does not actually exist. What happens then is the angst of the business regarding the lengthy acquisition cycles for compute resources simply becomes focused on the next phase of the deployment – the network, or the security, or the application delivery components. And as each set of components is servified and made available in the Burger King IT Infrastructure menu, the business will turn its baleful eye on the next set of components..and the next…and the next.
Until there exists an end-to-end set of services for deploying, managing, and migrating applications, “IT as a Service” will not truly exist and the role of IT will remain largely the same – manual configuration, integration, and management of a large and varied set of infrastructure components.
