• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • 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

    Modernizing IBM i Apps with Microservices

    Rocketing Ahead With An API Engine

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags: Tags: API, COBOL, IBM i, microservices, REST, RPG, SOAP

    Sponsored by
    TL Ashford

    TL Ashford writes software to generate Barcode Labels and Forms for the IBM i.

    Our software products are the most feature-rich, cost-effective solutions available!

    TLAForms converts traditional IBM i spool files into high quality, professional forms that are output as PDF documents. A form is associated with a spool file and the form is designed. TLAForms then ‘watches’ the IBM i output queue for a new spool file to be generated. When a new spool file is generated, TLAForms reads the data from the spool file, places the data on the form, and outputs a PDF document. The PDF documents can be archived to the IFS, automatically emailed, and printed.

    Features:

    • Select Data directly from an IBM i Spool File
    • Burst IBM i Spool Files based on page or Spool File data
    • Add spool file data to form as Text using a wide variety of fonts and colors (the MICR font for printing checks is included in the software)
    • Add spool file data to form as bar code – including 2-dimensional bar codes PDF-417 and QRCode
    • Configure SQL statements to retrieve and use IBM i File data on forms
    • Utilize Actions to show or hide objects on the form based on data within the spool file
    • Import Color Graphics
    • Use Color Overlays
    • Create Tables
    • Forms can be archived to the IFS
    • Forms can be emailed automatically
    • Forms can be printed to any IBM i, Network or Windows printer
    • Forms are automatically generated when a new spool file is generated in the IBM i output queue
    • NO PROGRAMMING required
    • On-Line Video Training Library

    Learn more about TLAForms at https://tlashford.com/tlaforms/

    Barcode400 is native IBM i software to design and print labels directly from your IBM i in minutes! Compliance and RFID labeling is easy using Barcode400’s tools and templates.

    Features:

    • Software resides on the IBM i
    • IBM i security and Backup
    • Labels are centrally located on the IBM i
    • Label formats are available to all users the instant they are saved – even in remote facilities
    • GUI designer (Unlimited Users)
    • Generate Labels as PDF documents!
    • Print to 100’s of thermal transfer printers
    • Print to HP and compatible printers
    • Print labels interactively – No Programming Necessary!
      • OR Integrate into existing application programs to automatically print labels – Barcode400 has been integrated with nearly every ERP and WMS software available on the IBM i, including thousands of in-house written applications.
      • On-Line Video Training Library
      • Free Compliance Labels
      • Generate Checks using the MICR font
      • RFID Support (optional)
      • History / Reprint Utility
      • Integration Assistant
      • Low Cost (no tiered pricing)

    Learn more about Barcode400 at https://tlashford.com/barcode400/

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Guru: Edit Result Sets in Run SQL Scripts Sometimes Even DIYers Need A Little Help

    Leave a Reply Cancel reply

TFH Volume: 29 Issue: 57

This Issue Sponsored By

  • ARCAD Software
  • Profound Logic Software
  • WorksRight Software
  • Computer Keyes
  • Manta Technologies

Table of Contents

  • Sometimes Even DIYers Need A Little Help
  • Monoliths, Microservices, And IBM i Modernization: Part 1
  • Guru: Edit Result Sets in Run SQL Scripts
  • Automation For The Masses – Here Come The Bots
  • Power7 And Power7+ Will Truly Be Dead At The End Of 2020

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • Power10 Midrange Machine: The Power E1050
  • IBM Puts The Finishing Touches On PowerHA For IBM i 7.5
  • Guru: Regular Expressions, Part 2
  • Get Your Security Education, And Not From The School Of Hard Knocks
  • IBM i PTF Guide, Volume 24, Number 33
  • Power10 Entry Machines: The Power S1024 And Power L1024
  • Thoroughly Modern: Latest IT Trends – Bring Security, Speed, And Consistency To IT With Automation
  • Big Blue Unveils New Scalable VTL For IBM i
  • As I See It: Thank God It’s Thursday
  • IBM i PTF Guide, Volume 24, Number 32

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2022 IT Jungle

loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.