Application Modernization is often seen as an essential element of Digital Transformation initiatives. Java has been a mainstay of traditional Enterprise applications and understanding how to evolve applications built on WebSphere and other Application Servers is essential to keeping complexity and costs in check while tackling new business initiatives. 'Modernization' initiatives will therefore focus on keeping the same application functionality but seek efficiency gains that will result in lower total cost of ownership. 'Transformation' initiatives in contrast will involve a more fundamental change in the nature of the application that will better enable it to meet future business needs by increasing agility to boost innovation. Clearly this is a journey and the available 'landing zones' continuously evolve. The recent announcement of WebSphere Hybrid Edition reflects the needs of Enterprises to tailor their own path for their modernization and transformation initiatives and builds on previous generations of Application Platform capabilities ie. IBM Cloud Private and Cloud Pak for Applications. The 3 fundamental facets of modernization (introduced in this blog) that Hybrid Edition facilitates are outlined below and shown in Figure 1
- Modernize Operations => Lower Total Cost of Ownership (TCO)
- Modernize Runtime => Reduce Technical Debt, dependency on old standards and APIs, leverage new capabilities
- Modernize Architecture => Become more Agile and deliver faster in smaller increments with better resiliency
A desire to adopt modern application architectures will drive a need for modernizing operations. Modernizing operations through containerization will drive a need for lightweight container optimized runtimes. Adopting containerized runtimes will also make adoption of modern application architectures like microservices easier. It's clear that getting this virtuous cycle going requires Culture and Process change, but getting the technology choice right is a big factor in whether that succeeds or fails. The goal being that modernization proceeds on an Application by Application basis once the fundamental tenets are in place. See blog series by Kyle Brown and Kim Clark on what the journey to becoming cloud-native entails.
The process of Operational Modernization to containerize workloads involves the adoption of a Kubernetes-based platform, such as RedHat OpenShift Container Platform. This will involve the strategic decision whether to adopt a Private Cloud, Public Cloud or Hybrid approach. See blog by Eric Herness from Cloud Engagement Hub which addresses this topic.
Runtime Modernization involving moving workloads from traditional monolithic application servers to a modern lightweight full-Java runtime. See blog by Graham Charters on the features of Liberty that make it ideal for a variety of Architecture styles that your existing workloads may adopt as they are modernized and transformed.
Architecture Modernization involves refactoring a monolith application into smaller, more manageable units (e.g. Macroservices or Microservices) with the primary goal of increasing team autonomy and speed-to-market. See blog by Kyle Brown on the topic of granularity of those units and blog by Holly Cummins on the culture change, risk management and importance of automation.
Modernization projects are multi-year journeys and tooling is essential to provide continued momentum. WebSphere Hybrid Edition modernization tools include IBM Cloud Transformation AdvisorTM and IBM Mono2MicroTM and Figure 2 shows the use cases addressed by each of the tools at each phase. 'Advise' use cases will aid in planning activities and 'Move' use cases as the workload is adapted to the new landing zone.
Operational and Runtime Modernization can be seen as foundational for Architecture Modernization during the Move phase but Advise use cases can and should proceed concurrently for the business critical Applications that require it. Transformation Advisor takes an Enterprise wide view from an operational perspective and gives an understanding of how decisions on the makeup of the modernization 'landing zone' will impact the work required for Applications that might run there. Mono2Micro starts from the Line-of-Business (LOB) application perspective and helps determine how partitioning the application will help it take best advantage of the new landing zone so that the LOB can be more responsive to customer needs. Once the landing zone is ready the tooling helps reduce the translation work required to build, test, deploy and run the application effectively there.
Mono2Micro identifies high cohesion, low coupling components.
Using a combination of Runtime Traces, Business Use Case and class dependencies input, the Machine Learning algorithms identifies ways to cluster the classes together to 'partition' the application. The user can interactively refine the recommended partitions in the intuitive graph based UI trading off optimal Business Use Case partitioning and one that follows 'natural seams' once code dependencies are taken into account. Figure 3 shows an example of the graph for a sample application, whereby classes are shown as nodes and edges represent the volume of calls during runtime.
Generated Microservices ready to be deployed
Once the desired partitioning has been decided, Mono2Micro can auto-generate the code injections required for inter-partition communication once each partition is packaged into it's own microservice. Figure 4 below shows an example of how the monolith code is partitioned for building as independent containers and generated code for client calling remote micro-service over REST.
The role of AI
IBM's approach to AI is to augment not replace human experts and thus AI in Mono2Micro assists architects doing application transformation. It is not a magic tool that transforms monolithic applications into microservices but a tool that helps in the process of decomposing large applications allowing architects to focus more on the desired end state of the application and organisational responsibilities around it.
Starting from the current state of the application code and automated tests, it allows decomposing the code into 'partitions' that can run in independent containers. This step is 90% automated by Mono2Micro generated scaffolding code for communication between the partitions, allowing a developer to easily standup the partitioned application and validate it with the existing test suite. These partitions can then be further evolved into independently deployable microservices following the new container container based Continuous Integration methodology. It is likely that the scaffolding code, application code and test code will need to be further adapted at this stage in order to ensure good performance and correct error handling to account for the now distributed nature of the communication and Mono2Micro recommendations guide developers to pay attention to those areas.
The application of AI into IT processes is a very exciting area as IT becomes more and more automated with Cloud infrastructure and cloud-native methodologies. AI being able to understand code is fundamental for practical application to Enterprise IT and a tenet of IBM's 'AI for Code' initiative. Following an extensive beta program, availability of Mono2Micro in WebSphere Hybrid Edition is a significant milestone in this journey.
Get started with the 90-day free trials for Mono2Micro and Transformation Advisor and kickstart your modernization and transformation projects with WebSphere Hybrid Edition.
Other Useful Links:
•IBM Developer Blog Series
•Mono2Micro Online Lab
•AppTransformers Channel on IBM ExpertTV