Monoliths, Microservices, And IBM i Modernization: Part 1
October 7, 2019 Alex Woodie
What’s the best approach for application modernization: Maintain the monolithic architecture, or break it into individual microservices? This is an important question, especially for IBM i shops that are looking to take their considerable investment in encoded business logic to the next level.
At first blush, the answer seems obvious: Monolithic architectures are bad, and microservices are good. Monolithic architectures, which are still quite prevalent in the IBM i world, proliferated from the 1970s well to the 2000s thanks in part to the popularity of packaged ERP suites that automated a multitude of processes and also to the programming inclinations of in-house development staffs.
Even after the client/server revolution brought us the MVC (model, view, controller) view of the world, monolithic application architectures continued to be used, especially in pockets of the IT community that proved resistant to change, such as the IBM i and mainframe worlds. But in today’s Internet-connected world, developers have largely moved away from the big monolith in favor of more nimble approaches.
The biggest drawback with the monolithic approach is that it’s hard to change or update the code behind the application. In a monolithic architecture, the code for key elements of the application – including business logic, database access, and delivery of user interfaces (UIs) and application programming interfaces (APIs) – is jumbled up together in one tightly intertwined ball of code.
Monolithic architectures combine core elements of an application together. (Image courtesy Scalyr)
Monolithic architectures were great 30 years ago when computing resources (that is, CPU, memory, storage, and network) and the human resources (i.e. programmers and administrators) were constrained, and the business requirements didn’t change that quickly. A small team of capable professionals could develop, test, deploy, and maintain the programs needed to run the business, while companies that relied on packaged applications could get everything they needed from one supplier and focus their resources on their own business. When one or more of the applications ran out of headroom, you got a bigger server.
As the IT world grew more sophisticated, the drawbacks to the monolithic approach started to show. While intertwining the application, database, and display logic may have appeared an efficient approach when the application was first devised, unraveling that spaghetti code to integrate a third-party application turned into an absolute nightmare. Companies that wanted to, for example, plug a CRM or marketing application into their core financial packages had to extricate the necessary interfaces. It was a great make-work program for consultants, but not so good if business efficiency was the primary goal.
The state-of-the-art in development today is to use a microservices approach, where the programs or applications supporting individual business processes are broken up into individual components. When the company needs the service of an individual application or program, it uses an API, most often of the REST variety, to call that microservice into action.
Microservices-based architectures hold many advantages over monolithic architectures. From a developer point of view, each microservice can be modified and updated as needed, and as long as the API doesn’t change, it doesn’t impact the other microservices. This allows for an increased development tempo and a faster cadence of delivery of new capabilities in support of the business.
Administrators also benefit in the management of microservices. If one microservice malfunctions, it can be turned off, thereby allowing the overall application to continue running, albeit without that specific function. The individual microservices can also be scaled independently, providing more granularity on how they impact the underlying physical servers, whether on-prem or in the public cloud.
In a microservices architecture, the core elements of an application are broken up into smaller pieces. (Image courtesy Scalyr)
Many microservices today are running in virtualized environments called containers. Docker, for example, develops container technology that makes it easy for users to replicate and rollout entire platforms, complete with specific iterations of operating system, databases, Web server, and other middleware. These Docker containers can then be orchestrated (that is, instantiated, scaled up, killed, or moved) on clouds or within on-premises infrastructure as the user sees fit.
Microservices running on containers sounds like the way to go, right? It seems like a no-brainer to go this way, especially considering the pace of technological change today and the availability of powerful open source tooling for creating compelling applications, not to mention all the slick Web and mobile GUI technology and all the tools for managing REST connections (not to even get into what’s going on with Apache Kafka or GraphQL, which provide other compelling approaches for building microservices).
One of the early advocates of microservices in the IBM i world is OpenLegacy. The company has developed software that does much of the work of encapsulating IBM i and mainframe business logic as microservices, and then exposing those microservices to the world using the customer’s choice of REST or SOAP protocols.
“We have pretty dramatically doubled down on the concept of microservices, and microservice architecture,” Zeev Avidan, OpenLegacy’s chief product officer, told IT Jungle in 2018. “It’s what the market is moving toward. We see everybody moving toward microservices basically as a way of figuring out why API strategies were not as successful as people were hoping.”
Other IBM i vendors are also moving in that direction. Rocket Software has created something called Rocket API, which allows users to create REST data streams from the output of RPG and COBOL applications. Rocket API is being incorporated into modernization plans, the company says.
“Rather than embark on the risky and expensive path of moving platforms,” Rocket’s Dan Magid said in 2017, “they are now focused on leveraging that IBM i value while using Rocket API to expose those application functions and that IBM i data via new technology and interfaces.” (Magid has since left Rocket to found Eradani.)
Midrange Dynamics is also getting into the microservices groove with its recent acquisition of Rest4i, a company that developed a tool for exposing IBM i business logic using REST, the lingua franca of microservices.
In part two of this series, we will explore some of the downsides of the microservices approach as it pertains to modernizing IBM i applications.
RELATED STORIES
Midrange Dynamics Dives Into REST With Acquisition
