A pragmatic approach to including “stubborn” legacy or specialty applications into an evolving cloud ecosystem.
First came “the cloud,” and IT embraced and consumed it. For many companies, this evolved into hybrid-cloud due to business requirements such as meeting regulatory and data sovereignty requirements, leveraging paid-for on-premises technology investments, and addressing requirements for low latency, especially when communicating to legacy architectures.
Then came “multi-cloud,” as described by Vmware and others. Where “the cloud” usually means using the services of a single cloud provider, which most of us have done, “multi-cloud” describes using multiple cloud providers’ services in a heterogeneous way. More complex than the single cloud, multi-cloud is helpful for organizations needing to pick and choose services from various cloud vendors or requiring high-end redundancy. Today, 61% of businesses use one or two clouds and are considered to be “multi-cloud.” The drawback of multi-cloud is that each cloud operates in a more isolated operational model, and the customer has to integrate them. Concerns about specialized skill sets, greater complexity, and increased security concerns are often cited as the challenges of multi-cloud.
Next comes “super cloud,” which has been described as the next evolution in cloud computing, where an abstraction layer exists over the top of actual lower-level computing services. Super cloud aims to be a unified architecture for managing data and services that can float across multiple cloud providers.
The problem is, as defined above, super cloud is unobtainable for many organizations still evolving their multi-cloud or hybrid cloud strategy. As Tim Wagner, CEO of Vendia, writes: “The prospect of simultaneously maintaining on-premise data centers, migrating to one public cloud, and then redundantly staffing for two or more additional clouds on top of that is a recipe for frustration…”
Cloud, hybrid-cloud, multi-cloud, super cloud…the cloud industry is evolving regardless of where you are in the journey. Most companies have committed to a multi-vendor cloud strategy and are being successful. However, these companies often struggle with legacy architectures that are “stubborn” to migrate to the cloud. These might be mainframe, midrange, or specialty architectures that have been around for decades, run business-critical applications, and are the fabric of many consumer services that exist today.
For the remainder of this article, let’s focus on midrange legacy computing systems. We can describe a pragmatic pathway where midrange systems can participate in the continuing evolution of cloud computing.
What is the profile of the company that describes itself as multi-cloud but still has on-prem midrange systems?
A typical company profile with midrange systems might include one that:
- has traditional on-prem architectures comprised of x86, Vmware, Linux, Windows, etc.
- has midrange Power Systems like IBM i (AS/400) or AIX
- might have an IBM Mainframe or other “specialty” computing devices like Tandem, Teradata, or Sparc Solaris
- would describe itself as multi-cloud, but primarily works with one or two cloud providers
A company as defined above typically expresses interest in:
- a data center exit as a way to reduce costs
- avoiding an expensive hardware refresh for its midrange systems that are built on proprietary hardware
- how to modernize midrange systems and create a pathway for refactorization
- how to reduce security complexities when using on-prem and cloud-based services
- how to provide Disaster Recovery and High Availability for its proprietary midrange systems despite a push to close traditional customer-owned or leased data centers
Transitioning Legacy and Specialized Workloads to Hyperscalers
No cloud vendor today can host all the workloads described above, but the ability for cloud hyperscalers to support legacy and specialized workloads is well underway! For example, Azure allows you to host the following workload types within its data centers:
- Azure Services (200+ services available)
- IBM Power midrange systems like AIX, IBM i (AS/400), and Linux on Power
Azure leverages Skytap to natively run AIX and IBM i workloads on actual IBM hardware, not emulators. Skytap can also host older x86 operating systems that native Azure does not support. Instances of these operating systems can all be brought together into network subnets that replicate the existing on-prem network topology. No change of IP addresses is necessarily required.
So, within Azure, you have support for modern and legacy workloads. In other words, it is a pragmatic beginning to allow hyperscalers such as Azure to “absorb” most of the legacy workload that was previously stuck on-prem.
What are the Benefits of This Approach to Transitioning Midrange Systems?
Reduced Latency
Many legacy applications have specific latency requirements between application service components. If you migrate some of your on-prem workloads, like x86 to Azure native, but leave legacy AIX or IBM i on-prem, you might not be able to meet the latency requirements of older non-x86 applications. If you place everything in the same Azure data center, you’ll have a good chance of meeting your legacy latency requirements.
Unified Networking
Following the Azure and Skytap example, if you host IBM Power AIX or IBM i in an Azure data center, you tie that back to on-prem using standard Azure ExpressRoute technology. There is no need for a costly third-party “cloud-connect.”
Standardized Security and Compliance
Using the Skytap on Azure example again, the only way to access the administrative components of IBM Power running AIX or IBM i is to authenticate through Azure using one of the Azure-supported authentication methods. Once authenticated for Azure, you can access the administrative panels for IBM Power.
Reduce Skill Set Burden
Running legacy operating systems like IBM AIX or IBM i in Azure will still require specialized skill sets at the operating system level. AIX and IBM i are not like Windows and Linux. But once you move beyond the guest operating system, your existing on-prem IT skill sets and Azure skill sets will be most of what you need. As Tim Wagner wrote earlier, having wholly duplicated skill sets across “multi-cloud/super-cloud” architectures is out of reach for many mainstream companies. If you are multi-cloud today, combining your cloud and legacy skill sets should provide everything you need.
Midrange is in the Cloud
We have described a “path to the cloud” for what might be called legacy or specialty applications. Just a few years ago, there were no options for midrange systems like AIX or IBM i to move to the cloud. The only choices were to perform a costly and risky refactor or leave them forever on-prem, eliminating the possibility of closing the data center.
Transitioning legacy and specialty workloads to your hyperscaler allows you to “lift-and-shift” those fragile applications that can not easily be changed. It also puts you into better strategic alignment to refactor those applications in the future. Now that midrange is running in the cloud, you can begin a more incremental approach to app modernization that does not force a rewrite from scratch as a prerequisite to moving to the cloud.
What we know as “the cloud” is evolving. Not every specialized legacy workload is supported yet, but today there are pragmatic options that fit a majority of enterprise workloads. No doubt, more specialty workload options are on the way. Don’t wait to begin your journey. Set yourself up to take advantage of the evolving cloud now.
Meet the author:
Tony Perez – Cloud Solutions Architect at Skytap
