Three Paths to DevOps

3-Paths, by Thom Dougherty

It’s impossible to map out a route to your destination if you don’t know where you’re starting from.- Suze Orman

DevOps is about the relationship between software development and software operations — the path from idea to code to deployment. It is about the development of the application, and the development of the operational processes and environment.

There are three paths to the reality of a DevOps implementation.

The first path is creating a new application, while simultaneously creating its operational processes. This is in many ways ideal.

The second path is creating a new application, to be deployed using an existing environment and processes.

The third path is creating a new “DevOps” process for an existing legacy application.

The first path: New application, new environment

In most ways, this is the ideal situation. Development of application(s), continuous delivery pipelines, and deployment environments can happen in concert, using Agile processes.

It’s not necessarily all fun and games this way, though. The way can be fraught with peril. First, there are the hazards of new technologies. This circumstance is often the result of a greenfield project, often involving new project management approaches as well as new technologies. If the team hasn’t used the new tools before, they have a learning curve and potential pitfalls (which can be made worse by the rapidly evolving, poorly documented nature of many DevOps tools). Alternately, the team might be relying on new hires or consultants for technical expertise, people who don’t always understand (or respect) the corporate culture. New technologies, new risks.

The second path: new application, existing environment

Again, this has its advantages and disadvantages. The key advantage is risk reduction. The operational environment is a known, tested quantity. And if the new application is being developed by the same team as previous applications, it can be very straightforward. Still, it’s not always easy. A new team, or a team with aggressive new developers, can push for new technologies that don’t fit well into the existing environment. Or worse, a new application may be forced to fit into a straitjacket of previous constraints — a lava flow of “that’s how we’ve been doing it”.

The third path: legacy application, new environment

This can be the scariest path — moving a legacy application from a comfortable but problematic legacy operational environment to a new, modern, DevOps world. This can be very difficult. Management processes can be manual, undocumented, full of secrets and surprises. Older team members may fear or resist change. Legacy apps can depend on middleware that is difficult to automate, requiring either difficult shoehorning, or modifying the application to use more modern middleware. Data can be very difficult to move. This situation is often forced on teams from the outside, creating bureaucratic friction and resentment within the organization.

Sharks gotta swim

Conventional wisdom tells us that sharks have to keep swimming, or they will die from a lack of oxygen. This is a good metaphor for software. It can’t stay in one place forever, or it will drown.

Understanding how applications and their environments are created and evolve over time helps us recognize the risks before we find out about them the hard way…