DevOps Dawn or Ostrich Posture?

If you’ve followed my blogging here, you know that I’m a special fan of the class of system tools called “DevOps”.  These tools are designed to automate application deployment by transferring information from the development process to a form of template, container, or script, that can then be used to install the application when it’s needed.  BMC software has made an acquisition (VaraLogix) in the DevOps space, adding to its StepStream deal last year.  It’s clear that BMC intends to make this space its own, and important to understand why.

Tactically, DevOps is already an opportunity.  Today’s applications are increasingly deployed as complexes, with layers of applications cooperating.  A typical web-based app, for example, would have a front-end web server, a back-end application server, and a database server.  If there’s component redundancy built in, you can see that the structure gets big fast, and that means that it would be fairly easy to make a mistake in deployment that would send it all crashing down, especially when a failure event tested some thinly-reviewed logic path.

Application integration in the form of worker-specificized GUIs is another area where problems with deployment can already be seen.  In the good old days, you ran an application.  Today, increasingly, you run a screen that’s scraped from a couple of applications.  More and  more, users have GUI-integrated views of apps that are assembled from exercising functional APIs and not application-specific GUIs at all.

The best part of DevOps, though, is that it plays to the broadest mission for the cloud.  Whatever issues exist in deploying applications on static servers in data centers, they pale by comparison to deployments in the cloud.  Add in hybridization, application integration across the public/private boundary, failover public cloud services, and you have a formula for something that no one will ever get right if it’s done manually.  But even that’s not the end.

We’re about to launch ourselves into the age of composable applications and experiences, a period when the whole notion of what an application is shifts from static to dynamic.  This change, which makes “provisioning” and “orchestration” of components two sides of the same coin, takes us forever out of the world of manual deployments.  BMC is smart; they’re taking a lead in a race that most of their competitors don’t even know is being run.

Then there’s the fact that there simply isn’t any logical way to address network connectivity in a dynamic cloud other than to presume that provisioning resources includes provisioning network resources.  OpenStack makes that explicit assumption, for example.  However, I also think that you can’t presume that applications themselves are the “software” in “software defined networking”.  It’s anarchy to let everyone serve themselves at the connectivity counter without mediation.  At the least, what you do to deploy apps has to be reflected in the connectivity of the application system as a whole.  DevOps software, then, is the “software” in SDN.  That might give BMC an enormous leg up in the world of SDNs.

Or not.  The problem is that BMC has never been known particularly for agile DevOps, nor have they been known for flexible DevOps thinking.  Their release on their VaraLogix deal doesn’t anchor things to the cloud at all, and it’s hard to see why the company would waste the bully pulpit of the announcement not to trumpet their superior strategy…if they knew they had one.

What this says is that BMC (like, let’s face it, so many market leaders today) is focusing on the purely tactical and ignoring the real trends driving DevOps from a backwater scripting activity to the mainstream of the cloud and SDN.  If it is, then competitors might now pick up some other startups and run away with a market that BMC could have owned.  If that happens, I sure hope that others in the software and networking space take note.  BMC isn’t the only playing ostrich at the market zoo.

 

Leave a Reply