Navigating your cloud journey
Any cloud transformation process that includes application migration will be complex. Yet among this complexity, there are a few clearly defined destinations on the journey to cloud. One such destination involves how "cloud-ready" to make the target application. How cloud-ready do you want/need the application to be in order to move to cloud at the desired time frame? Throughout this paper, we will outline some of these destinations and highlight best practices and lessons learned based on our journey. The key to success is to clearly define your migration goals in advance so that you can make optimal decisions about how to reach them. You’ll find yourself confronted by many potential paths. Over the course of your migration, developers, delivery teams, and executives will need to evaluate and make many choices about how to proceed.
We recommend focusing on the following technical and business drivers to frame the decisions you need to make to meet your business objectives.
Cloud services provide compute power at scale—far beyond what is possible for managed infrastructure—enabling your business to grow to meet market opportunities. Cloud-based infrastructure as a service (IaaS) and platform as-a-service (PaaS) enables ISVs to focus on building scalable architectures utilizing modern components. An added benefit of migration is that by freeing internal development teams from managing and scaling IT operations, focus can be directed to tuning and optimizing performance.
Modernizing toolsets, services, and architectures eases integration between components, helping applications realize the full value of the tools and technologies available in the cloud. Such tools range from infrastructure upgrades to automated deployment pipelines to integrated machine learning models that improve application performance. Modernization is most important where markets are experiencing rapid and consistent change, as applications must be dynamic to keep pace. In some cases, services can be completely rewritten and rebranded, leveraging the latest technology stack to offer lower costs or more-streamlined service options. Such changes can refresh aging products and disrupt established markets where licensed offerings are the norm. In other cases, products may be overhauled with new approaches, improving service while preserving brand awareness and customer loyalty. This does not necessarily require a complete change to the product suite.
Moving to the cloud becomes a trigger for a broad-based modernization push. As cloud provides you and your teams with access to services, technologies, and expertise that were not previously available in your organization, it becomes possible to achieve new goals and deliver new capabilities. Your teams can move “up the stack” to focus on new, generally applicable product features rather than custom code linked to specific deployments with distinct customers. With service provisioning, product updates, and customer support all happening faster than ever, resources can be refocused on developing new features. In this way, cloud migration sets the stage for a broad wave of modernization activities, transforming everything from the execution of product upgrades to the quality of customer service.
"The migration to the Gen2 Cloud has enabled Oracle to ensure successful delivery of our services via a robust DevSecOps model and allowed us to support our customers' business transformations. We now release software daily and have decreased provisioning time by more than 98%." — Karthic Murali, Senior Principal Product Strategy Manager, Oracle Global Business Units
Standardization across IaaS and PaaS allows you to reduce overhead and make teams more flexible and fungible. As organizations grow, your teams will adopt tools of various maturity levels. Consolidating these toolsets within the cloud service abstracts much of the complexity associated with this layer of IT management. It permits the development and use of standard operational practices for tasks that can map across the portfolio. Standardizing also makes routine activities simpler and more predictable, reducing labor demand for basic tasks. Resources previously tied up in navigating varied, possibly incompatible processes across applications are freed to focus on more-important problems, including the development of next-generation products and services for customers.
Notably, standardization makes it simpler to enforce global policies and practices around security, risk, compliance, and other operational activities that your teams can easily apply to existing and new products. In fact, many of the intrinsic capabilities of the IaaS platform, such as accredited compliance certifications, can be inherited by the application.
Revenue optimization can be achieved in two primary ways. First, and most obvious, are cost reductions. Eliminating data centers by utilizing IaaS not only shifts the financial model from CapEx to OpEx, it also typically results in meaningful TCO savings. What may not be as obvious are the cost savings achieved by rationalizing the technology stack used across a portfolio of applications that have been migrated to cloud. Common toolsets create institutional knowledge and eliminate the expense associated with ad hoc training for nonstandardized tools. Along these lines, common toolsets that treat infrastructure as code provide automation that ultimately saves time and labor costs. Finally, teams who are specialized in foundational areas that apply across the portfolio, such as security, eliminate the need to create experts within each individual product team.
Secondly, the move to cloud can ultimately optimize revenue by helping you get to market faster, as product development timelines are typically shortened once an application is cloud-ready or cloud native. Getting to market quicker means faster revenue realization. Once an application is cloud-ready, it can be deployed anywhere across the globe in a matter of minutes.
Combined, the principles discussed above should result in standardized product and service architectures as well as improved deployment speed and quality. Scale results from design for repeated patterns, which contributes to revenue optimization, quicker time to value, and the resulting ability to refocus resources on enhancing the quality and integrity of the service for customers.
"We saw a financial performance that allowed us just out of the gate to save 30 to 35% in our CapEx expenditure, and with the great performance we're getting from OCI, the ROI that we deliver with our suite continues to get better and better." —Mike Morini, Chief Executive Officer, WorkForce Software
Paths to value in the cloud
Cloud computing can include an array of IaaS and PaaS resources as well as multiple software deployment models, ranging from access to bare metal instances to integrated containerized environments to fully functional service stacks. At the most basic level, cloud computing refers to the replacement of physical infrastructure components with core IaaS resources.
Most enterprise applications were not originally built for the cloud. For many applications, converting or conforming to cloud patterns is time consuming and difficult. Replatforming can be expensive from both a time and labor perspective, so it is not surprising that it can sometimes be easier to design for cloud native principals from scratch. Taking that into consideration, companies typically find themselves in one of three main scenarios when considering a cloud migration.
- Exiting legacy data centers: Running a data center is expensive. Buildings, people, power, cooling, maintenance, and upgrades are just a few of the day-to-day responsibilities. Many businesses are actively working to reduce or eliminate their data-center dependence by evaluating application portfolios for candidates to move off premises. The priority is to move applications out of colocated, managed hosting, or on-premises data centers in an effort to reduce or eliminate capital expenses. Often a lift-and-shift strategy is utilized whereby the application is migrated as is to a bare metal server or virtual machine in the cloud.
- Evolving the technology stack: In this case, companies begin making incremental changes to applications that will require additional investment—but are also expected to bring more value—over time. An example of this would be replacing on-premises versions of Oracle Database with the cloud-based Oracle Autonomous Database without making major changes to the application itself. This is sometimes referred to as a move-and-improve strategy.
- Going all in on cloud native: The benefits of re-architecting an application from the bottom up to be cloud-ready might outweigh the costs of keeping a less-mature application in tact while implementing one of the scenarios mentioned above. Cloud native applications are highly distributed in nature—often constructed utilizing 12-factor principles—and are thus designed to be independent of the underlying architecture, meaning applications continue to run even when the infrastructure underneath it breaks. In short, it is worth evaluating whether this path makes sense for the target application, as the move to cloud will certainly be easier than moving an application that is tightly coupled with its underlying infrastructure.
To find out about how Oracle defines cloud native, the origins of cloud native apps, and best practices to follow when constructing them, read this ebook.
Another way to envision these scenarios is to look across the spectrum of actions you could take to move an enterprise application closer to a cloud native architecture while moving it to Oracle Cloud Infrastructure. See Figure 1 below.
Figure 1: Cloud migration change and investment levels
The left side of Figure 1 represents the least amount of change, the shortest time to value, and the lowest initial investment. The level of change, investment, and time generally increase as you move to the right, but the realized value is also greater. This model helps you frame a way to predict what kinds of investments to consider making during the move phase. Note that the scenarios aren’t necessarily discrete and overlap a bit as applications are built in a myriad of ways.
The scenarios described above become key reference points for assessing existing maturity levels and cloud-transition objectives. The gap between your current state and target state provides a rough estimation of the scope of technical and process change required for the cloud transition. In a perfect world, the cloud transition should result in all applications transitioning to cloud native delivery models. However, given resource and time constraints, few organizations are positioned to transition their whole portfolio to a cloud native model in a single process. Even simple replatforming efforts can be resource intensive and require significant investments just to replicate legacy capabilities.
The cloud transition is thus a question of identifying the trade-offs between the optimal cloud maturity level (where the applications sit in the cloud-hosted to cloud native continuum shown above) and the engineering investment needed to re-architect the product and its associated business processes. At this stage, the key step is identifying each application’s current and target maturity levels with a rough estimate of the development investment required to bridge the gap.
Applications that change maturity levels during migration also have to change operational patterns and expectations. The changing of maturity levels affects the teams, processes, and policies that support the service.