X
Business

No, enterprise apps should not be left to 'die in their lifecycle'

'There is no single, silver-bullet path to becoming a cloud-forward enterprise. But lost in the discussion is the most important question: what's best for the business?'
Written by Joe McKendrick, Contributing Writer

The following is a response to my recent post, "One-fifth of today's enterprise applications were born in the cloud, surveys suggest," in which an IT executive was quoted as stating that the best way to handle legacy applications is to "let them die in their own lifecycle."

By Wayne Morris, chief marketing officer, Skytap

keyboard-nyc-world-financial-center-photo-by-joe-mckendrick.jpg
Photo: Joe McKendrick

Analyst Joe McKendrick took a close look at two surveys from Capgemini and Cohesive Networks in a recent ZDNet article, and did an outstanding job of capturing his readers' attention early, and better than any survey numbers could have ever done. McKendrick leads his story with the headline, "One-fifth of today's enterprise applications were born in the cloud." And sure, in our tech industry filled with hype and hyperbole, with pundits positioning public clouds like AWS and Azure as panaceas for all corporate apps, one-fifth is a surprisingly small share of apps that can actually use those services.

But that's actually not the most startling statement in Joe's story. It was McKendrick's subhead that should stop you in your tracks: 'Let them die in their own lifecycle': Will on-premises applications simply wither away through gradual attrition?

To be clear, McKendrick asks the question about whether on-premises applications will "wither away," but it was Capgemini who quotes a "vice president of technical services for a US restaurant chain" who claimed, "You're probably better off letting (non-cloud-native applications) die in their own lifecycle."

Non-cloud-native enterprise applications are often depended on heavily, if not entirely, to support an organization's lines of business. These are complex, mission-critical systems with years, maybe decades, of baked-in business intelligence around numerous components, integrations, and millions of dollars invested to do one thing--keep these applications running so the entire business stays running alongside them. These are billing systems, ERP systems, or even healthcare systems that keep a lot more than business alive and well. These investments and dependencies can't simply be abandoned, or ignored to "wither and die." There are too many dependencies on them.

McKendrick is correct in stating: To date, the motis operandi of cloud implementations has been to apply the cloud-first principle to any and all new projects, applications or workloads, while leaving on-premises as is.

Most cloud providers have built their cloud IaaS and PaaS offerings to largely support cloud-native applications--or traditional/legacy applications that have been completely rewritten and rearchitected for their specific cloud. Because of this, many CIOs, App dev, and IT ops leaders have chosen to leave on-premises applications "as-is." Or, in other words, locked in the datacenter, and continuing to receive the lion's share of annual IT spend--a fact that many other surveys will tell you. But this decision isn't being made so that these applications will eventually "die in their own lifecycle"; it's so they'll continue to run reliably, and support the growing number of cloud-native applications they're coupled to.

This is where a problem emerges. Many traditional applications were first developed decades ago, when cloud, mobile, DevOps, continuous delivery, containerization, and microservices were not of mind. And as software delivery teams are tasked with delivering higher quality code faster, they will continue to turn to modern development practices, methodologies, and technologies to assist them with that effort. More cloud-native applications will be developed, these surveys will soon show that even greater percentages of enterprise application portfolios now reside in the cloud. This will create an even larger dichotomy between the pace of development and modernization of newer apps and their monolithic counterparts.

Luckily, there's a solution--and it's not, "wait until these apps become so outdated, problematic, and crippling to innovation that there's no choice but to kill them off." McKendrick recently published a follow-up story, "8 steps to becoming a 'cloud-native' enterprise," where he shares Capgemini's advice for those who are "legacy-laden." Quoting his Capgemini sources, McKendrick writes: There often can't be a good business case made for bypassing years of investments in on-premises systems to adopt new cloud-based applications.

This is exactly right, and it's why forward-thinking organizations are beginning to realize that starting a cloud-native journey doesn't require traditional applications to be completely scrapped and rewritten from scratch. Doing so does far more than "bypass years of investments"; it adds months, if not years, of new investments in redevelopment costs--and new risk of breaking what once worked. The smarter move being made by a growing number of organizations is to begin introducing new technologies and cloud-native services to existing applications so they can maximize their ROI, while modernizing them over time.

This is an iterative process that can be done at any organization's optimal pace. Capgemini recommends that enterprises, "Start small, (and) don't attempt to boil the ocean." Skytap gave this same advice at this year's CoreOS Fest to teams looking to successfully--and safely--scale the adoption of containers. By first tackling small components of a traditional application, with an equally small team of early adopters, you introduce less risk to a mission-critical system, and building a foundation of trust makes getting future buy-in from others easier. This is no different from how you would nurture and grow the adoption of agile and DevOps initiatives--two other recommendations from Capgemini that are also extendable to on-premises applications.

There is no single, silver-bullet path to becoming a cloud-forward enterprise. In the cloud space, hype and buzzwords are commonplace: public, private, on-prem, native, hybrid. We obsess over defining these categories ad nauseum and debating over which approach is best. And we make businesses and applications fit into those cookie cutter definitions. But lost in all that is the practical and most important questions: What's best for my business? Where will my applications be most successful? Organizations don't have to fall into one category or another, and they don't have to abandon all of their on-prem applications in order to move to the cloud and modernize. The cloud is so often seen as being black and white, but don't overlook the shades of grey.

Editorial standards