DIY DevOps: Build, Buy, or Yes?

We are in an era of application capital. That generally means that applications are the most valuable asset an organization owns. But "application" isn't meant just to imply the shiny, gesture-filled glamour apps the business uses to coerce consumers into engagement and consumption. It's also meant to imply the applications that increasingly run the business.

Given that the business is personified in apps, the applications that run the business are, well, more applications. Applications that license and bill, that meter and monitor. Applications that build and deliver the applications consumers can't consume fast enough.

That build and delivery process - that pipeline - is of a critical nature today. It is the assembly line that must be optimized and managed in order to improve the time to value equation used by business to measure success. It's run by software, of course, as is everything today. But the question is, is that software built? Bought?

Perhaps it's both.

You see, no matter what you do, you're going to be building something software. Pipelines are the digital manifestation of process, and process is unique. While every organization likely crafts a pipeline to deploy some of the same components that secure and scale their applications, each of the components itself is somewhat customized. Or should be. Microseconds of latency may be barely a blip on an operational dashboard, but to a consumer, it is a lifetime. The selection of everything from TCP optimizations to where encryption and decryption occur to which scaling algorithm should be used are choices made that must ultimately be put into practice. That means pushing a policy or configuration out to one of the components in your application pipeline.

You will be building something - your pipeline. But that doesn't mean you need to build the actual pipes, themselves. A plethora of build, integration, and test tools exist today that can be used to drive even the most customized process (pipeline). The choice of Jenkins or Chef or Puppet or Ansible as tools isn't nearly as critical as the process and optimizations you put into place with those tools. In fact, you should probably look to standardize on an existing toolset - one in use by developers and DevOps - in order to reduce the burden on the business to maintain custom pipeline software.

Because that's what you'd be doing if you build software to run the pipeline. Scripts, essentially, are a manifestation of this "do it yourself" approach that strings together multiple, disconnected scripts in an attempt to create a workable pipeline. Each of those scripts - each piece of software written - must be vetted, tested, maintained, versioned, reviewed, and more. If you build your own, you're going to be stuck with the operational task of treating it like the software it is. And while you still have some of that responsibility when you buy - or rent, it's greatly reduced when you eliminate all the software development related tasks required to build.

The alternative - going the buy route - enables you to focus on what matters: applications and the pipeline that pushes it out to an eager audience. Standardizing on an existing, supported package means both internal and external resources to help manage, maintain, and monitor that pipeline while freeing up time to craft the right policies that will give the business an edge.

Buy the base: If organizations are struggling to keep up with the backlog of custom applications required to meet and exceed consumer expectations today, it's crazy to think they can simultaneously build out a customized deployment pipeline. There is a robust market of tools that exist already and are probably in use within your organization right now. Buy - or more likely, subscribe - to tools that have a vibrant ecosystem and widespread support.

Build the pipeline: Your process is your pipeline. Just as business processes help dictate the success of the business, so will operational processes dictate the success or failure of deployments. Pipelines are unique, and you can't (or shouldn't) rely on stock policies to determine configuration of security, scale, and speed. Focus on optimizing the pipeline with the right policy and overarching process for maximum success.

Unless you are a startup with a single application that integrates a continuous deliver and deployment pipelines from day one, you'll find it more advantageous to buy the base and build what matters: policy and pipeline.