The Simple Guide to Back-Porting DevOps

You could never accuse IT of standing still. Slow and bulky software projects are history, while the infrastructure is infinitely more available than five years ago—and it’s codified for consistency. The bottleneck has moved on. Today, one key area that slows us all down is the trusted process developed through years of working practices and experience.

Bottleneck or not, the fire hose is still on enterprise IT. This blog explores your existing process assets and liabilities, and recommends a course of action for mapping enterprise applications to DevOps.

Let’s start by looking at how IT has evolved in recent years to move at the speed of Agile. The seeds were sown in 2001, with the launch of The Manifesto for Agile Software Development. This promised individuals and interactions over processes and tools, working software over comprehensive documentation, and customer collaboration over contract negotiation. In 2008, the Hudson continuous integration (CI) tool arrived, offering even greater speed and ease of use. And by 2012, we were seeing the emergence (and subsequent widespread adoption of) virtualization.

The Web era brought us young, hungry unicorn organizations like Twitter, Uber, YouTube and Airbnb—often born out of two guys in a garage. These companies weren’t saddled with 40 years of legacy technology and were eager to embrace the Agile methodology. Some were born with it. Their innovations, intelligence and limited legacy contributed to some of the most popular DevOps technologies and tools we use today. The emergence of Infrastructure as Code from 2010 onwards—think Puppet, Chef, and SaltStack for example—all enabled even faster innovation and DevOps growth and we are even now seeing the next wave of agility rise in the form of containers and micro-architectures.

Against this backdrop, we have enterprises stuck with 30, 40, or more years of legacy infrastructure. These companies rely on interdependent applications that have been tightly coupled together over years of development and business acquisition activity. In these types of applications multiple technologies are tied together, different teams work across different geographies, and there are strong interdependencies and strict rules and regulations.

Enterprises stuck with legacy infrastructure need to take action on their development strategy. Complexity is through the roof and will continue to grow as the number of technologies, servers, devices and integrations expand. The consumerization of IT continues to push customer expectations higher. And in the context of applications, development processes have risen, while delivery time expectations have fallen.

The Process Alternatives

So how can you map those legacy enterprise applications to Agile and DevOps—and cope with the fire hose of demand for new apps? Well, there’s three back-porting alternatives to choose from.

1. Rewrite the Application

I can't be serious... can I? Well, if the app is relatively small and simple it can sometimes make sense to re-write or re-architect it. But usually this is not a feasible option for large, mission critical applications and legacy systems. Rewriting is expensive, takes time, is fraught with risk, disruptive to the business, and demands a significant degree of resources--which is why many times this option is taken off the table first

2. Attempt to Codify

You might consider abandoning existing manual and scripted deployment processes and "codify," using Chef, Puppet, SaltStack, or another alternative. The investment required is sometimes on the low-end given open-source alternatives, and the risk is definitely lower than rewriting the application. However, codifying still means an abandonment of existing trusted processes and a re-architecture of the deployment process. Attempting this with large enterprise systems does absorb a huge amount of time, resources and distraction. Moreover, it can be extremely complex and error-prone. Race conditions, transitive dependencies and many other non-trivial examples are abundant, especially when specifically ordered processes and cross-tier synchronization is needed as part of these processes.

3. Automate Existing Processes

By automating existing processes, you gain true control of the complex matrix of applications, releases and environment variations—more quickly and at significantly less risk than the first two alternatives. You benefit from packages and promotion paths, so you can be confident that what is deployed is correct.  Workflows deliver a standard, quality-assured means of deploying changes consistently. And deployment models ensure the correct setting and configurations are applied to each environment.

Through business automation, you can truly start to keep pace with those young, dynamic organizations—the two guys in a garage—not weighed down by years of legacy infrastructure.