This follow-up article by Tony Perez, cloud solutions architect, Skytap, examines two options available to IT teams after moving non-HANA workloads to the cloud; leaving them as-is or modernizing them with cloud-native services to help economize their SAP ecosystem now running in the cloud.
Lush green tropical forests, sky blue ocean waters, cascading waterfalls, you have arrived at your ultimate destination…
In my last article Navigating The Road to SAP HANAOpens a new window , I discussed how an organization’s ultimate journey to SAP HANA might include moving non-HANA SAP components to the cloud by using an IaaS to run Power LPARs, as well as traditional x86 (non-Power) workloads in the same environment. One such option is Skytap on Azure, where IBM i (AS/400), AIX, Linux Power-based operation systems and traditional x86 workloads can all coexist without re-writing, re-architecting or re-platforming.
Leveraging the cloud for non-HANA workloads is part of an IT strategy that offers the following benefits:
- Support for IBM Power
- Regulatory Compliance
- On-Prem Infrastructure Reduction
- Business Continuity (disaster recovery)
Now let’s say you’ve completed that part of your journey compelled by the above-noted benefits and now have non-HANA workloads running in the cloud.
Congratulations!
You’ve accomplished this feat by doing a traditional “lift-and-shift.†This ensures that the original architecture was not materially disturbed. The lift-and-shift pattern reduced project risk, and you could leverage your historical IT skill sets cultivated over decades from on-prem.
The Fork in the Road
Now you have started a new journey. And right away, you have come to a fork in the road and are faced with two very different paths:
Turning left at the fork in the road: This path means you leave everything “as-is†after the lift-and-shift and maintain it without further modernization. This is the end of the cloud journey for you.Â
Now you’re saving money, because you don’t need to purchase your own equipment (which can necessitate significant upfront costs and long-term maintenance expenses). Furthermore, you have a secure platform managed by a third party, so you don’t have the expense of having to secure and maintain your own network components.Â
Your workloads now scale more easily and cost-effectively. Production infrastructure and development environments can be provisioned and ready to use within hours instead of days or weeks if you had to purchase and set up in-house computing infrastructure when operating on-prem.Â
Additionally, your infrastructure can now be accessed from anywhere, depending on the security that you have in place. The recent global pandemic created a remote workforce that is far more common in IT. Hence, the flexibility to access and manage your infrastructure no matter where you are is now more essential than ever.
However, no doubt that when you migrated non-HANA workloads to the cloud, you also carried forward many “satellite services.†These weren’t necessarily SAP components but were custom-built or third-party solutions to help make SAP more consumable across the enterprise. For example:
- Reporting
- Data IngestionÂ
- Data WarehouseÂ
- Data TransformationÂ
- Data Governance
- Machine Learning
Turning right at the fork in the road: To address these “satellite services,†let’s examine how cloud-native services from Microsoft Azure could replace or supplement legacy services from on-prem over time. This is often referred to as incremental modernization.Â
See More: Cloud Native Upturn Amid Economic Downturn
Benefits of Cloud-native Services
Once your workloads are migrated to Azure, you can connect them to cloud-native services to unlock additional value. For example, Microsoft Azure offers cloud-native services to support things such as advanced analytics, data visualization and reporting, and AI and machine learning so you can fully realize data modernization benefits for legacy data.Â
Here are just a few of these cloud-native services and their benefits:
- Power BI: Create powerful reports and data visualizations with Microsoft Power BI to better inform business decision-making.
- Azure Synapse: Ingest data from physical and logical files or a DB2 database stored within your IBM i (AS/400) libraries to an Azure Data Lake using Azure Synapse.
- Azure Data Factory and Azure Data Lake: Warehouse your data and create code-free transformations, as well as merge data from other sources to gain insights.
- Azure Purview: Create a holistic, up-to-date map of your data landscape with automated data discovery and automated sensitive data classification with this end-to-end data governance platform.
When you move SAP NetWeaver workloads to Skytap on Azure, you are enabling SAP HANA workloads to interoperate with other Business Applications running on Azure. These cloud-native Azure services could replace and simplify the overall architecture. If part of your long-term strategy is to leverage Azure for greenfield applications, then this strategy makes sense. Why duplicate services? Your plan should be to consolidate them over time.
Learning Along the Way
Regardless of which fork in the road you took, you did achieve one tangible benefit: you gained experience migrating applications to the cloud. If you took the left fork in the road and are planning to leave the application “as is,†that is a solid IT strategy for legacy applications moving to the cloud. Now, you have good information on the costs of migrating large applications, and you probably learned how to deal with security and networking issues as well. So even though the application might not be modernized, you did modernize your skill sets. That is an important benefit for your IT organization.
If you are taking the right fork in the road and are planning to replace or integrate Azure native services into your existing application architecture, then you’ve created a repeatable “path to the cloud,†not only for this SAP application but for other applications that might follow. The pattern is based on (1) “lift and shift as-is,†(2) getting the application stabilized and running at your existing production standards, and (3) begin looking at how individual services from Azure could be used to replace or improve the carried forward legacy architecture. You’ve “won†regardless of which path you took.
To sum up, once you’ve successfully moved your non-HANA SAP NetWeaver workloads to the cloud, you inevitably gained a basket of additional IT services and solutions on which the SAP on-prem implementation depended to operate successfully. So, you can turn left at the fork in the road and let it run as-is, or you can turn right at the fork in the street and begin to look at how to modernize and economize your SAP ecosystem now running the cloud and enable it to transition more easily to SAP HANA in the future.
Where are you on your transition to SAP HANA? Are you turning left or right at the fork in the road? Share with us on FacebookOpens a new window , TwitterOpens a new window , and LinkedInOpens a new window .
MORE ON SAP HANA:Â
- Getting The Best Outcomes From Your Transition To SAP S/4HANA In The Cloud
- Successfully Migrating to SAP S/4HANA: How to Pull It Off with Aplomb
Image Source: Shutterstock