In today’s rapidly changing business landscape, organizations are constantly seeking ways to stay ahead of the curve and remain competitive. One key aspect of this is ensuring that their IT infrastructure is up-to-date and able to handle the demands of modern-day computing.
For many enterprises, the mainframe is still the strategic platform since mainframes are highly reliable and scalable, with a long history of proven performance and security, which makes them ideal for processing and storing large amounts of critical data.
In this blog, we will explore the modernization of the mainframe, including the latest advancements in technology and the benefits that come with it. We will also examine how enterprises can leverage the strengths of the mainframe to stay ahead of the competition and meet the demands of today’s business environment.
Architectural patterns and methodology
Recently, we delivered a challenging modernization project by implementing new “API layer” around existing mainframe applications. Legacy applications are often perceived as giant monolith from the outside perspective. Therefore, we had to simultaneously “break a monolith” and build a new “API layer”.
We thought about architectural patterns and styles that might be appropriate for the project. For endeavours of this size and complexity, you simply need to do that. Otherwise, you’re doomed. There were several important patterns and styles we chose to use, to make the whole story sustainable even with a lot of new tech.
We decided that applying the Strangler pattern would be a good approach here, given the specifics of the monolith we had in front of us.
The Strangler Pattern is an approach to modernizing legacy systems by gradually replacing or augmenting components of the existing system with new, modern components. It allows for a smooth transition from a monolithic architecture to a more modular and distributed architecture.
By using this pattern, we were able to gradually break down the monolith into smaller, more manageable services, without disrupting the existing functionality where z/OS Connect played a crucial role.
To support the Event Sourcing approach, we implemented an event store that captures all changes to the application state. This allowed us to reconstruct the current state of the application at any point in time, using the full history of events.
This is where an architectural pattern known as CQRS (Command-Query Responsibility Segregation) comes into play. We have already been experimenting with CQRS and Event Sourcing in our labs and pet projects for some time. The project context that was in front of us sounded just like the right kind of problem to be solved with these two. Axon Framework was the weapon of choice in this case, giving us both the CQRS and Event Sourcing infrastructure to build upon.
By combining these patterns and styles, we were able to build a sustainable and scalable architecture that could handle the complexity and demands of the project. The use of Strangler, Event Sourcing, and CQRS allowed us to break down the monolith, capture changes in the application state, and separate concerns between commands and queries, respectively.
Breaking Down Monoliths and Building API Layers
Mainframe clients are often looking for modernization to address several key challenges. These include the cost, the scarcity of skilled engineers, and the need to integrate the mainframe into a hybrid cloud.
Most of today’s enterprises have opted to modernize in place by reusing mainframe applications and infrastructure by enhancing applications, adding capabilities, modernizing user interfaces, etc.
The monolith in our project was a typical mainframe system designed for high volume transactional processing. Mainframe developers may find it challenging to break down a monolith as they are used to working with a traditional mainframe architecture that is not designed for microservices.
Applications are written in PL/I, running on z/OS operating system inside several CICS application regions and accessing Db2 databases. The business logic consists of hundreds of CICS transactions, thousands of Db2 stored procedures, Db2 tables with complex design and numerous referential constraints.
5 Easy Steps for Sustainable Modernization: The Secret Recipe for Breaking Down Mainframe Monoliths
These are the five easy steps to follow for success:
1. Identify all logical subsystems
The first step is to identify all the logical subsystems within the monolithic application. It is often the case that this is most difficult step because it involves rethinking of business processes and challenges established practices. This involves drawing hard boundaries between subsystems to enforce service layer integration instead of data level one both on technical and organizational level.
2. Find out which subsystem is owner of what data
The second step is to determine which subsystem owns what data, as this helps to ensure that data is accessed and managed appropriately by the different services. In this case, the hundreds of CICS transactions, thousands of Db2 stored procedures, Db2 tables, with complex design and numerous referential constraints would need to be carefully analysed to determine the appropriate data ownership and access.
3. Expose access to data trough service based (API) operations
The third step involves exposing access to data through service-based API operations, which enables the different services to communicate with each other and with other applications and systems. In this case, z/OS Connect acts as an API layer that sits between the legacy mainframe system and the new components.
4. Establish API governance
The fourth step is to establish API governance, which involves setting standards and guidelines for the development, deployment, and management of APIs. This helps to ensure consistency and quality across the different services. As a API developer, this would involve following industry best practices for API development and deployment, as well as ensuring compliance with any relevant regulatory requirements.
5. Introduce orchestration layer between new applications and legacy monolith APIs
Finally, an orchestration layer would need to be introduced between the new applications and legacy monolith APIs, which acts as a bridge between the modern applications and the existing mainframe application. This would involve developing an intermediary layer that can manage and monitor the APIs, as well as provide a centralized location for handling any issues that may arise.
Transforming Mainframe into a Microservices-based System with Streamlined DevOps and API Management
As a result, existing mainframe system is transformed and ideally positioned to provide solid foundation for future initiatives, such as introduction of Event Sourcing infrastructure.
New solution involved productizing the process of creating new services and APIs. Our team has built a system for provisioning APIs based on a desired state, with a central team managing the DevOps environment and syncing with liaisons in other teams. This approach has proven to be highly effective and has resulted in a capable and battle-tested group of consultants. In addition, we have implemented a robust API management system, with hundreds of APIs created and different governance policies applied to unique services exposed from the mainframe through glue code.
Future of Mainframe: Continuing to Thrive with Modernization and Innovation
Overall, as a system architect, modernizing an existing monolithic application running on a mainframe using a new API layer requires careful planning, design, and execution. However, by taking a modular, service-based approach and using modern technologies, it is possible to modernize the application while preserving its core functionality and value, and to support future growth and innovation.
It is clear that mainframe modernization is changing the paradigm. We are convinced that the mainframe will continue to live and thrive, despite some sceptics. The mainframe’s consolidated architecture with its high levels of security and low latency make it a valuable option for certain workloads that cannot be replaced by other architectures. Industries such as large banks, airlines, insurance companies, and governments will continue to rely on the mainframe for their operations. As we move forward, we aim to leverage the strengths of mainframe technology, such as its robust backend and high core transaction systems, and its unmatched security features, including its upcoming quantum-safe delivery.
By welcoming new and innovative ideas, whether from young people, experts, or technology advancements, the mainframe ecosystem can grow and evolve into an even better platform than it is today and have a very bright future.
How to implement Strangler Pattern using z/OS Connect
API Layer: z/OS Connect acts as an API layer that sits between the legacy mainframe system and the new components. It allows you to expose APIs for specific functions or services within the mainframe, encapsulating the underlying complexity. The API layer enables the new components to interact with the legacy system in a controlled and standardized manner.
Integration with Modern Technologies: z/OS Connect enables seamless integration between the new components and the existing mainframe system. It abstracts the underlying mainframe technologies and provides a RESTful interface that the new components can interact with. This allows the new components, which are often built using modern technologies, to communicate with the legacy system without directly accessing its internal workings.
Gradual Replacement: The Strangler Pattern emphasizes a gradual replacement of components over time. With z/OS Connect, you can start by identifying specific functions or services within the mainframe system that you want to modernize. You can then create APIs using z/OS Connect to expose those functions and gradually replace them with new components. This incremental approach minimizes risks and allows for a smooth transition.
Coexistence of Legacy and Modern Components: During the modernization process, the legacy mainframe system and the new components need to coexist and work together. z/OS Connect facilitates this coexistence by providing a bridge between the two. The API layer allows the new components to consume services from the mainframe system, making it easier to integrate and gradually replace functionality without disrupting the overall system.
Scalability and Performance: As the Strangler Pattern involves the integration of new components with the existing mainframe system, scalability and performance are essential considerations. z/OS Connect is designed to handle high volumes of API requests and ensures the performance and scalability of the overall system. It can efficiently manage and distribute the incoming requests to the appropriate mainframe services, allowing for efficient utilization of resources.
Looking to modernize your mainframe infrastructure but feeling overwhelmed by the complexities and challenges of integration? Our team of expert engineers is here to help!
