Apps and ops don't meet--but they will

My CNET column is called Apps Meet Ops for a reason. It's about the time and place where the creative, development side of IT meets the disciplined, operational side of IT.

This isn't to say that there isn't discipline in development, or that there's no creativity in operations. But the gestalt of the apps world is about creating new functionality; writing software that embodies new or updated business logic; making things. The gestalt of the ops side is about building and running infrastructure; managing logistics; keeping things up and running smoothly; operating things. The two zones of activity have sufficiently different motivations, approaches, requirements, and metrics that they've become silos. Indeed, these are the IT silos that--even once all other silos have eroded or fallen--would still stand. Yet they must work increasingly closely together.

Apps meet ops every time a new application or service is deployed, and every time it's patched or updated thereafter. Every time there's a performance test or a requirement to troubleshoot, the two come together. This meeting is the linchpin of getting new IT stuff in production, and of maintaining and updating what's already there. Indeed, it's the linchpin of the entire application/service life cycle. And yet, it's long been a tense meeting in no man's land.

Apps and ops will never be the same--but they are increasingly pulling together. The number of IT services now required, and their ever-growing economic value, mean that apps and ops now meet much more frequently, with many more overlapping responsibilities. Thanks to global commerce and the Internet, more and more apps are networks services--high scale, 24-7 services to boot. You can't build or update such things unless development and operations are working well together. Developers have to build scalability, reliability, and maintainability right into their algorithms; just running them on especially fast or reliable systems is not enough. Operators have to not just build infrastructure, but to carefully tailor it to application requirements. Both groups have to work together to create approaches that mesh well, update after update, at whatever scale point, across multiple deployed services. The strategies of the Googles and Amazons are replete with such converged apps-plus-ops thinking.

Virtualization is another key driver, especially within enterprises whose primary business isn't selling network services. Within the last five years, IT has shifted from a "we might virtualize, some things, very carefully" to "we want everything virtualized; if it's not virtual, there'd better be a good reason why not." There are many benefits, including reduced costs and greater flexibility. One implication, however, is that what used to be separate and distinct concerns--apps, servers, storage, networks, security, and configuration/change management to name a few--are pushed close together, even interwoven.

Apps truly meeting and working with ops requires even new approaches and tools. The much-discussed idea of adding a "deploy to cloud" button to developers' tools is a good example--a direct link from the developer to code deployed on infrastructure. But starting up an app is just the beginning. It must also be monitored, managed, stapled, stamped, and spindled.

Today, VMware has probably the largest arsenal of hybrid apps/ops tools. Examples include Lab Manager, AppSpeed, and the PaaS (Platform as a Service) work recently acquired from SpringSource. These become not just "yet another management widget," but core parts of customer IT processes and life cycles. They contribute to VMware having become not the provider of "yet another commodity hypervisor," but rather, a mainstream IT franchise and go-to platform.

Traditional management vendors are not quite as far along. Management by service level, configuration management databases (CMDB), service catalogs, automated provisioning and orchestration--these helpfully up-level "systems management" into "service management." But while they better understand and handle applications, these remain staunchly ops tools, often from firms with limited apps touch-points and assets.

Given their systematic attention to adaptive/dynamic IT, HP, IBM, and Microsoft have more motivation and opportunity. But they haven't quite gotten off the dime. Because they sell both development and management tools, IBM and Microsoft are especially natural contenders. But they are still percolating. IBM is the most likely, given its enterprise customers and process orientation, so I recently asked the head of IBM Rational application development arm (Danny Sabbah), the head of its Tivoli operational management arm (Al Zollar), the head of its System Software arm (Helene Armitage), and Tivoli's CTO (IBM Fellow Dave Lindquist) about this intersection; their answers point to some interesting pieces and research that might find its way into future products, but few currently shipping tools that converge apps and ops.

While the traditional vendor set isn't quite there yet, make no mistake: Apps Meet Ops is the direction everyone must follow. The ever-growing number of IT services, their ever-increasing service level objectives, and their ever-growing economic value demands it. If apps and ops don't meet comfortably and play together nicely, the hard silos and throw-it-over-the-wall mentality will be a hurdle to both dynamic IT and IT at scale. Platforms on which apps and ops can and do meet will be simply more efficient, reliable, scalable, flexible, and effective than those in which they remain tensely separated, disjoint concerns. IT shops in which they meet will similarly be more effective. So if your apps aren't currently meeting your ops, now's the time: Get with the program!