IT operations in a cloudy world

Cloud computing and data center virtualization are both changing the way IT operations are organized, and the toolsets sought to automate operations tasks. Recent conversations with a variety of cloud practitioners have reemphasized this for me, and I wanted to lay out what changes I see coming to the operations space, and why those changes are important when considering your future (or your product's future).

A few months ago, I wrote a series of five posts I dubbed the "Big Rethink" series. If you haven't read the series yet, I invite you to do so now. The series basically breaks down the effect of virtualization and cloud computing on IT operations, and looks at how those changes affect data center operators, developers and end users, respectively. I wrapped up the series with several observations about what the future holds based on "the Big Rethink."

I followed that up with a three part series on "DevOps", the term applied to aligning application development with operations automation throughout the developement/deployment/operations lifecycle. In that series, I laid out my argument why IT operations will shift from a server/network/storage model to a more "horizontal" model.

In conversations following those two series of posts, it has become clear to me that I need to clarify exactly how I see those horizontal operations roles evolving, and provide a model for the ownership of various aspects of a "cloudy" IT operations organization. Most of this draws from the previous series, but there are some important nuances that I want to demonstrate in this post.

The first thing that I think is critical to identify is that there are really three elements to IT operations in a world where IT is delivered as a service:

I think of these three categories in the following way:

1. Infrastructure operations (or "InfraOps") is the management of the base physical systems (such as physical servers, networking and storage), and usually the virtualized representations of those resources--though not always, as you'll see below. Included in this infrastructure are the management systems focused on managing resource allocation at the behest of services and applications.

   What is critical to understanding the role of InfaOps is understanding that infrastructure is moving towards a more homogenous model in support of heterogeneous applications and services (a "Big Rethink" concept). If the same core infrastructure is going to host multiple services and applications, it therefore makes sense that a single team of dedicated professionals would watch over that infrastructure, theoretically guaranteeing the ability of that infrastructure to adjust to the demands of its payloads.

2. Service operations (or "ServiceOps") is then the role that focuses on running the services provided on that infrastructure. For example, the ServiceOps team would own the service catalog and service portal environments, and all of the software systems that define and manage the services offered through those systems.

   Why manage services separately from the infrastructure they run on? I usually illustrate this concept with an analogy: think of the data center infrastructure as an iPad, and the services it hosts as "apps." Ultimately, I may move towards a more homogeneous data center infrastructure in support of my services, but I still want a wide ranging choice of service options to select from. Perhaps I build my own infrastructure as a service offering, buy my communications services from a vendor, and my dev/test governance services from another vendor.

   If the data center is hosting multiple services from multiple sources, there will need to be expertise to support the common infrastructure (as mentioned above) and expertise to support each of the services. This means service operations would need to be managed separately from infrastructure operations.

3. Application Operations (or "AppOps") then is the role that manages the applications themselves, assuring that the application has a place to execute, that it is deployed correctly, and that service level requirements are met throughout the life of the application. AppOps typically is the team that is involved in DevOps activities, and is also the most likely role to find itself working with multiple "clouds" (aka IT service providers) at once.

   This is the primary effect of the "Big Rethink" and DevOps: the drive to make the application itself the unit of administration from the application's perspective, rather than the infrastructure on which it runs. To me, this is an exciting change, as it get's application operators out of the business of being "clerks" (e.g. responding to trouble tickets day after day), and into the creative business of architecting, implementing, and maintaining application operations automation.

(For the more technical readers, I should note that today, many so-called "cloud infrastructure" tools tightly couple physical resource allocation to an "infrastructure as a service" software system. The problem I see with that is that it means the infrastructure can only be used with that service offering, or other services that utilize the same management and user interface systems as that offering. I believe that the "service" component of IaaS will eventually be decoupled from the actual infrastructure automation for that reason.)

By the way, some of you may have picked up on a very interesting point that can be derived from this breakdown of operations. The separation of operations roles basically denotes the separation of operations automation systems that should be deployed in an cloud ecosystem; the same three elements are involved:

Now, it will take time for these roles to appear in many organizations, but I find it hard to picture a different breakdown that will allow for (a) maximum flexibility and efficiency in infrastructure usage, and (b) the separation of concerns that come into play when you have an end user consuming a second party service that is running on a third party's infrastructure--a very reasonable model in the world of cloud computing.

I'd love your feedback on this concept. Does it ring true to your organization? Does the "hybrid IT" model I mentioned earlier support this change, or disrupt it? How do you see cloud computing and virtualization affecting your IT organization?