By Loke Tan, Director of Product Management at Skytap

Over 90% of enterprises worldwide will operate in a hybrid network infrastructure model by 2022 (via IDC). But the move to hybrid gets more complicated for organizations with key applications running on IBM Power servers. That includes almost any businesses older than 10-12 years, especially banking, retail, manufacturing, distribution and finance companies. These organizations often assume that the cloud isn't an option for these workloads, due to the perceived risk and difficulty of replatforming, and thus they can't take full advantage of a hybrid model. But that's not necessarily the case. 

There are options for moving business-critical IBM Power applications to the cloud that allow for a hybrid infrastructure model. The most common approach is to run production code on-premise and move disaster recovery and/or development workloads for IBM Power systems to the cloud. This reduces costs and increases flexibility for these functions, while maintaining stability for production. Let's go over each of those in detail to see how it works and what IT should consider when going down this path.

Cloud Disaster Recovery

A common first step towards hybrid for many organizations is moving disaster recovery (DR) or backup systems to the cloud. Cloud-based DR offers several benefits compared to on-premise solutions, including cost saving, geographical distribution/resilience, and ease of use. Like other "as-a-service" models, the customer only pays based on how many resources they use and leaves the management of hardware and other infrastructure to the cloud provider.  Users can then reduce resources to only the level necessary to replicate data to the backup server under normal conditions and "turn it on" when needed. This typically costs far less than buying and maintaining physical backup servers and frees up IT budget for other projects rather than managing backup servers. Since many of the applications running on IBM Power are business-critical (an ERP system for example), ensuring they are backed up completely and can be restored quickly is vital; every minute of downtime in an outage is lost revenue.

Cloud Development

The second most-common workload moved to the cloud is development and/or QA testing. By creating replicas of IBM i applications in the public cloud, copies can be distributed to multiple engineering teams, allowing them all to work simultaneously on real-life environments, rather than mock environments running on local workstations. Giving teams the power to create these cloud environments themselves, rather than requiring infrastructure teams to create them for them, can also speed up projects considerably. The same process can be done with QA or integration testing. A cloud representation of a target system can be saved as a template and then reset after every test, speeding up testing and preventing "configuration drift." The efficiency gains from moving developer environments to the cloud means they are high on the list of things many IT teams want to migrate.

One indirect benefit of moving DR or development to the cloud is that it provides organizations with a "toe in the water" to experiment with a hybrid model without risking any business-critical workloads. If mistakes are going to be made, better they happen to a DR server or test environment than to production. This hybrid model allows organizations to become more comfortable with the cloud and gain confidence and experience for future migrations.

With adequate preparation, moving from IBM Power on-premise to the hybrid model explained above is not as challenging as many assume it to be. Here are three considerations that IT should address while planning a migration to prevent potential problems.

To replatform or not to replatform?

This is the first and most obvious question when moving to a hybrid model. Replatforming is often quite risky and complex with long-running IBM i applications, particularly if the applications have been heavily customized (as they often are). Power also has benefits the organization doesn't want to lose, like mature security and High Availability options. In this case, there are specialized solutions that allow IBM Power workloads to run in the public cloud unchanged and IT will need to weigh the benefits of the cloud and the costs of a specialized solution versus the work and risk of a migration or the status quo.

Losing control of network infrastructure

Moving workloads to the public cloud means IT no longer has control over the network connections to and from those workloads. This has a number of ramifications, like how to monitor that traffic for security and troubleshooting, and longer recovery time in High Availability and DR solutions. These concerns are generally outweighed by the benefits of running DR in the cloud, but IT should review them in advance and plan ahead to account for them.

Picking the right Disaster Recovery provider

When moving DR to the cloud, IT teams should first decide on their recovery objectives (how much data they can afford to lose and how quickly they need the backup system up and running) and make their decision about a provider based on these metrics. They'll also need to pay attention to any data sovereignty laws that restrict where their data can reside. This might limit them to only using providers with a data center in the same country or region where they are located. On the other hand, hosting backups in a different region for greater resilience may be required to comply with certain cybersecurity standards (and is a good practice regardless). IT should take all of these factors into account when choosing a DR provider.

As long as IT follows these best practices, they can enjoy the benefits of a hybrid infrastructure even if they rely on IBM Power for crucial appliances. If you've written off this model so far, maybe now it's time for a second look.

##

ABOUT THE AUTHOR

 

Loke Tan is a Director of Product Management at Skytap, a cloud services to run IBM Power and x86 workloads natively in the public cloud. Loke combines a strong technical development background, with experience in developer marketing, technology evangelism and social media. He was a technical product manager and developer evangelist at Microsoft for ten years and has held similar positions at Avalara and Concur.