The Opportunity in App Modernization

Situation

App modernization is now a buzz word similar to Devops or SRE or Cloud Native. The word means different things to different people. Ask a Platform Engineer and he would explain modernization as lift and shift of VMs from private cloud to public cloud.

Ask a developer and he will refer to modernization as the containerization for legacy apps. A software architect may define modernization as the refactoring of an application to 12 factor/15 factor microservices.

All the major enterprise vendors are in a headlong rush to help enterprises modernize workloads along all layers of the IaaS, CaaS and PaaS stack. How does one break down this market opportunity?

There are multiple market conditions at play that trigger the refactor and upgrade of applications to cloud-native and the cloud.

1. Legacy Middleware

A significant percentage of customer application estate are legacy non cloud native apps running on non-microservices frameworks on proprietary app servers. These applications could be massive monolithic Struts apps with backend logic running on WebSphere or WebLogic.

The Jakarta EE Developer survey has indicated that 85% of users in the standards space are on a programming model from 3+ years ago. Almost 50% on one 7+ years ago. Monolithic apps on legacy servers slow down the releases of new features and significantly increase the lead time.

Developers get tired waiting for a app restarts that take 1-5 mins and an inner loop developer experience that ties them to older JavaEE frameworks and app server libraries. The app restart and footprint problem has largely been solved in the modern variants of all the application servers; however, it takes time to migrate existing applications to the latest Eclipse Glassfish or OpenLiberty.

Image source: Jakarta EE Developer Survey 2020

Proprietary Application Servers represent a cost and systems vital to an enterprise business. Application Server specialists have left the companies both at the Infrastructure and Developer tiers. Finding IT staff to maintain these systems is becoming costly. Systems and app server and JDK versions are not updated leading to audit and governance challenges. Java applications built using older J2EE framework Technologies like Struts, EJBs, JAX-RPC, etc. are difficult to upgrade and have accumulated technical debt. Applications also use underlying services or customized frameworks which were homegrown to integrate these applications.

2. Legacy Java

Most Enterprise workloads are still on Java 8, Java 7 and Java 6 and on their way migrating to Java 11/14. Customers need our help in migrating their apps to Java11 and Java14 to leverage the containerization hooks provided by later versions of Java.  Older versions of Java prevent platform upgrades and are generally not container friendly from a memory perspective.  Older versions of Java are also a source of security vulnerabilities.

Image source: Jakarta EE Developer Survey 2020

3. Legacy Spring

Spring Framework and Spring Boot are the # 1 Java microservices framework in the enterprise. Lack of CI/CD practices and application architecture governance have led to applications using older versions of Spring Framework (< 5) and Spring Boot (< 2). Enterprises need help in upgrading and patching their versions of Spring. This is an issue that will come to bear when Spring Boot 2.1.x will EOL on Nov 1st, 2020 and Spring Boot 1.x has already EOLed on Aug 1st, 2019. Enterprises who have a rigorous security posture will want to upgrade ASAP to supported releases of Spring and Spring Boot. An older version of Spring and Spring boot prevents enterprises from using the latest frameworks like spring-cloud and other downstream spring projects that accelerate microservices development.

Image source: Stack Overflow Trends

An opportunity exists to automate the toil in the migration of framework and spring boot components for existing Spring apps. Instead of reading and implementing a multi-page guide, developers can run a spring linter to upgrade their framework components.

4. Monoliths to Microservices & Microservices to Modular Monoliths

Recent developer surveys by Jetbrains and Jakarta EE confirm that microservices are the leading architecture for implementing Java systems in the cloud however; enterprises are still lifting the yolk of monoliths. Domain Driven Design and modeling techniques like SWIFT, Wardley Maps, Bounded Context Canvas have provided the technical and business heuristics in carving out microservices. There is however an emerging backlash from the complexity of microservices and an impetus to move towards simpler deployment architectures like modular monoliths. See To Microservices and Back Again.

There are significant gaps that libraries and frameworks can fill by driving a backlog of stories and implementation from event storming or monolith decomposition. Generating a backlog of user stories and epics from event storming is a work of art and requires heavy facilitation because DDD Is Broken. Dividing business capabilities in sub-business capabilities is tough and candidate microservices need expert judgment before implementation. Observability tools and frameworks that aid in understanding the existing application runtime metadata paired with a profiler theoretically have the information needed to make recommendations on starting points to decomposing monoliths. A tool that has started to look at this problem is vFunction.

Image sources: JetBrains Developer Survey, Jakarta EE Developer Survey 2020

Combining profiling instrumentation, CI/CD metrics and SLO measurements can guide the rationalization of microservices by analyzing metrics like change failure rate. This is a process that is facilitator heavy and driven by workshops like the "Should That Be A Microservice?".

5. Fragmentation in the Java EE, Jakarta EE & Eclipse MicroProfile Microverse

Eclipse and Oracle were unable to agree on terms for javax package namespace and trademarks. As a result of which all the JavaEE apps now must migrate Jakarta EE. App server vendors are rushing to add Jakarta EE support to their app servers. Jakarta EE is taking off. Applications coded on the javax namespace can run without changes on TomEE, OpenLiberty and others with eclipse transformer that bytecode-rewrites Jakarta EE 8 references to Jakarta EE 9 and patch plugins that provide supplemental bytecode transformation based on ASM to handle edge cases.  The other option is for applications to recode using the Jakarta EE APIs using tools like tomcat-Jakarta EE-migration.

For conservative enterprises, the transition from Java EE to Jakarta EE requires a regression testing effort and deployment on newer vendor app servers and a whole bunch of bytecode rewrite magic OR code rewriting to address the confusion created by Oracle.  Enterprises have other things to invest in instead of worrying out functional compatibility and regression with a new version of Jakarta EE. This presents an opportunity for additional tooling and/or products in this space.  

Image source: Transition from Java EE to Jakarta EE

Eclipse MicroProfile is evolving at a faster rate than Jakarta EE. Six major MicroProfile releases with sixteen component releases in less than two years whereas JavaEE/Jakarta EE is evolving at the rate of consensus across standards bodies. It seems that most of the innovation in the standards space will first occur upstream in MicroProfile and then trickle down to Jakarta EE. For the foreseeable future Eclipse MicroProfile will be separate and build on top of Jakarta EE.  Kevin Sutter – the Eclipse MicroProfile co-lead and EE4J PMC member writes in What's next for MicroProfile and Jakarta EE?

Until Jakarta EE has demonstrated a specification process that allows the rapid, innovative aspects of the MicroProfile project, MicroProfile will maintain its own project dynamics distinct from the EE4J projects.

Image source: What's next for MicroProfile and Jakarta EE? (Eclipse Newsletter)

The API fragmentation between Jakarta EE and Eclipse MicroProfile frameworks with differing rates of change provides an opportunity for simplification.

6. VMs To Containers & Kubernetes (V2C / V2K)

This is the holy grail of Kubernetes vendors. A tool that automagically creates containers from VMs. Not just system containers but app level containers that have knowledge of the underlying middleware. A tool that can discover, analyze and repackage existing applications to take advantage of the elasticity, fault-tolerance, density and upgrades/patching offered by the cloud. A tool that understands application and language specific frameworks to containerize and build the right OCI compliance layer caching efficient images. Such a tool is akin to a magical unicorn.

There are a variety of tools that assist in building images securely from source like S2I, Cloud Native Buildpacks and maven plugins like jib and maven/gradle build-image tasks and goals; however these require some kind of manual intervention. Infrastructure driven bottom up modernization loves to deal with workloads without talking to developers with preferably zero changes to code with least amount of risk. Platform engineers dream of a VM2containers or VM2kubernetes product that serves the needs of the Infrastructure team enabling them to lift n shift massive workloads with minimal developer intervention. Google Anthos Migrate and Docker have made valiant efforts to solve this problem. Amazon also has recently joined the party and introduced a slew of tools in this space like AWS app2container, docker2aws and co-pilot that help in the containerization of apps to land them on ECS and EKS.

Value Capture

How can vendors take advantage of these tailwinds by creating a suite of products that address the unmet needs and the challenges faced by app modernization developers today. What products can enable developers to migrate their applications to cloud native architecture and microservices faster and alleviate the pain described above.

1. Cookbooks

App modernization recipe cookbooks like appmod-recipes and well-architected-framework gathered over years of past app migration engagements can serve as a force multiplier when it comes to developer adoption and productivity.  Documentation of patterns that helps cloud architects in migration with a well-structured approach to app modernization with a solid cookbook of app migration recipes will lead to developers not wandering in stack overflow and increase the productivity of migration by large System Integrators. Investment in the App Transformation Cookbook by a dedicated writer paired with the domain expertise of the App Modernization Team will lead to an acceleration the quality and quantity of Transformations making it easy for ordinary developers to migrate apps to cloud-native without heavy consulting lift. A high-quality set of recipes cataloging the migration from legacy component framework will also serve as the blueprint for transformation tooling.

2. Super (Rewrite) Linters

A command line tool packaged as a linter or a command line executable that provides a rewrite engine and a DSL for code transformation. The rewrite tool acts as a super linter that automates the replatforming of legacy applications and reduces technical debt. The Rewrite linter directly modifies the source files, including Java, XML, and YAML using a JavaParser library to parse Java sources files. Modifications are made and directly to the abstract syntax tree, so the result is always syntactically correct and serialized for persistence and provenance. The intent is to automate the toil of replatforming to modern microservices frameworks and leave the app in a compileable state. A tool that starts to implement this concept is open rewrite.

3. Adversarial Interoperability

This is a technique that is leveraged by hyperscale cloud providers to offer domain or product specific APIs like for Cassandra or mongo but have the underlying implementation provided by native products. For instance, Azure Cosmos DB provides an API for MongoDB leveraging the MongoDB wire protocol compatibility. Upstart frameworks can attack incumbents with this play. For instance, Quarkus provides a compatibility layer for Spring dependency injection in the form of the spring-di extension. Quarkus Spring API compatibility includes Spring DI, Spring Web, and Spring Data JPA. Additional Spring APIs are being planned like Spring Security and Spring Config. See Quarkus For Spring Developers.

Summary

The average developer spends 13.5 hours a week paying down technical debt. [Source - Stripe survey]. The twin pressures of servicing apps running in production and modernizing them to the cloud are putting stress on development and platform teams. App Modernization needs to scale and made efficient through documentation, products and frameworks. It is time vendors to step up and for enterprises to invest in Migration & Transformation as a Service to accelerate the partial or full modernization of app workloads to the cloud. Enterprises that focus on the onboarding of workloads to the cloud will address the competitive their threats by improving developer productivity, reducing technical debt and utilizing the cost efficiencies and flexibility of the cloud.

About the Author

Rohit Kelapure is an expert on migrating applications to the cloud and modernizing mission critical systems. Rohit has formulated GTM, marketing and product strategies for Application Modernization. Rohit is continuously improving offerings & systems to support sales, delivery, and open source communities in driving the right customer outcomes. Rohit actively blogs on cloud foundry, kubernetes, refactoring monoliths and app modernization strategies. Rohit's recent webinars include topics as diverse as middleware modernization, mainframe migration and tools & recipes to replatform monolithic apps to modern cloud. Rohit is an expert at both Spring and Java EE technologies and has covered both topics extensively on his WebSphere and All Things Cloud blogs. All opinions are my own and not my employer's.