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.
