In our previous installment in this series, “IBM AIX Is Still a Pillar in the Enterprise,” we wrote about how even though cloud-native applications tend to grab a majority of today’s tech industry headlines, these applications are often heavily dependent on legacy or “traditional” applications behind the curtains. These applications may not get as much coverage in the press, but the mission critical lines of business that they support make them incredibly valuable, and worthy of attention.
We took a look at the IBM AIX operating system in particular, due to its high levels of reliability and performance that it delivers to traditional applications, and we consulted with our partners at IBM to learn more about how AIX is evolving in today’s cloud-centric market. At Skytap, we have a number of customers with AIX dependencies, and we’re always looking to better understand how their software development and delivery processes are changing. This enables us to continuously deliver solutions to our customers that meet the changing and accelerated needs of their own clients.
One customer of ours, in particular, a large—and highly respected—distributed health insurance company, recently shared a story with us around the role technology plays in the ways they interact with their customers. These interactions are critical to our customer’s success, and any interruption in the reliability, stability, or security of the technology they depend on could result in immensely negative results.
The need for our customer to maintain the stability of their applications—while delivering updates to them that support their business needs—has required that they look for ways to dramatically improve their ability to fully test their releases before they reach production. They’re doing as much component testing as far down the path as they can, but there are gaps, as they just can’t test all of the dependencies they have, especially when those dependencies are on applications running on the AIX operating system. Our customer, like many large enterprises today, maintains x86 applications, applications running AIX on Power Systems, as well as the dependencies between them. But this often causes problems when trying to perform end-to-end testing across a complex portfolio of different operating systems and architectures.
While some organizations with similar dependencies and architectures have looked at rewriting or refactoring their older applications, they find this is not feasible due to the time, cost, resources, and risk required to do so—nor are they necessarily interested in getting rid of a historically dependable OS like AIX. These applications usually have a lot of knowledge baked into them, and oftentimes, no one person knows entirely how they were originally constructed. When it comes to testing these applications, long provisioning times, constraints around shared environments, and struggles to acquire fresh data sets that match production all result in less frequent testing, poorer software quality, and greater risk.
Our customer is looking to eliminate what are essentially traditional constraints by finding opportunities for boosts in agility, and reduced time to market and bottlenecks amidst their traditional applications wherever possible. The challenge is, of course, achieving on-demand, self-paced virtualization and provisioning of environments with non-x86 architectures. As mentioned earlier, our customer relies heavily on AIX, and the dependencies around entire suites of applications running AIX have prevented them from full lifecycle virtualization. There are companies today who can provision AIX instances as a managed service—but not at the speed, and on-demand nature needed for true agility. As teams wait for the environments they need, bottlenecks and inefficiencies grow, the available time for testing shrinks, and risk rises.
We’ve worked tirelessly with this particular customer to combat these challenges, as they’re far from the only organization dealing with this constraint. And I’m proud to say…we think we’re onto something.