Modernise of JAVA EE application deployed in a 3-tier architecture

Legacy Java EE (which was earlier known as J2EE and is currently known as Jakarta EE) has grew over time and now become unmanageable due to complexity and interdependency modules. These applications were never designed for cloud infrastructures. This lead huge time to market and unable to achieve a high level of productivity.

With growing popularity of cloud adoption, many organisations are seeking way to migrate the applications on cloud. All new applications are can be developed either using the cloud- native services or serverless architecture. These services are using fully managed platform for building, deploying and scaling your apps, services example Azure App Service (Google App Engine) or managed Kubernetes Services like Azure Kubernetes Services (Google Kubernetes Engine).

But wait… what about the legacy applications !!!

One of the approach is to completely rewrite the application. In this case the goal is to create new components that replace and ultimately retire the existing application. This is the most expensive and time-consuming option, and replacing a critical legacy application can be extremely risky.

Other approach is to do -
1) “lift and shift” modernisation model
2) containerised your application modernisation model

1. “lift and shift” modernisation model.

This is an attractive first step to cloud-native development. In this approach find out if the corresponding application server’s support is available on the Cloud or not. If yes then either you can choose corresponding SAAS provider in which the license-included virtual machine images with Application Server software pre-installed or if vendor supports Bring Your Own Software and License (BYOSL) then you can spin-up a new VM and you will manage the software by you. For example Support Policy for IBM Software on Microsoft Azure or Eligible Public Cloud BYOSL Policy allows you to deploy any IBM software licensed.

2. Containerised your application

Now the next step of the modernisation approach is to containerised and deploy on managed Kubernetes Services.

In this approach below are the high-level steps to follow before containerised the application.

Analyse the App type — Identify if the application rely only on features provided by the Java EE specification or dependent on a specific application server platforms, such as Oracle WebLogic Server or IBM® WebSphere Application Server.

Server Capacity — Findout how much the current production application is utilising the server resources. This will help to design the Kubernetes cluster in terms of CPU and amount of memory needed.

Remove the vendor application server dependency — You’ll have to refactor your application to remove server dependencies and find the alternates services available within the cloud or alternate JAR files. Here are some of the application server dependencies — Oracle Service Bus or OSGi bundles.

Remove JAVA EE features -

• JavaTM Message Service (JMS) — If your application is using JMS Queues or Topics, you’ll need to migrate them to an externally hosted JMS server. Azure Service Bus / Google Pub/Sub or Amazon MQ can be a great migration strategy for those using JMS.
• Java Naming and Directory Interface (JNDI) — JNDI related resources, such as JMS message brokers, may require migration or reconfiguration
• Entity Beans or EJB 2.x-style CMP Beans — You’ll have to refactor your application to remove these dependencies.
• Determine session replication is used — Refactor your application to externalise the session to Redis Service or use a database for session management.
• Reconfigure the server applications to use HTTP APi and remove any dependency of the JAVA EE based application client features.
• Determine if the application generate some files on server like which will be later used by OS cron job for publish to the destination. In this case refractor your application to directly upload the files in storage account like Azure Storage or S3 bucket.

Containerisation of the Application and Deploy on Kubernetes -

You can use Apache Tomcat or Jboss wildfly docker image from docker hub and containerised your application. Now you can choose cloud Kubernetes managed services platform for managing containerized workloads and services.

If the applications uses any scheduled jobs then use Kubernetes CronJobs. If application is composed of multiple WARs then containerised each WAR as separate application and run them individually.

3. Secure the traffic flow using Service Mesh

Service Mesh enables Organization to secure, connect, and monitor microservices, so they can modernize their enterprise apps more swiftly and securely. Istio is an open source service mesh that helps organisations run distributed, micro-services based apps anywhere.

By using Istio you can do fine-grained control of traffic via Ingress and Egress Gateway, SSL offloading, M-TLS and load balancing and much more… You can also control the ingress/egress traffic to come via particular node which will be exposed to outside world. Hence you can secure other nodes.

This addresses the challenges of developers and operators face as monolithic applications transition towards a distributed architecture.

4. CI and CD Pipeline

Whenever a developer do any source code changes, with the continuous integration / continuous deployment (CI/CD) system automatically builds, tests, and deploys an application. This maintain reliability while increasing your development velocity.

With help of Istio traffic Management, lets you to control service-level properties makes it a breeze to set up important tasks like A/B testing, canary rollouts, and staged rollouts with percentage-based traffic splits into production.

Finally consider exposing application-specific metrics via Prometheus or Public Cloud specific logging, monitoring and alerting tool. Prometheus is an open-source metrics framework broadly adopted in the Kubernetes community.

Summary

This process has high level view how to migrate an existing Java EE app to the cloud and provide high-level planning suggestions and considerations. Out of above options most prefer option is to “containerised your application modernisation model”. But sometimes your existing IT infrastructure due for the upgrade and you don’t want to invest on Capex then you can choose step processes i.e. 1st “lift and shift” and then refractor your application to containerisation.

Here in 3 tier application I have covered modernisation of application server migration, in next blog I will cover database migration strategy.