Continuous Delivery (CD) and all the other continuous things – Continuous Integration (CI), Continuous Testing, Continuous Deployment – have become the new mantra of DevOps. CI/CD adoption typically starts with agile Dev teams working on new or well-funded systems. But what about the rest of the world and all of those “other” applications under-funded IT teams are responsible for supporting? Can or should Continuous Delivery be a reality for all applications?
YES! CONTINUOUS DELIVERY IS FOR EVERY TEAM AND EVERY CHANGE. No application is an island. Every application is subject to change, whether it be code changes, patches to the OS, changes to the supporting databases or changes to the infrastructure it is running on. Without a regulated pipeline to deliver changes quickly across all systems, organizations expose themselves to unforeseen risks and escalating maintenance costs.
No matter how new or well-funded an application is today, it will soon become one of many other applications that have to be secured, patched, updated, and maintained as part of an organization’s IT estate. For example, consider all those “hot-new” Windows IIS sites built in the early 2000s now sitting on Windows Server 2008/R2, which reaches end-of-life on January 14, 2020. Unsupported operating systems are not only costly, but provide prime targets for cyberattacks, (the Bluekeep Vulnerability being just one of many examples).
To Succeed at Continuous Delivery Organizations Must Navigate Complexity
The “J-Curve of Transformation”, included in the “The State of DevOps 2018, Dora Report”, visualizes the challenges large, complex organizations face when automating delivery pipelines. Teams first target high profile projects and quick wins, and then see a drop-off as they’re faced with mounting complexity and technical debt.
Nowhere is complexity and technical debt more relevant than when it comes to mission critical COTS applications, like SAP and Oracle. Manual controls, layers of process, and siloed support teams are all commonly associated with these types of apps. The term “bi-modal” IT is commonly used to describe the variance in delivery processes used for these types of apps vs. custom apps being released as part of Continuous Delivery pipelines.
Not only are COTS apps handled in this “bi-modal” fashion, but there are also the “forgotten” and the “hidden” applications. The forgotten being legacy applications still in use but no longer being actively developed and the hidden being all the applications needed by IT to run IT operations.
Continuous Delivery Challenges: COTS, Forgotten and Hidden Applications
To succeed at Continuous Delivery, organizations need to apply standardization across delivery pipelines for all teams and environments this includes COTS, forgotten, and hidden applications.
Complex: Mission-Critical COTS Applications
Large, mission-critical applications like SAP and Oracle present unique challenges to teams focused on enterprise DevOps, but successful CD pipelines are possible. Teams must first recognize that packaged applications are fundamentally different than custom built applications. There is a great blog post by Shoeb Javed discussing this paradigm shift: “Why DevOps Doesn’t Work for Enterprise Applications”. Similar to older applications (which many packaged applications also are), the fundamental challenge is creating an automated way to build packages that can then be consumed by the pipeline.
Success here also requires additional intelligence about the underpinning proprietary services and technologies supporting the packaged application. Often, this requires curated content and third party expertise. Rizing, a premier SAP consulting firm, is an example of a firm that provides such expertise. At ChefConf 2019, Rizing demonstrated how they were able to install a secure, working SAP S/4HANA environment in an hour.
Forgotten: Legacy Applications
There are a myriad of reasons why older applications present large challenges to organizations trying to achieve Continuous Delivery: technical debt, lack of resources, required refactoring, operating platform dependencies, and a fear of business disruption, to name a few! Updating these apps many times requires individual acts of heroics, involving an abundance of manual efforts in which run books are individually updated, shadow sessions are invoked, and the impact on dependent systems is typically not known until the update hits production.
Getting started with Continuous Delivery requires creating an automated build package that can then be deployed via the pipeline to the preferred destination – cloud, on-premises or hybrid. If the application and all of its dependencies have been successfully abstracted from the underlying operating system and infrastructure, and packaged accordingly, it can be consumed into the pipeline and deployed anywhere without having to refactor or rewrite the application. The Chef Windows Server 2008/R2 Migration program is a great example of how application abstraction can be used to overcome technical debt and create an automated build package that can be consumed and deployed anywhere, all part of an automated Continuous Delivery pipeline, without doing any rewriting or refactoring.
Hidden: IT “Owned” Applications
The “Digital Age” has led to an exponential growth of applications used by the business (Web Sites, Distribution, POS, etc.) as well as third-party applications/tools used by IT teams to build, test, deploy, manage, secure, and monitor those applications. In many cases, these applications have become just as mission-critical as the business applications they’re supporting, but they’re not typically treated as “applications” by the business.
In many cases, they remain completely hidden from the business, with little understanding of the value they provide. Often there is no clear owner for the application, different teams use the application in different ways, updates and patches are handled in an ad-hoc fashion, and expertise is limited to a few individuals within the organization (who take the knowledge about the application with them when they leave).
IT Owned Applications Across the SDLC
Ultimately, third-party applications used by IT need to be managed like any other application. If not, delays in release and production failures, caused by changes not properly tested in pre-prod, will happen.
What Chef does to package Chef Infra with Chef Habitat is a great example of how applications used by operations teams can be packaged for Continuous Delivery.
Continuous Delivery for Every Application!
Continuous Delivery provides the mechanism for delivering and managing all of an organization’s applications at scale. However, getting every application into an automatable, consumable package is not an easy task. This is the challenge Chef Habitat was built to address. To learn more about how Chef Habitat enables Continuous Delivery across all applications watch our webinar “Continuous Delivery: Every Team. Every Change“.
