The Whys And Hows: “Platform Switch” For Enterprise Java Apps

Enterprises today are keenly focused on digital transformation—powering new customer experiences through software. The key word for the enterprise here is “transformation”, as enterprises have systems already powering their business. In order to modernize them, enterprises must embrace a “Platform Switch.”

Platform Switch is the evolution of the Application Development stack from Java EE + Application Servers (WebLogic/WebSphere/JBoss) to Spring Boot + best-of-breed open source application services (like NetflixOSS) deployed on a modern cloud native platform. It’s about using technology that is purpose-built for cloud architecture and scale.

As Adrian Cockroft (former Netflix Chief Architect) stated in his SpringOne Platform keynote:

“We have Cloud Foundry and we have the Spring Cloud, Spring Boot stuff, and it’s just there. And if you’re doing Java, there really isn’t anything else out there that’s got this level of support. That’s just going to give you all of this stuff … you don’t need to go build it yourself anymore. You need to build on top of it. You need to build something interesting that is your product that’s going to be the next generation thing that adds your business value.

…
Let’s just do Spring Boot on Cloud Foundry and use a bunch of those Netflix projects that got bundled into it, and move on to the discussion. It’s scaffolding.“

In this post, we will explore why a Platform Switch is so important for enterprises, using the real world experiences of early movers (like Comcast). Next, we will dive into practical advice on how enterprises should approach the Platform Switch for their existing enterprise Java apps.

Note that while we’ll be talking all about enterprise Java apps in this article, these principles apply to enterprise .NET apps as well! Refer to this article for a great example of .NET refactoring considerations.

What About Operational Risk And Cost?

When one brings up replatforming of existing enterprise apps, a natural response is, “What about risk? These enterprise apps pay the bills around here (and my mortgage).”

Partnering with some of the largest enterprises as they replatform has given the Pivotal Cloud Foundry team a unique opportunity to observe the impact of replatforming on operational risk and cost in the real world. A notable example is Comcast, who are migrating some of their core business critical apps to Pivotal Cloud Foundry.

For example, their SOA backbone (“Enterprise Services Platform”), is being replatformed off Oracle middleware onto Pivotal Cloud Foundry. This is the largest middleware application I’ve personally ever worked with during my days at Oracle; it handles about 250 Million business critical transactions/day! Here is their summary of the benefits they’ve obtained from their replatforming effort:

Source: Large-scale Enterprise Platform Transformation—Vipul SavJani, Christopher Tretina, SpringOne Platform 2016

Another of their core apps is SPARROW, their “service activation” platform. Here are some of the KPIs they have been tracking, to quantify the outcome of the replatform effort:

Source: The Power of Partnership & Building a Cloud Native Tier-1 Platform—James Taylor, Comcast

As you can see, there were tangible improvements across every KPI! Beyond these numbers, there have been multiple instances where the Comcast teams were able to diagnose and deploy bug fixes into production in hours, where it would have taken them days with the older platform.

For more on their story, I strongly recommend you take some time and review the Comcast experience videos. Nick Beenham describes the cultural changes they underwent and I especially like Chris Tretina’s description of their multi-year transformation journey. Of course, the SpringOne Platform video playlist is full of lots of other stories from top brands such as Home Depot and Dreamworks.

Where Is Java EE Headed?

It is logical to examine the future direction of your existing stack before you consider an alternative.

As this article in The Register details, there has been a lot of churn recently around the future direction of Java EE. James Gosling (Creator of Java) and others got concerned enough to establish the Java EE Guardians community and are tracking JEE 8 progress (or lack thereof).

Independent of where Java EE is headed, it’s interesting to observe the architectural direction of JEE Servers, such as Oracle WebLogic Server (“WLS”).

Source: Oracle WebLogic Server Multitenant Datasheet

This design premise is resulting in more and more state being encapsulated in each WLS instance via Multi-tenant Partitions. One may choose to agree or disagree with this approach, and I have no doubt my old friends on the WLS team have solid reasons to go down this road.

But there’s no denying this is the opposite direction of where the overall industry is headed—ephemeral lightweight stateless single-process container instances with externalized state. That is, replaceable, scalable processes. Conversely, WLS seems to be doubling down on the “pets” pattern whereas the industry is increasing adopting the “cattle” pattern—meaning, pets are given all the care and feeding they need when they are sick, but cattle is simply replaceable. In an age where infrastructure is a service, there is no longer a need to spend any cycles on infrastructure.

Isn’t Putting My JEE Server In Docker Good Enough?

Docker enjoys tremendous popularity today as it’s an excellent solution for the purposes it was first conceived for: an isolated runtime environment to execute your application within and an immutable packaging format to easily encapsulate & share your application with others.

Over time however, it’s scope is getting conflated into areas beyond its original focus.

Case in point: I am seeing customers consider putting their JEE Servers into Docker images, typically as part of CI/CD pipelines.

My concern with this approach is we are taking “pets” and stuffing them into “cattle cars”. JEE Servers are designed such that each instance has its own distinct identity—“Server Name”, “Listen Address”, what “Cluster”/’Domain”/”Cell” it belongs to, what applications are deployed to it, etc. Just stuffing them into a Docker image doesn’t turn them into cattle and somehow make these servers behave in a cloud native way!

I would assert you are actually increasing your deployment complexity as you have to now rationalize the two methodologies (pets vs. cattle). For example, you now need to make sure your Docker networking is configured such that WLS Cluster members can talk to each other. And if a particular WLS instances crashes, you can’t treat it like cattle and forget about it—there is unique state associated with that particular WLS instance (JTA transaction logs and JMS Persistent Messages) that needs to be recovered. Yes, you can theoretically migrate JMS and JTA Services off to other WLS instances, but I highly recommend you talk to someone who has ever attempted to operationalize that!

The table below lists the most common operations and development tasks when building a Java EE app. Look at it and ask yourself, which of these are any easier with the “Put JEE Server in Docker” approach?

My recommendation would be to take some time and ask the hard questions around what problems are you actually solving by going down this (“Put JEE Server in Docker”) approach.

OK, So How Do I Proceed?

You must be wondering how would you actually proceed with this replatforming? If you have a large number of Java EE apps across multiple LOBs, where does one even start?

Some overall guidance:

• Don’t try to boil the ocean. Pick a small set of candidate apps that you believe are representative of your overall application portfolio and would benefit from replatforming.
• Closely examine these candidate apps for replatform suitability (below).
• Execute a “Replatform Pilot” with the end goal being the applications migrated, deployed and operational on the new platform.
• Lessons learned from the Pilot will inform the replatform patterns and best practices that your organization must follow to migrate the wider suite of apps.
• A large subsets of Java EE apps can be replatformed with minimal effort. Typically, it’s only the app’s surface area (i.e., bindings to its execution environment) that needs work. Remember its Java code at the end of the day and in most applications we are seeing, the JEE API usage is typically encapsulated within base interface types. So bulk of the code can be moved over as-is.
• Yes, there are obviously areas where more extensive refactoring is needed (2PC XA and Container Managed Persistence, for example) but apps utilizing those capabilities are far less common than one may assume.
• Beyond usage of specific APIs, there are other areas that need to be carefully examined, the foremost example being state management—where is the application storing its state? Is in embedded inside the JVM? Will the JVM get corrupted if I ‘kill -9’ it?
• Other notable areas that bear close examination are how the application handles logging and filesystem usage.

Going a bit deeper into the technical details, if you look at Java EE apps built over the last 15-20 years, they have tended to follow some general design and adoption patterns:

• Webapps (Servlet/JSP/JSF) issuing raw SQL queries/updates over JDBC connections is where most folks started (and many just stayed there).
• With the emergence of Spring and Hibernate in the early-mid 2000s, some/many of the previous apps moved to a Spring/Hibernate-based framework.
• There was some early adoption of the commonly prescribed JEE pattern (business services layer implemented with stateless session beans issuing DTOs to DAOs built with EJB CMP) but this was supplanted over time with newer patterns—business services layer via POJOs exposing SOAP/REST interfaces, CMP replaced by Hibernate or other ORMs, etc.
• Message-driven beans are well adopted as they focus on one specific and very popular use case and handle it well.
• JTA usage is mostly within Container Managed Transactions. An application’s explicit usage of the JTA API is much rarer.
• Adoption of vendor-specific extensions to JEE API has remained fairly limited, primarily because from the mid-2000s onwards, architects have been increasing careful not to box themselves in with a specific vendor. There are some notable exceptions to the above—on the WLS side, WLS JMS and its features like Distributed Destinations and Message Bridge have proven quite popular.
• Caching solutions like Oracle Coherence, Pivotal Gemfire or one of the plethora of OSS offerings are often employed to mitigate performance & cost issues when accessing data sources like databases, mainframes, ERP systems, etc.

The above-described patterns help inform the replatform consideration:

• Applications that are already using Spring as their application framework can be moved over to the new platform with little or no effort.
• Webapps issuing raw JDBC or using ORMs like Hibernate are a low hanging fruit, again movable with little or no effort.
• Application components already using POJO-based models (including JPA) are great candidates as well.
• MDBs and SLSBs are generally good candidates as only the EJB-specific “shim” needs to be refactored into a POJO-based model, the actual business logic can transition over as-is.
• Applications often package their WARs alongside the EJBs within the EAR. It should be feasible to tease the WAR out of the EAR and move over to the new platform. I am calling this out as it’ll help minimize the legacy footprint of the app that continues to reside on the old platform (if so desired). Note this does bring up new considerations like cross-network performance and change control that need to be examined closely.
• Application components using the JTA API sometimes end up actually doing just local transactions under the covers, so should be examined as well. If one does find 2PC XA transactions being executed, my personal preference is to leave them be. Note that if you do choose to refactor this code, there are multiple options available, for example using eventual consistency patterns.
• If vendor-specific extensions are indeed being used (such as the example of WLS JMS above), there are abundant alternatives out there. It really becomes a question of your future technology/vendor strategy.
• I recommend keeping the data tier as is, initially. Don’t bite off too much at one time! I believe any data migration considerations should be decoupled from the app replatforming efforts, and handled separately and subsequently.

Lastly, I would highly recommend these sources of information:

• One of my colleagues, Rohit Kelapure, maintains an excellent repository of real-world replatform technical tips & tricks. You’ll find a wealth of information there.
• An old friend from the BEA days (Andy Van Abs) wrote this article many years ago. In my opinion, it continues to be one of the best technical deep dives on migrating JEE applications.
• My colleagues Rohit Kelapure and Pieter Humphrey recently delivered a great webinar that describes our replatform methodology in detail.

How Can Pivotal Help?

Pivotal offers “Application Replatforming Services” to quickly identify and transition apps to Pivotal Cloud Foundry with minimal refactoring. Spanning a typical duration of 10 weeks, the service deliverables include reviewing apps for replatform suitability, migrating the apps, performing testing and verification, and operationalizing them.

We are also working closely with our SI partners to cross-pollinate our respective approaches and offering joint solutions.
Please contact us or your local Pivotal team for more details.

About the Author

Biography