Executives leading small, medium, and large organizations now recognize software is a core business differentiator, and they are looking to their IT teams to accelerate innovation. IT leaders, in turn, are embracing the cloud for a competitive edge. Yet finding multi-cloud success has been harder than they ever imagined.
After hearing our customers talk about their many challenges, we’ve discovered that how organizations approach multi-cloud ultimately determines their success (or failure) with it.
Those that begin by taking their current application portfolio and trying to move it all in one go to the future-state architecture typically fail to reach their goals in the time or budget they agreed upon with the business. They encounter not only technical obstacles but operational, staffing, cultural, and tooling ones at the same time. Soon, the transformation that they anticipated would take months, is looking like it will take years and could be interrupted by changes in business priorities over that period.
For these organizations, it’s an all or nothing—all cloud or all on-premises—proposition. Making it all the way to app modernization nirvana or going back to the beginning.
The reality is that many leaders discover all of these challenges when adopting a single public cloud, such as Amazon Web Services or Microsoft Azure. So, imagine how many more obstacles they’ll need to overcome with an all-or-nothing approach to embracing multi-clouds. The realization of achieving the promised benefits of a modern, multi-cloud future suddenly goes from looking great to looking fairly grim.
Change Shouldn’t Be About “All or Nothing”
If I’m the CIO investing my four-years’ (average) tenure, energy, and resources into an app modernization initiative, I want two assurances: that it will be fast and that it will be successful.
Not every application needs to move directly to cloud nirvana. Instead, CIOs should look at their cloud strategies as “right-sizing” exercises. Some applications may just need to be rehosted to take advantage of OpEx cost models; others may need to be replatformed to benefit from Kubernetes or containers. Finally, some may be ideal for refactoring right away to reach cloud nirvana. So, it’s essential to recognize that not all apps are equally crucial to the business, and not all strategies will be the same—even within a single organization.
If you plan to force change by swapping out the entire application stack rather than gradually evolving your current teams and processes, unfortunately, you will have the exact opposite effect of what you want. You’ll create new silos of teams and processes for the new stack at high costs, long return-on-investment (ROI) payback periods, and expanded security risks.
It won’t work as you imagine, frustrating you for these reasons:
- It sets up an “all or nothing” scenario –Instead of iterating to evolve to a new model, an app or app component is either completely in the old world, or completely in the new world. There’s nothing in between.
- It creates inflexibility and limits your options –When new business priorities arise (for example, an acquisition or new product launch), work slows down or stops on the transformation because some apps are in the old word while others are in the new.
- It has a steep learning curve – Because the new and old worlds are completely different, the learning curve for developers and operations teams is very steep. This creates new silos and will cause both dev and ops teams to make errors as they learn.
- It’s slow –Because so much effort is required to refactor, rearchitect, retool and retrain, progress will only inch along. Migration to the new stack cannot be broadly parallelized because so much manual effort is needed to complete the transition.
- You’ll be forced to straddle two different worlds – Although the goal may be to get everything over to the modern side, the reality is that this transformation will take years (if ever completed at all!) so teams will have to straddle both the old and new stack for a long time, again slowing progress.
- You’ll have to invest resources for each cloud – Because every public cloud is vertically integrated differently, you will have to allocate time and resources to each—plus integration across them—to achieve your multi-cloud goals.
In the end, the all-or-nothing model adds challenges to modernizing apps. Although well-intentioned, it is sub-optimal for CIOs wanting speed and success.
Top Considerations for Choosing a Path to Cloud
If you could simply modernize everything at once by running all of the apps you have today on a single cloud, everyone would have done it. That’s why you need a different approach, one that:
- Maximizes choice at all levels – You need an approach that provides broad infrastructure choices around the location(s)where your apps run, the underlying infrastructure and hardware, and the cloud/service providers. You also need choices for how to build the application, including the following:
- App architecture (traditional, virtual machine (VM)-based, container-based, microservices, etc.)
- Public cloud services (for example, Redshift, Cloud Spanner, etc. from any cloud)
- Enterprise-vetted operational support system (OSS) packages
- Platform-as-a-service (PaaS) versus container-as-a-service (CaaS) abstractions
- Ensures the quickest time-to-value – Your approach needs to remove hurdles to and deploy automation as much as possible to realize quick wins while rapidly progressing toward your future vision.
- Operates least disruptively – Your approach must provide a consistent experience. But it also needs stepping stones to progress non-disruptively rather than having to do large, time-consuming, and risky “jumps” between states. You also need to be flexible to deal with unforeseen changes.
The approach you take is critical because of the sheer scale of what you’re trying to do. After all, your business could have dozens to hundreds to thousands of applications that need to be modernized.
Where to Begin
You have a lot of decisions to make when modernizing apps. Which—and how many—clouds should you use? Do you deploy Kubernetes? How will you ensure app mobility and consistency? You typically will end up taking one of five possible actions for each app as a result of making these decisions:
- Refactor (rewrite the app, typically to a microservices architecture)
- Replatform (usually from VMs to containers and public cloud infrastructure)
- Rehost (migrated as-is to cloud)
- Replace (usually with SaaS)
- Retire
Today, many of the cloud providers offer a full stack, proprietary to each service. Although this bundle is convenient, it hinders your ability to be flexible, to change your mind, and move your apps to a different provider. By abstracting your infrastructure layer using VMware solutions, you can rest assured that mobility to a new destination is possible without having to start over.
One size certainly doesn’t fit all when it comes to app modernization, so having the right digital infrastructure—horizontally rather than vertically focused—that accommodates all of these options is critical. We won’t wade into the debate here of when you should take one action versus another, as those decisions are highly specific to each situation and application. We will talk about why going with a solutions provider focused on maximizing your choices, flexibility, and time to value while minimizing disruption is best for digital business.
Watch this short video or visit this event page to learn more about multi-cloud approach best practices.
‘
