Approaching Legacy Environment Management with DevOps

This is a guest post by Tim Driggers (@timdriggers)

Moving to DevOps? Buyoff from the business? Teams bought in?

Angels are singing, Unicorns are dancing, and the stars are aligning.

You have no doubt already built a roadmap to your DevOps implementation; have projects lined up and are working on new team processes and interactions.

You’re thinking of your new DevOps team as managing new projects and releases, but what is your plan for managing the legacy environment? I had similar thoughts and had to manage through them in order to successfully implement DevOps.

This post is not about moving forward, but recognizing what is behind you – what you have bulit and how you are going to continue to manage it within the framework that you have defined as ‘DevOps’.

What about the application that was written four years ago, you know the one – it’s monolithic and not documented. One ops guy knows how to manage it. A few developers touch it when necessary. The cost of management is high, the business isn’t willing to put money into it and it’s vital for the company.

Dr. Emmett Brown: What on Earth’s this thing I’m wearing?
Marty McFly: Ah, this, this is a radiation suit.
Dr. Emmett Brown: Radiation suit? Of course, because of all the fallout from the atomic wars.

People make up their own history.

It’s best to not worry about why something was done. Stop talking about who did it. As matter-of-factly as possible, change your culture to talk about The Present and Future.

Matthias Marschall on enabling a DevOps culture in October:

Stop the blaming game. Don’t introduce audits and SLAs just to be able to blame someone if something fails. Instead, use them to communicate expectations and results of discussions. Only if you share responsibilities for code quality as well as operations metrics like speed or availability, can you work more productively.

Matthias was talking about embracing your team and moving forward, but I want you to apply this to your legacy infrastructure. How?

When i sit down with my teams, I talk about the big three: Humility, Ownership and Commitment. I believe these are a basis by which all tactical aspects of a project or operational environment are managed.

• Humility
  Recognize that your old methodology was inconsistent, created gaps in skill-set and lacked accountability. Admitting that mistakes were made out of business need (speed, resources, etc) puts the team on a level field.
• Ownership
  Define ownership of legacy services or applications. Teams that feel ownership and responsibility tend to drive solutions that make sense. If you dont have a DevOps owner, then there is no commitment to quality or accountability on a per-service or app basis.
• Commitment
  Your DevOps team(s) must commit to doing the best they can with the legacy environment. This might mean setting aside points (Agile reference) to go back and determine where gaps are in the legacy environment, as well as business commitment to resolve those gaps.

Giving ownership to the team, and crisply communicating the expectations should allow you to cover legacy environments with your DevOps teams.

Operations

In the real world, this is how I applied it to my DevOps team:
Teams come together for a meeting to discuss legacy applications

• We set ground rules for how we discuss legacy applications – Humility.
• We (as a group) identify legacy applications
• We assign a DevOps team to each application. (You may find a majority of applications end up initially being assigned to a specific developer or operations person. Do your best to break up the load across your teams.)
• I set the Ownership and Commitment expectations (note: after a team takes ownership of an application).
  empower the teams to learn, and document the current state, and management techniques of the legacy app.
• I ask the teams to write stories (Agile reference) around easing management and maintenance of their legacy applications.

My job is to work on getting those stories prioritized within the other backlog items.

My approach is to assign ownership and then methodically back the the team into operational crispness to transform applications or services that are still using traditional methods into more DevOps friendly environments.

No need for a DeLorean or time travel, just a sensible approach to implementing DevOps.

About the author

Tim is a twelve year veteran in System and Network Operations, Information Technology Management and day-to-day technical activities. Currently, Tim is the head of Technology for LexBlog, the world’s premier legal network. He blogs about DevOps at Rooflabs