I’ve been researching one of the most interesting trends in IT development and deployment architectures; the migration of development/deployment architectures from JEE Application Servers to light weight JAVA containers. Many IT organizations have been re-thinking their commitment to commercial JEE Application Servers, due to both challenging business environments that drive the need for more cost effective application architectures and, more importantly, the need to transition to more responsive/agile applications development. When we hear IT organizations talk about “migrating” their applications, they generally are focusing on one or more of three distinct situations. These are:
In the next few blogs, I'll be focusing on the migration of existing JEE applications to the most popular of the light weight containers, Apache Tomcat. There are many excellent reasons to consider moving applications off of commercial JEE servers sold by Oracle/BEA, IBM, etc. While we are concentrating on the JEE to Tomcat migration process, many of the business and technical decision factors apply equally well to the second and third situations and many IT organizations are doing some/all of them in parallel.
There are multiple steps in the JEE to Tomcat application migration process. These are:
Initially, we’ll focus on some Migration Strategy processes for determining whether to migrate your applications or portions of your applications from commercial JEE servers to Apache Tomcat. Many of these decisions will be based on business factors, although there are also significant technical opportunities and challenges to address. Experience has shown that the projects that work best are those where application owners (business units), development, and operations collaborate in the decision process.
Why Even Consider Migrating a Working Application?
Perhaps the most important question to resolve is “why would you even consider migrating a working, successful, application?” With all of the demands on today’s IT organizations, “if it works, don’t mess with it” surely applies. Additionally, there are many good reasons that today’s JEE Application Servers occupy many hundreds of mega-bytes of system space and cost tens of thousands of dollars, including highly integrated feature sets, very powerful application services, and sophisticated management tools.
While there are certainly valid reasons to leave well enough alone, there are also a number of reasons that IT organizations are deciding to migrate applications from one of the commercial JEE application servers (Oracle/BEA, IBM, etc) to Apache Tomcat. In this context, the term “application” includes complete applications, portions of an application, or functional modules/layers (“services”) which make up an application. I'll be discussing those reasons, a processes to determine a migration strategy, and how to select viable migration targets.
In most cases, migration of JEE applications is not an “all or nothing” process, so a standardized way to select specific migration targets is a valuable tool. Often times migration decisions will be motivated by long term strategic objectives, such as architecture and operating cost reduction plans, but occasionally there is an immediate tactical challenge that can best be met by careful migration.
In one recent case, a consumer facing financial services application running on largely IBM WebSphere was becoming seriously overloaded at critical times of the day. A creative developer decided to understand why this was happening and discovered almost 85% of the processor time was being consumed by a single JAVA service. By abstracting that service (took less than a month) and migrating it to a highly parallel Tomcat deployment, the company avoided purchasing multiple new licenses of WAS, saving hundreds of thousands of dollars in equipment, licensing, and operating (mostly maintenance contracts) costs. In this example, the application was “no longer working” (e.g. not meeting it’s service requirements), so something had to be done fairly quickly, but the brute force approach of purchasing additional costly JEE application server instances was avoided.
In another company, a recent investigation of a large scale application determined that it was almost 100% servlet code, with some utilization of data persistence, and it was hosted in a WLS cluster configuration. Most of the code transported to Tomcat seamlessly, plus adding OpenSource Hibernate technology to deal with the data. This resulted in an annual maintenance contract savings of almost $200,000, an excellent return on the three man months the migration project took.