In The API World, Nobody Knows You Are An IBM i
August 2, 2021 Timothy Prickett Morgan
One of the earliest memes of the early years of the commercial Internet was captured in a famous cartoon in The New Yorker magazine penned by Peter Steiner and showing a dog at a computer, which quipped: “On the Internet, nobody knows you’re a dog.”
Somewhere back in the archive – it was in September 1997, which is not online because we were a paper, subscription publication for the first seven years of The Four Hundred – we did a riff on this meme with a lead essay called, On The Net, No One Knows You Are An AS/400. This was when IBM has doing its big e-commerce push and the WebSphere variant of the Apache Web server was not yet dominant and Netscape Communications, the big dog in Internet infrastructure servers, was getting ready to port its codes from Unix to OS/400. Netscape came and went, as did I/NET and a few other providers, and WebSphere came to dominate, as often happens when a vendor sells an integrated stack of technology.
Fast forward to 2021, and the world has learned from the hyperscalers such as Google and Facebook and Microsoft and Amazon to think not in terms of Internet protocols and services, but rather at an abstraction layer one notch higher but still below the applications themselves, called appropriately enough the application programming interface, or API, layer. Now, APIs are how programs are stitched together and how infrastructure itself is controlled. So, as we say in the title of this essay, nearly three decades after that meme in the The New Yorker: In a world dominated by APIs, no one knows – or cares or needs to care – if you are an IBM i platform.
On June 30, Steve Will, chief architect of the IBM i platform, hosted an hour-long discussion to try to help the programmers at IBM i shops try to get a better strategic and tactical grasp of the directions they need to be taking to create the next generation of applications for the IBM i platform. (You can sign up for a replay of the event here.) The conversation was a lot broader than just APIs, including other things such as new programming languages, application modernization, microservices, containers, and public clouds – and absolutely keeping as much of the legacy application code and databases that have been in use for decades at OS/400 and IBM i shops as makes technical and economic sense.
If you are working at a company where the IBM i platform is not under constant threat of replacement for reasons of corporate politics, technical prejudice, or just the desire by some executives to change for the sake of change, then you must be the lucky one in a million. The rest of the base feels all of these pressures, all of the time. Which is why it is important to listen to what Will has to say and use this as weaponry in your defense of the IBM i platform within your company.
We have always contended that the risks of writing new code is too great to wholly replace most legacy applications and their databases. This is one of those change for change’s sake scenarios. Do the people at your company honestly think a bunch of 25- to 30-year-old techies can examine three decades of business logic and database design and re-implement that in some new language with some new architecture and do it flawlessly or without delay? It usually makes sense to modernize these applications than to recode them for any platform (including IBM i, such as happened when lots of the base ported RPG applications to Java in the 1990s and 2000s or PHP in the 2010s). The smart thing to do is to take known good bits of code, extract them from the monolithic code, refactor them into callable services, and wrap them up as APIs for anyone to call and make use of. Like this:
Will admits this is a bit of an oversimplification of the modernization process, but when talking to upper management, you have to sometimes cut to the chase scene and keep it high level so they grasp it.
“I simplify what has to be done into this three-step process, where I’ve got an initial program that has way too much code for a modular piece of code,” explains Will. “And I refactor a piece of that critical business logic and I separate it into its own ILE module. Now we have tools in RDi that help you do that, but there are other tools from other vendors that help you do this refactoring, et cetera. That’s cool. You get yourself a refactored thing that has one particularly good piece of service that it wants to give. You can easily wrapper that into a service. And again, we have a tool, the Rest API Engine, that helps you do that. And then that service can be made available to things that are in your enterprise or outside of your enterprise in the cloud, because as far as they know, that service is running in a container. What does it matter? All that matters is that it’s a service that is callable in a standard way.”
The fun bit is that with this refactoring of code and databases to expose them as APIs, the same techniques that can be used to modernize both in a native fashion on the IBM i platform can be used to modernize them for running in the public cloud or in a modern DevOps mode. As Will is fond of saying, it is not “IBM i or the cloud,” but rather “IBM i and the cloud.” To be fair, public cloud instances of Power Systems machines that could support IBM i are relatively new in the past few years from IBM, Microsoft, Google, Skytap, and Comarch, among a few others. And it would have been better if this had been done a decade and a half ago when true cloud utilities, starting with Amazon Web Services, popped up and changed the IT consumption model. But, at least IBM i shops have lots of hosting, co-location, and true cloud options today.
The developers at IBM i shops have to start thinking like the whippersnappers that some upper management people want to replace them with, or at least augment them with. Here are the key attributes that Will says IBM i programmers have to be thinking about as they write new code or refactor existing code to create the “IBM i Next Gen Apps,” as he calls them:
- Quickly respond to business needs with a DevOps, CI/CD, agile approach
- Encapsulate processes and data, thereby creating assets for the business
- Blend technology, using the “best fit for purpose”
- Easily incorporate new technology, even if the technology is not “in-house”
And here is a chart that shows the lay of the technology landscape that most IBM i shops are facing, and how they need to embrace the new and the newer as well as the legacy to maximize the value of all programs in the IT portfolio at the minimum effort and cost. And that, after all, is what all good IT managers do.
And here is another great chart that illustrates the blended application development strategy that Will advocates and that has always made good sense to us and most of the people we talk to who are IBM i application developers:
All of this data should help make it a little bit easier for those who want to push continued – and expanded – investment in the company IBM i platforms. This is the kind of thing that should be pushed hard. We would love to see more economic analysis of porting code versus writing new code versus refactoring code into APIs, because this is ultimately an economic argument, as are all technical arguments excepting those in supercomputing, where budget is not a limit given the very nature of the task to push the computing envelope. Businesses do not have such luxuries.
RELATED STORIES
In Search Of Next Gen IBM i Apps
Modernization Trumps Migration for IBM i and Mainframe, IDC Says
A Chat With Steve Woodard, The New CEO At Fresche Solutions
