Modernizing IBM i Apps with Microservices
November 7, 2018 Alex Woodie
Application modernization means different things to different people. For some, it could be turning a 5250 screen into a Web or mobile interface, or replacing database access with SQL. But for others in the IBM i community, including the vendor OpenLegacy, modernization refers to exposing existing business logic as APIs through a microservices architecture.
Microservices refers to a software development technique whereby applications are broken down into multiple self-contained components and served via APIs in a loosely coupled but coordinated manner. The main advantage of this approach is each microservice is built independently of others, which can boost productivity and result in more resilient applications. It’s pretty much the direct philosophical opposite of the monolithic approach behind many (if not most) IBM i applications.
The modern distributed microservices architecture is similar in some respects to the service oriented architecture (SOA) technique that rose to prominence in the early 2000s, including the componentization of business process and reliance on APIs. However, there are important distinctions that set microservices, including the use of lighter weight API protocols such as REST (instead of SOAP and XML) and the use of containerization technologies like Kubernetes and Docker.
While microservices have been in the news a bit, they’re still relatively new and there is a lot of work being done at the moment to develop the tooling that companies can use to build and expose their own microservices. A recent survey by microservices software provider Perficient found that 70% of companies are investigating microservices architectures, but are facing IT headwinds as the companies shift to become more agile and DevOps-focused.
Microservices are being adopted with new applications, but that doesn’t mean they’re irrelevant to existing ones. A recent Red Hat survey found that about almost 80% of users of its Kubernetes platform, called OpenShift, were looking at microservices as part of their efforts to re-architect existing applications.
To be sure, there are plenty of stories of organizations adopting microservices technologies and techniques to gain more value from legacy systems. In its recent whitepaper “How APIs Can Modernize Legacy Systems,” API management firm MuleSoft discusses how several large organizations like Siemens and Mount Sinai Health System re-architected business processes housed in legacy systems like IBM mainframes around APIs, which improved access to the systems while reducing maintenance costs.
MuleSoft supports the IBM i platform with its API management platform. You can also find IBM i support with some of the top-tier API management vendors, such as IBM with its Connect offering, CA Technologies and its Layer 7 offering, and Google with its Apigee offering.
APIs are a core enabling component of microservices. But increasingly companies are looking for microservices platforms to help accelerate the creation of a microservices architecture in their environment. One vendor developing such a microservice platform for IBM i is OpenLegacy.
The New Jersey-based company has been plying the application modernization waters for IBM mainframe and IBM i with its API-centric offering since it burst onto the scene a few years ago. At the time, the company was espousing its capability to re-package and expose business processes on IBM i and mainframe systems as individual SOAP and REST APIs.
But as momentum has built around microservices, OpenLegacy has adapted its API strategy and adopted the microservices approach to legacy modernization, according to OpenLegacy Chief Product Officer Zeev Avidan. “Two years ago we were at the beginning of that journey,” Avidan tells IT Jungle. But now we’re providing a complete microservice architecture out of the box.”
The company’s microservices-based application integration platform has several components, Avidan says. There’s a Java-based software development kit (SDK) that exposes an individual business process as an API and also allows users to add new capabilities, such as analytics or security. This JDK generates a standard Java object that be served from the IBM i server or any other environment with a JVM. The runtime environment instantiates what’s called a microservices “mesh” that allows the services to be invoked. There’s also a management console that lets administrators control what’s going on.
OpenLegacy is gaining traction with its microservice offering in the banking and insurance field, Avidan says. The company has multiple clients around the world that are exposing IBM i and mainframe business processes as microservices via REST APIs.
“It enables them to create digital offering and digital interfaces that pull data form their mainframe, and doing it without using any middleware,” Avidan says. “So they don’t need MQ or any of those things. It’s a direct connection. It’s scalable and it performs very well.”
There’s nothing stopping IBM i and mainframe customers from developing their own microservices. “It’s not impossible to do. You can absolutely create APIs using those techniques,” Avidan says. “The problem with that is all that work is manual.”
To get a headstart on microservices, many companies pay systems integrators to generate APIs for them, which they can then expose as part of a microservices architecture. While that can also work, it doesn’t leave the customer with the ability to change and adapt those microservices going forward, Avidan says.
“What you really need is not someone to go and build it for you,” he says. “What you really need and what our customers realize, is you need that muscle of creating the services yourselves, because that is a core competency today. If you’re not able to move fast and support the business in terms of creating those services, then that’s a problem . . . . You need the muscle and the best way to do that is to have a set of tools and technology to do it yourself.”
OpenLegacy isn’t the only vendor targeting IBM i APIs and microservices. Rocket Software also has an offering in this arena, called Rocket API, while LANSA also has the capability to generate RESTful services with its “low code” development environment. Rogue Wave Software‘s Zend subsidiary is also chasing the market with its XML Toolkit, and there are undoubtedly others.
Whichever tools and techniques you use to generate microservices, there’s a good probability that microservices will play a more prominent role in IBM i application modernization in the foreseeable future.
RELATED STORIES
Visual LANSA Goes Low-Code With High Tech Update
One IBM i Route Into the API Economy
Goodbye, Java Enterprise Edition. Hello, Jakarta EE
Don’t Be the Eeyore of Digital Progress, OpenLegacy Says
Should a company use microservices? Adrian Cockcroft, a microservices pioneer, warns that microservices are harder to manage than traditional monoloithic web apps. The major problem of monolithic web apps is the inefficiency encountered when a very large team is working on them which is not often the case. Microservices is a strategy that should be used after containerized web apps have been have hit a pain threshold because the monolithic web app has runtime efficiencies that are lost when microservices are used.