Enabling continuous improvement with managed DevOps services

If everything you do is in the cloud based, life is easy. All your applications, systems and infrastructure are designed to work with each other. You write the code once and deploy it, and the infrastructure itself is generally self-scaling and self-governing. Code changes are managed by a source code management (SCM) repository like GitHub, GitLab, Bitbucket or Azure Repos. A CI/CD pipeline such as GitHub Actions, Jenkins, or Azure DevOps smoothly deploys your apps into production.

If that’s the case, thanks for making it this far. This is probably not the blog you need.

However, if you have a combination of new and older systems, cloud and older infrastructure, or new and old applications, keep reading.

The trouble with DevOps in a two-speed enterprise

Keeping track of the changes to a brand-new application is hard enough. Once you have built a functional version, it needs to be sent for performance testing, regression testing, integration testing, security testing and more. Every bug or vulnerability needs to be fixed, and every application change adds a new layer of complexity.

Developers keep track of and manage all this complexity with a branching strategy, a model that tracks the different versions of the code and how it has changed from the original. There are many different approaches, but at its core, the purpose of the branching strategy is to identify the version most suitable for deployment into production or other environments like development, testing or acceptance.

If the application you are working on is older or interfaces with older systems, any changes to functionality will cascade to both new and older systems, prompting changes to code, software, hardware and networking.

Every environment and every set of applications touched by new code and new functionality adds another layer of complexity which can quickly overwhelm you. Keeping track of this complexity can become unmanageable — and the impacts of changes can be far reaching.

You may have a DevOps team working on your new applications, but if your infrastructure is not fully modernized, you couldn’t possibly have enough staff to keep track of all the different impacts that a code change will have. Similarly, every change has its own potential security implications that must be addressed.

So, what’s the solution?

Evaluating different enterprise DevOps options

Theoretically, you could create separate DevOps teams: one for new development and another to handle your legacy applications. Unfortunately, this is an inefficient and costly approach. There will be a high-level of skills duplication, and staffing up to handle big rollouts will leave you with a lot of high-priced specialists sitting around with not much to do between releases.

You could also try to modernize your entire IT portfolio, moving everything to the cloud and containers to ensure traceability, scalability and easy deployment of new features. However, with thousands of applications and huge costs involved, this is not feasible or sustainable either.

Now imagine that your CI/CD pipeline is humming smoothly, no matter whether the app is fully cloud-based or if it touches legacy applications, databases or infrastructure. What if security threats could be swiftly addressed, and deployment issues became a thing of the past?