eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The numbers are in: The global cloud computing market has reached $250.04 billion in 2021 with a projected compound annual growth rate of 17.9%, which will reach $791.48 billion by 2028, according to Fortune Business Insights.
Statistics vary, but most enterprises have migrated between 20-40 percent of their systems to the cloud or created net-new systems in the cloud to handle 20-40 percent of their workloads.
Even though we’ve been at it for a little over 10 years, moving to the cloud continues to create excitement in the enterprise. However, most enterprises now realize that cloud operations (CloudOps) are the true challenge. Almost every enterprise hits the CloudOps stumbling block when they migrate apps and data to the cloud because increased heterogeneity and complexity are a byproduct of every cloud move and build.
The true value of any service or commodity is its ability to do the job it was designed and purchased to do, along with its ongoing reliability. These same reliability factors hold true when it comes to cloud computing.
Reliability Challenges During Cloud Migrations
Think about it for a minute. Let’s say you own an attractive, well-designed sports car, but its engine is so unreliable that you’re never certain when or where it might break down or what it will cost to repair. It’s this kind of consumer uncertainty that resulted in a bowling ball manufacturer owning Harley-Davidson in the 1970s.
Stepping forward in time once again, let’s look at the reliability challenges enterprises face during cloud migrations. Let’s also touch on the approaches and technology involved in migrations that will lead to success vs. a bowling ball buy-out.
Take a mainframe-to-cloud migration. You start with a single application that runs on a single server and talks to a single database on the same platform. It’s not a huge task to run most mainframe-based applications on platform analogs in the public clouds these days. However, this happens at the expense of operational complexity.
When this and other applications move to the cloud, they’re often containerized to run on Kubernetes container clustering mechanisms that talk to databases that are scattered between native public cloud databases, and databases that are still maintained on-premises for compliance reasons. That’s how we go from 10 solution patterns to 30-40 without added functionality or any changes to the applications and/or the data.
The once-easy-to-operate systems now have many more moving parts, technology types, and platform locations that make operations (CloudOps) much more complex. We typically need new tools and new skills, but with no budget increases. Something’s got to give.
How to Create Success in CloudOps
Bridging the Cloud Transformation Gap is a report that evaluates the findings of Aptum’s Global Cloud Impact Study. “The survey reveals this with 62 percent of respondents citing complexity and abundance of choice as a hindrance when planning a cloud transformation.”
The rising use of multicloud drives much of this complexity. Decision makers use the “best of breed” battle cry to leverage multicloud solutions. This leads to an explosion of cloud services choices. The choices include different security and/or governance systems, databases, machine learning, analytics, and other applications/services that are easily provisioned from public cloud providers.
The newly formed CloudOps teams usually run out of money, time, or both, because they can’t evolve their skills and tools fast enough to deal with the exploding complexity. Instead, they ‘explain away’ the outages and security breaches as unavoidable byproducts of the move to the cloud. Most enterprises find these explanations unacceptable.
Here’s the good news; enterprise CloudOps teams can be successful. Here are some suggestions to increase your odds of success:
Create an ops plan for all migrated and net-new applications, including applications that are on-premises and in the public clouds
Typical cloud migration and development projects take the ongoing effort and cost of maintaining and operating the resulting systems into account at the end of the project. The usual result is a complexity surprise, with unforeseen maintenance and operations requirements that remove most or all of the cloud move’s projected ROI. Do yourself a favor; put ops plans in place at the beginning of a cloud move.
Cloud and non-cloud heterogeneity: Consider the tradeoff
You need to understand the cost, risk, and ROI of deploying 5 different security systems, 20 different development platforms, and 30 different databases on 3 different public cloud brands.
Those who choose best-of-breed cloud products or services rarely consider the clear cost of the added complexity or the additional risk and cost that comes with operationalizing that complexity. The key to success is to implement common services that cross clouds and platforms.
No, the security, governance, MDM, ops management, testing, and other services that you can leverage from platform to platform might not be best-of-breed. However, the ongoing ROI usually justifies the benefits of leveraging the same technology across applications, data, and platforms.
Final Fact: Tools won’t save you
Yes, leveraging AIOps tooling and other operationally-focused technology allows you to manage more complexity with less cost and risk.
However, CloudOps teams often spend more time figuring out the tools they want to employ versus knowing and studying the project’s requirements so they can purchase and deploy the correct tool. It doesn’t matter if you spend months learning how to fly a jet if you open the hangar and find a helicopter. Don’t miss that mark.
The best path is to create an ops plan as defined above. Determine the tasks and playbooks required to create and successfully operate the new “to be” state that will include cloud or expands its use. Then, and only then, pick the tools that will automate and build upon those plans and processes.
The pandemic drove many applications and data into the cloud before their time, or before their projected timelines. Over the next few years, budget-buster CloudOps bills will come due for many organizations. Yes, we had a good reason to rush to the cloud but now it’s time to re-assess our CloudOps strategies.
You need the ability (and need to cultivate the related skills and abilities on staff) to look at cloud migration projects with a long lens, long before the project begins. What are the operations and maintenance requirements for the affected data and apps 6 months after the migration project ends?
If you have a cloud migration project in the pipeline and this is the first time you’ve asked yourself that question, you need to reconsider your project’s timeline.
About the Author:
David Linthicum is the Chief Cloud Strategy Officer at Deloitte Consulting