Tag: cloud computing

“My application can’t be moved to the cloud!”

My company provides the ability to host IBM Power AIX and IBMi application workloads in the cloud. We partner with two of the world’s largest technology companies to provide this service. During my daily activities as a Cloud Solutions Architect (aka Pre-Sales Engineer), I listen to many customers tell us about their “hopes and dreams” regarding moving legacy workloads to the cloud. These are definitely “Cloud Stubborn”. But when it comes to legacy applications based on IBM Power one of their common responses is:

“It is impossible to move my IBM Power-based application to the cloud.”

Of course, that begs the question “Why not?” The answer is often one of these:

  1. “My application is based on IBM’s AS/400 or more recently called IBMi, or IBM AIX.”
  2. “My application has hard-coded IP addresses compiled into the source code.”
  3. “There is no longer anyone around who knows about the code or applications that are still running.”
Continue reading →

Prove your IBM i Backup is Recoverable: The Cloud Way

Beyond having checklists and runbooks, what else can you do to test your backups?

In the comprehensive article called “How to Prove Your IBM i is Recoverable without a Real DR Test,” Tom Huntington from HelpSystems details all the IBM i Save Commands and system objects that should be included within a comprehensive backup. By performing an audit of your backup process, you might identify missing components that prevent you from doing the worst-case scenario, a full system restore. It is a great article that IBM i administrators should review.

Continue reading →

Resetting QA Test Data: The Cloud Way

Stop running database scripts to reset test data, there is a better way.

One of the common use-case problems we hear about from QA Teams is figuring out how to reset test data once any testing activity has been performed on a complex test environment. In most cases, the stories describe multi-day or multi-week processes that must be completed to reset a test system back to some known data state. If you don’t do a reset, then you are accumulating technical debt in your test data. Any repetitive testing results become suspect, and quality decisions can not be made from the testing results. In some cases, it isn’t possible to start a new iteration of QA testing without first resetting your test data from the prior test run.

Continue reading →