Microservices Give COBOL New Life on the Mainframe – InApps 2022

Mainframes, legacy systems, and COBOL are getting a bad rap that they just don’t deserve.

COBOL is still a common, business-oriented language, contrary to the reports of its demise at the hands of JAVA, Python, and Ruby. COBOL is easy to learn and easy to read and it delivers high performance when compiled.

COBOL is no longer hip or trendy because it never was nor had to be. But, the fact is, it’s still critical to running most of the world’s established organizations and their reliable mainframes. While everyone likes to improve the status quo, the fact is that COBOL has been the status quo for more than 50 years because it works.

According to the latest statistics from Tutorial Brain, more than 100 billion lines of COBOL code are being used in thousands of mainframes all over the world. 70 percent of the zettabytes of data around the world are still stored on mainframes, 2 million people around the world still code in COBOL, and systems migrated from COBOL end up having to revert to COBOL to continue running.

An Oldie but Goodie

COBOL got a bad reputation because it is associated with mainframe systems. Mainframes aren’t the bad guys, though. They’re the workhorses of most international organizations, especially within the Fortune 500 companies and the organizations managing the stability of the world’s economies.

COBOL applications were written to be secure, stable, and high performing – and, no, they were not written for web, mobile, IoT, or cloud. COBOL to mainframes – great! COBOL and mainframes to web — not so good.

Companies felt stifled by their legacy systems as they weren’t able to link to the latest software. Thus, ESB/SOA middleware was developed to serve as the intermediary connector between legacy systems and “modern” applications.

As the only tool available at the time, middleware performed more than adequately. The critical word here is “adequately.”

Middleware — Time to Move on

SOA and ESB middleware used to be the best alternative available, but now new approaches bridge the legacy systems to the modern world of the web, mobile, and cloud in a way that makes everyone happy — the legacy people and the teams responsible for the future, like the enterprise architects  and DevOps teams.

If you look into a crystal ball, you’ll may actually see the death of ESB and SOA, not legacy systems.

The problem with middleware is that over the decades it has become an amalgam of enterprise service buses, object request brokers, APIs, and other specialty hardware and software. Every time a new application is added or modified that needs to connect with the legacy system, the middleware needs to change as well. Middleware changes require extensive code creation, QA and testing in both staging and production. This adds a significant amount of time, complexity, money, and resource requirements to any attempt to modernize.

The addition of middleware, extract layers, and silos all add to the brittle nature of these applications. You end up with a tightly structured rubber band ball, where every band needs to be adjusted to make any change. Each layer between you and the system of record slows down your ability to change, slows performance by increasing latency, and introduces more places where something can break.

COBOLing the New Path

Cloud, mobile, and web apps are cool. Mainframes are definitely not cool — and middleware is even less so. Trying to satisfy the demands of digitally impatient millennial consumers with the latest apps quickly, efficiently, and cost-effectively isn’t possible within a traditional legacy system-middleware-modern application infrastructure.

COBOL has served mainframes well for more than 50 years. It still does exactly what it was created to do — manage the business processes within exceptionally stable mainframes. Modern applications take that information and quickly and easily deliver it to customers, using the latest programming languages. But what to do about middleware? Bypass it completely.

You no longer need the ESB middleware; it does not provide any additional value in the digital economy. Even retailers are changing their stores from buying “things” to buying experiences — adding value as part of the process. If your company does not accept this model, then your competition will pass you by.

Think Micro

ESB middleware takes all the information from the mainframe and passes it to the application, whether it needs it or not. In addition to “overwhelming” the app with data, it can cause significant security and privacy risk. Middleware, too, requires highly specific skill sets, which may not be easy to find; the cost of resources to support the infrastructure adds up; and the time for test, QA, etc. limits speed to market. And, of course the cost of an ESB/SOA in a major organization can cost millions of dollars per year.

Instead of being constrained by middleware infrastructure, consider microservices instead. Microservices are very specific instructions to the mainframe to deliver very specific information to the application. For example, one microservice might request a username and password, another microservice might retrieve the current account balance. These functional application building blocks are represented as easily consumable, focused, and secure APIs that can seamlessly accommodate orchestration to enable the development of new capabilities.

Service-oriented architecture is not living up to its promise; microservices can deliver on that promise.

Conclusion

Using microservices instead of ESB/SOA middleware significantly accelerates testing and implementation, allowing organizations to deliver information to their clients quickly. Microservices allow even the largest, well-established companies to adopt continuous delivery and agile development — all while depending on good, old fashioned COBOL to manage the original information.

Feature image via Pixabay