Cloud Hosting

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 its connected. All of this stuff seems important, so we must explore why every enterprise isnt jumping on the lifecycle automation bandwagon.

Were 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 dont 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, theyre 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 whats called deployment and redeployment. In the cases of my contact enterprises, these mean loading the applications 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 arent 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 thats running on a failed resource, its possible to use a redeployment to fix it, and that can be initiated manually using DevOps or orchestration tools.

We cant stop here, though. We need to look at whats different about those enterprises that do think they need lifecycle automation. It turns out there are again three patterns. First, theyre heavy users of hybrid cloud applications. Second, their applications are business-critical and cant stand even a short outage, and third, they have a large collection of microservices that are shared among applications. Third, theyve 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, theres no backup pad of manual receipts for a salesperson to write outyoure out of business. That makes remediation absolutely critical, and so these businesses tend to create capacity pools to ensure they dont 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, well need a little math. To start with, fully half of all enterprises dont have a cloud, web, or mobile application model because their business doesnt 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 dont 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 thats 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, well never see them at all.

And perhaps thats OK. We may not be overthinking lifecycle automation, but were likely overhyping it. Everything doesnt have to be automated, and in some cases, automation attempts can introduce more complexity than they resolve. If youre an enterprise, dont feel left out if youre not pushing for application lifecycle automation. You may be just where you need to be.

Read more:
Are We Overthinking Application Lifecycle Automation? - No Jitter