In IT operations terms, an “application lifecycle” is the series of steps that an application takes from its initial deployment to its eventual withdrawal. Some reflect orderly upgrades to application components, and others respond to changes in how the app is used, to faults in the software, what it runs on, and how it’s connected. All of this stuff seems important, so we must explore why every enterprise isn’t jumping on the lifecycle automation bandwagon.
We’re now hearing that many vendors are looking to apply artificial intelligence (AI) to enterprise application lifecycle management. But are enterprises holding their breath for this revolution? Not the ones I talk with. In fact, the majority say they don’t think they need application lifecycle automation in any form. The contradiction between vendor focus and buyer interest seems to demand some exploration to uncover the truth.
One way to start is to look for what kind of factors might be common among those IT organizations that are happy with what they have. Three patterns come across in my contacts with them. First, they’re already using Kubernetes or a DevOps tool for deployment. Second, their applications consist of stateful components rather than stateless microservices or functions. Finally, their hosting and networking were based on pooled or shared resources such as the cloud or containers.
DevOps and container orchestration handle what’s called “deployment” and “redeployment.” In the cases of my contact enterprises, these mean “loading the application’s components onto hosts” and “reloading stuff that changes,” i.e., where software changes have been made. While there are tools or techniques to expand the redeployment concept to handle replacing things that have failed because of a hardware or network problem, those aren’t seen as major issues so far.
A combination of the second and third truths I uncovered seems to be the reason. Most applications today consist of a relatively small number of static components that run on resource pools that are already supported by management tools aimed at fixing problems. If a resource is broken these users say, “fix it.” Even where there is a value to reloading something that’s running on a failed resource, it’s possible to use a redeployment to fix it, and that can be initiated manually using DevOps or orchestration tools.
We can’t stop here, though. We need to look at what’s different about those enterprises that do think they need lifecycle automation. It turns out there are again three patterns. First, they’re heavy users of hybrid cloud applications. Second, their applications are business-critical and can’t stand even a short outage, and third, they have a large collection of microservices that are shared among applications. Third, they’ve done careful capacity planning to size their resource pools to their business load.
Where companies have a large web retail presence or significantly support remote or mobile workers (including the new work-from-home community), they typically tend to adopt hybrid cloud models, with a cloud front-end to mainstream applications. The needs that drove businesses to this decision continue to drive them to rapid, often massive, changes in the front-end elements.
The web-and-mobile wave also makes some enterprises entirely dependent on the online presentation of information to do business. If a web-based business goes down, there’s no backup pad of manual receipts for a salesperson to write out…you’re out of business. That makes remediation absolutely critical, and so these businesses tend to create capacity pools to ensure they don’t lose customers when they fail or when demand is high. Optimizing the use of these pools is a big driver of interest in lifecycle automation.
The question is how many enterprises fit each of these models? To figure that out, we’ll need a little math. To start with, fully half of all enterprises don’t have a cloud, web, or mobile application model because their business doesn’t have an online or mobile component. For this group of companies, the current deployment and redeployment strategy is fine, so take 50% of companies out of the lifecycle automation camp right away. The absent online or mobile emphasis, existing DevOps, and orchestration tools seem to work fine.
Of the half of companies who remain, about three quarters have already adopted the cloud-and-data-center online or mobile application model. These organizations are solving their operations issues by focusing on the dynamic part of their applications on cloud deployments and using cloud providers’ tools for automating responses to network or hosting failures. After all, that is what the cloud is all about – they don’t need new lifecycle automation either, so strike off another 75%.
That leaves us with a quarter of a half of enterprises, which is about 13%. These are the people who are clamoring for enterprise lifecycle automation, but 13% might be too small a market to justify a lot of vendor interest. That active seeker group sure thinks that’s the case because about a third of that group now believes that unless service providers or cloud providers drive a broader set of application lifecycle automation tools, we’ll never see them at all.
And perhaps that’s OK. We may not be overthinking lifecycle automation, but we’re likely overhyping it. Everything doesn’t have to be automated, and in some cases, automation attempts can introduce more complexity than they resolve. If you’re an enterprise, don’t feel left out if you’re not pushing for application lifecycle automation. You may be just where you need to be.
