Monoliths, Microservices, and IBM i Modernization: Part 2

October 14, 2019 Alex Woodie

Microservices are the future, right? After reading part one of this series, you can be excused for thinking that. Breaking up applications into smaller components brings clear benefits to both the development and operations staff, and clearly is an architectural approach that has a lot of momentum. But it turns out there might be practical limits to how far the microservices approach can take us.

“Loosely coupled, yet tightly integrated.” That phrase became something of a running joke at an Infor conference attended by this reporter several years ago. The company at the time was betting heavily on its ION technology to connect its IBM i ERP applications into the big, bold future of add-on technologies.

While it’s unclear how successful ION has been in getting Infor’s IBM i customers to open up their pocketbooks, the concept of “loosely coupled, yet tightly integrated” has taken off in the wider world, particularly with the advent of microservices and the surrounding cast of cloud, serverless, and container characters.

Microservices and related technologies and techniques bring plenty of benefits. By isolating the code for specific processes into individual microservices with a consistent API, integration becomes easier. For operators, the code isolation helps to prevent issues with one microservice from impacting other microservices, and potentially bringing down the whole application. The approach also bolsters the potential to scale individual microservices up and down in response to dynamic demand.

For all the benefits of microservices, there also are some drawbacks that application architects and developers should be aware of before they step foot into the brave new world. The end goal might be to create a mesh of services that are “loosely coupled, yet tightly integrated,” but there might be architectural tradeoffs that need to be accounted for.

According to Anton Kharenko, who is now a senior software architect at Amazon, the additional complexity of managing a distributed system, as a microservices-based application architecture invariably brings, can be a real burden on developers.

“You need to choose and implement an inter-process communication mechanism based on either messaging or RPC and write code to handle partial failure and take into account other fallacies of distributed computing,” he writes in an insightful 2015 piece (he was employed at Playtech at the time).

Microservices are widely used in the emerging cloud architecture. (Image courtesy microservices.io)

The distributed nature of microservices also leads to a higher number of databases, and the advent of databases that are distributed, which may aggravate an organization’s data silo problem. Say goodbye to having a single database of record that multiple applications touch. In microservices, each service gets to use its own database, ideally one that’s tailored specifically to what it needs. You can, of course, try to maintain a record of transactions in a central data store, but that requires more integration code to write and brings with it complexity for the developer to manage.

“Business transactions that update multiple business entities in a microservices-based application need to update multiple databases owned by different services,” Kharenko writes. “Using distributed transactions is usually not an option and you end up having to use an eventual consistency based approach, which is more challenging for developers.”

(It’s somewhat ironic that the cutting edge of development in the IBM i world calls for developers to make greater use of the Db2 for i database, whereas the wider IT world is moving the opposite way. Instead of writing business logic in RPG, Java, or other high-level language, many experts from IBM and other companies say users should be striving to encode as much logic into the database using stored procedures, constraints, triggers, and user defined functions. However, with the current explosion of database types and the relaxing of schemas and constraints with NoSQL, much of the work is being pushed out of databases and back into the developer’s hands and code).

One of the advantages of microservices is fault isolation, but that advantage can turn into a drawback when it’s time to test new or modified code in a real-world setting (or as real-world as can be simulated in a test environment). “For a similar test for a service, you would need to launch that service and any services that it depends upon (or at least configure stubs for those services),” Kharenko writes.

Kharenko also points out that a microservices architecture will require a service discovery mechanism, as well as an automated IT monitoring system. When the number of microservices and all underlying containers and serverless applications grow to a certain point, it becomes impossible for a human to keep track of it all, or even for traditional IT monitoring tools to do so (thanks to the inherent complexity of Kubernetes and containers). Thus, from the IT well of need, has sprung a brand new application category: AIOps, which uses machine learning technology to detect anomalies in monitored systems.

AIOps uses machine learning to monitor and sometimes help manage complex, modern applications, including those based on microservices and cloud architecture. (Image courtesy Gartner)

Any application that requires multiple microservices will necessarily bring more complexity. Managing the microservices, as well as the databases that underlie them, will require more careful planning.

In a recent conversation with IT Jungle, Brad Schick, the CEO of Skytap, recently made some interesting comments about the ease of moving old IBM i applications developed with the monolithic architecture to the cloud versus newer and more “modern” applications created using the latest distributed techniques (Skytap’s claim to fame is helping companies move complex, heterogeneous applications that touch multiple systems, often older and established enterprise system, into private and public cloud environments.)

“An interesting quality of i is they tend to be fairly self-contained,” Schick said. “That system was designed to be monolithic and do everything you need for a certain task. Something interesting that we’re learning is that those system tends to be easier to move, because they tend to be more self-contained, whereas AIX or other Linux variants, or Windows, tend to be part of more complex distributed systems or client-server systems that can take a little more effort to migrate to the cloud. Even when it’s a cloud service like Skytap that can run natively, they tend to have lots of dependencies, whereas IBM has a little bit less.”

Clearly, there are certain advantages to simpler approaches, and monolithic architectures are simpler, in some ways, at least compared to their newer microservices-based cousins. Certainly nobody planned it that way back when the monolithic approach was in full swing. And this one benefit of monolithic architectures certainly doesn’t eliminate the other real benefits that microservices can bring. But it does show that there’s rarely one right answer or one correct way to do things.

In the end, the enlightened IBM i shop should weigh the benefits of adopting a microservices approach against the costs, and do so within the context of its particular business. There invariably will be some pieces that are best left alone.

RELATED STORIES

Monoliths, Microservices, And IBM i Modernization: Part 1

Midrange Dynamics Dives Into REST With Acquisition

Modernizing IBM i Apps with Microservices

Rocketing Ahead With An API Engine