March 23, 2018

The Top 5 DevOps Hurdles for Legacy Applications

Version Control

Despite the rapid pace of technological change, many enterprises still rely on legacy systems. Many legacy applications are running on old operating systems, even some that are no longer supported. Over time, they become fragile and require manual fixes and workarounds. This can drain resources, introduce security vulnerabilities, and degrade customer satisfaction.

At the most basic level, the efficiency DevOps brings is gained by automation. Instead of operations staff pushing buttons, DevOps professionals write code that pushes the buttons. This automation, in turn, lowers risk because it makes all processes replicable: builds, testing, deployment, monitoring, and even remediation.

The easiest way to implement DevOps is to start with a new project. But if the legacy application is serving thousands of users and running millions of lines of code, most companies can’t just unplug and start over. Luckily, DevOps can help address many of the issues with legacy applications. 

Let’s examine some of the barriers that prevent DevOps success with legacy applications and how they can be overcome.

1. Developers Spend Too Much Time Putting Out Fires

Without extreme vigilance, a legacy team’s resources can be consumed by unplanned work due to outdated technology and planning methodologies. In all too many situations, fixes and feature requests may be poorly defined and hastily implemented, thus requiring rework. This problem is worsened when the most talented developers move off the legacy application to work on new systems.

If the intention is to adopt DevOps, chances are the plan also includes employing Agile methodologies for at least some work.  One common mistake organizations make is sticking to an old software development methodology for the legacy system, while moving to Agile on the new project. This strategy foregoes the benefits Agile can bring to the legacy operation.  It’s best practice to use Agile for all system development.

Go 100% Agile

  • Before working on the unplanned task, determine the business value. If there is no value, then the team should skip the activity.
  • If the task has value, use an agile project management tool to document and track the activity. This way, the team can see the impact and the full-scope of work.
  • A Kanban board is another great tool for prioritizing unplanned work and managing the interdependencies.

2. Data Locked in Silos

Oftentimes legacy systems prevent you from building the latest technology because individual departments have created and managed data in their own applications, databases, and formats. Until recently, there was little incentive to build mechanisms to share or standardize data for the enterprise. Now, it is very common to want to put web or mobile interfaces in front of legacy systems so customers can interact on the terms they’ve become accustomed to.

Because of this, business leaders in many cases are champions of the value in data transparency and are driving department leaders to find solutions for sharing data across the organization. One solution is to build standardized REST APIs and JSON for accessing the data. REST APIs can streamline how teams interact with legacy services and applications by extracting the data from the legacy architecture.

 Share Data Across the Organization

  • Use REST and JSON to allow the legacy system to access the new data source.
  • Remember to carefully plan and manage APIs to ensure the legacy system can handle the new traffic.
  • Consider leveraging the API architecture to make additional data available, such as legacy system KPIs for monitoring.

3. Extremely Long, Manual QA Cycles

Testing of legacy systems is usually manual. As features are added to the legacy system, manual testing efforts increase dramatically. This can slow down the development of new features and new systems.

Overcome this barrier with test automation. Begin by identifying and prioritizing a fundamental set of testing scenarios. Then, build out automated tests for those scenarios identified as top priorities. This will become a new regression test suite. You should implement CI for your legacy application, and as part of that process configure your version control system and build runners to execute tests with each build. When defects are identified and remediated, add them as new test cases. If new features are added, then script new test cases as they are built and similarly add them to the regression tests.

Automate Testing and QA

  • Identify and prioritize a set of testing scenarios.
  • Create automated tests and configure your version control system to run them with each build.
  • If you can, create a testing architecture using REST APIs. While this is hard with some legacy architectures, if done right it could provide better code coverage and align better with Agile methodologies.

4. Old School Infrastructure

Too often, legacy applications are tightly coupled with the underlying infrastructure. This makes it difficult and risky to upgrade components of an application individually. Therefore, even small changes require testing. Executing the testing requires the constant maintenance of a large-scale testing environment. This can be incredibly difficult, expensive, and time-consuming.

Solve this challenge by giving teams the tools and permission to build their own “self-service” infrastructure. This is the reason so many enterprise technology teams have made the move to Infrastructure as Code, either on-premises or in the cloud. While not all legacy applications can be easily migrated to this kind of new environment, many can.  The primary effort in solving this challenge is two-fold: convincing business leaders to invest in new tools and determining the strategy for upgrading the application infrastructure.

Equip Teams With Modern Infrastructure Tools

  • Implement a robust virtualization environment to support dev and test
  • Identify and provide teams with Infrastructure as Code tools
  • Allow teams to deploy their own “self-service” infrastructure as needed

5. Culture

If the decision is made to adopt DevOps, then the whole organization must embrace it. Why is this a challenge?  Because DevOps is not about collaboration between departments. It’s about two formerly separate disciplines becoming one. Some people will have a difficult time with this transition.  The day to day activities of teams will change. Some people won’t like this and will fight the change.

Similar to enterprise adoption of Agile methodologies, you will not achieve the benefits of DevOps without a lot of hard work. Investments will need to be allocated to new tools, and time will have to be set aside for learning. Communication will need to be enhanced. Developers will need to attend Meetups to network and hear best practices. If SharePoint is your only departmental interaction tool, you’ll need to setup Wikis and get Slack. It will be a lot of fun along the way, but there will be some pain.  Embrace it. It’s unicorns and rainbows when you get to the other side.

Create a DevOps Culture

  • Invest in tools, such as Slack, to support cross-departmental engagement and interaction.
  • Allocate time for training to ensure everyone understands their new role.
  • Foster open communication and collaboration.

DevOps Is Possible With Legacy Applications

As you can see, legacy applications and DevOps aren’t mutually exclusive. While it certainly requires some workarounds, creativity, and hard work, organizations that still rely on legacy applications can achieve DevOps. Did I miss an important point about how to avoid the pitfalls of legacy applications in the quest to scale DevOps? If so, please email me or reach out on Twitter.

Want to Scale DevOps to the Enterprise?