A critical factor in leveraging the benefits of DevOps is being able to implement the tooling needed to fully utilize the DevOps cycle in order to quickly respond to business demand/feedback with high quality features/applications in a timely manner. Unfortunately, an issue arises in many organizations that prevents the adoption, or the leveraging of the tooling needed to create this DevOps cycle. The issue revolves around outdated legacy databases/tooling/framework products.
All too often when an organization starts the process of moving to DevOps they discover that they have some type of legacy product that stands in their way of fully adopting DevOps infrastructure tooling, this product could be some commercial product or homegrown product that the organizations has a critical reliance on. The product could be used inside an organization for a myriad of things, business rules, a database, a load balancer or number of other things. This product was most likely put into place during the inception of an application(s) it supports and may or may not have been a smart architectural decision at the time. The reality that the product is now limiting the abilities to adopt desired DevOps infrastructure tooling is known by many involved in the DevOps decisions, the problem is that there doesn’t seem to be an easy and cheap way to replace it. This is actually a false premise that most organizations come up with.