The Consumerization of IT: The OpsStore

Tablets, smart phones and emerging mobile devices with instant access to applications are impacting the way in which IT provides services and developers architect applications.

When pundits talk about the consumerization of IT they’re mostly referring to the ability of IT consumers, i.e. application developers and business stakeholders, to provision and manage, on demand, certain IT resources, most usually that of applications. There’s no doubt that the task of provisioning the hardware and software resources for an application is not only tedious but time-consuming and that it can easily – using virtualization and cloud computing technologies – be enabled with a self-service interface. Consumers, however, are demanding even more and some have begun to speculate on the existence of “app stores” within IT; a catalog of application resources available to consumers through a “so easy my five-year old can do it” interface.

Unfortunately, such systems always seem to lay upon the surface. It’s putting lipstick on a pig: the pig is still there and, like the eight-hundred pound gorilla, demands attention. The infrastructure responsible for delivering and securing the applications so readily available in such “enterprise app stores” are lagging far behind in terms of the ability to also be automatically and easily provisioned, configured and managed. What we need is an Ops Store.

IT as a SERVICE

Cloud computing environments, specifically IaaS, have gone about half-way toward creating the Ops Store necessary to complete the consumerization of IT and enable IT as a Service. Consider the relative ease with which one can provision load balancing services using most cloud computing environments today. Using third-party cloud computing provisioning and management frameworks, such processes are made even simpler, with many affording the point-and-click style of deployment required to be worthy of the moniker “on-demand” and “self-service.”

But in the enterprise, such systems still lag behind the application layer. Devops continues to focus primarily on the automation of configuration; on scripts and recipes that reduce the time to deploy an application and create a repeatable deployment experience that takes much of the guess-work and checkbox task management previously required to achieve a successful deployment. But in terms of providing an “ops store”, a simple, self-service point and click “so easy my five year old can do it” interface to such processes, we are still waiting.

But these automations are still primarily focused on topology and configuration of the basics, not on the means by which configuration and policies can be easily created, tested and deployed by the people responsible: developers and business stakeholders. Developers end up duplicating many infrastructure-related services – security, performance, etc… – not because they think they know better (although that is certainly sometimes the case) but because they have no means of integrating existing infrastructure services during the development process. It’s not that they don’t want to, they often aren’t even aware they exist and even if they are, they can’t easily integrate them with the application they are developing. And because ultimately the developer is responsible to the business stakeholder for the application, the developer is not about to abrogate that responsibility in favor of some unknown, untestable infrastructure service that will be “incorporated during deployment.” Anyone who’s sat through a user acceptance meeting for an application knows that the business stakeholders expect the application to work as expected when they test it, not later in production. It’s a Catch-22, actually, as the application can’t move to production from QA until it’s accepted by the business stakeholder who won’t accept it until it meets all requirements. If one of those requirements is, say, encryption of sensitive data then it had better be encrypted at the time the stakeholders test the application for acceptance. If it’s not, the application is not ready to move to production. The developer must provide all functionality and incorporate all services necessary to meet business requirements into the application before it’s accepted.

That means operational services provided by the infrastructure must be available to developers at the time the application is being developed, particularly for those services that impact the way in which data might be handled. Identity and access management services, for example, are critical during development to ensure that the application behavior respects and adheres to access policies.

In a DevOps world, the operations team provides infrastructure as a service to product teams, such as the ability to spin up production-like environments on demand for testing and release purposes, and manage them programmatically. [emphasis added]
-- Tired of Playing Ping Pong with Dev, QA and Ops? (CIO Update, May 2011)

Developers need a way to manage infrastructures services programmatically; an “Ops Store”, if you will, that enables them to take advantage of infrastructure services.

NEEDED: INFRASTRUCTURE DEVELOPERS

While it “would be nice” if an Ops Store was a simple to navigate and use as a existing consumer-oriented application stores. But that’s not reasonable. What is, reasonable, however is to expect that a catalog of services is provided such that not only can developers provision such services but that they can subsequently configure and invoke them during development. It seems logical that such services would be provided by means of some sort of operational API, whether SOAP or REST-based. But more important than how is that they are provided; made accessible to the developers who need them to incorporate such services as required into the broadening definition of an “application.”

It is not likely to be operational-minded folks that enable such an interface. Unfortunately, devops today is still more concerned with ops than it is development and continues to focus on providing operational automation without much concern for application integration – even though that remains a vital component to enabling IT as a Service and realizing the benefits of a truly dynamic data center. This concern will likely be left to a new role, one that has yet to truly emerge in the enterprise: infrastructure developer. One that understands how developers interface and integrate with services, in general, and can subsequently provide the operational services in a form more usable to developers, closer to an “ops store” than an installation script.

While scripting and pre-execution automated configuration systems are great for deployment, they’re not necessarily well-suited for on-demand modification and application of delivery and access policies. There are situations in which an application is aware that “something” needs to be done but it can’t do it because of its topological location. The delivery infrastructure, however, can. Consider that the dynamic nature of applications is such that it is often the case only the application, at execution time, knows the content and size of a particular response. Consider, too, that it may also recognize that the user is a “premium” member and therefore is guaranteed “higher performance.” The application developer should be able to put 2 and 2 together and instruct the infrastructure in such a way as to leverage whatever delivery policies might enable the fulfillment of that guarantee. But today there’s a disconnect. The developer, even if aware, can’t necessarily enable that collaboration because the operational automation today focuses on deployment, not execution. Developers need the means by which they can enable applications to be more contextually aware of their environment and provide actionable data to infrastructure regarding how any given response should be treated.

If we’re going to go down the path of consumerization and take advantage of the operational efficiencies afforded by cloud and service-oriented concepts, eventually the existence of Infrastructure 2.0 enabled components has to be recognized and then leveraged in the form of services that can be invoked from within the application. That will take developers, not operations, because of the nature of that integration.