Migrating JEE Applications to Apache Tomcat: Motivation for Migrating

posted by avanabs on June 3, 2010 03:09 PM

In my prior blog on migrating JEE to Tomcat, I discussed the fact that organizations are increasingly migrating from JEE Application Servers to other lighter weight, simpler, faster, more scalable, and definitely less costly JAVA deployment environments. Today, I’ll take a more detailed look at the reasons for such a change and the associated costs.

Reasons to Migrate from JEE to Tomcat

Organizations that choose to migrate existing applications to a new application server are typically motivated by one or more of the following goals:

• Costs—Infrastructure costs are frequently mentioned as a primary motivator for migration, and are certainly important. That said, these costs can be subtle, particularly since in most cases the license itself is a “sunk cost” and all the maintenance fees probably continue if you use any of your licenses (contract “non-retirement” provisions).
  • Capacity Expansion—The need to expand deployment of an application in a cost effective way frequently drives interest in alternative infrastructures
  • Application Replacement—When an application “wears out” and is being replaced entirely, there are opportunities to consider alternatives
  • Vendor Replacement-—While relatively rare, some IT organizations are choosing to replace their IT infrastructure vendors, for a variety of reasons. The cost advantages of replacing obsolete architectures and equipment are an important part of the cost analysis.

Equally important are all the costs associated with maintaining an application infrastructure and the infrastructure’s effect on the cost of maintaining the applications themselves. Many studies have shown that maintenance costs are a much larger component of TCO than license acquisition.

• Shifts in application development/deployment architectures—During the late 1990’s and into the mid 2000’s, most IT organizations (and application vendors) bought into the JEE vision. Without debating the reality of that vision, many IT organizations now realize that the vision was both difficult and costly to achieve for a large number of reasons and they have transitioned their development in several directions. These include a number of alternative languages and architectures, with the common characteristics being:
  • Much simpler to develop and maintain
  • More agile, allowing IT to better meet the rapid changes in business requirements
  • Vastly lighter weight, suited to highly parallel, scalable, redundant, deployment architectures
  • Order of magnitude lower acquisition and maintenance costs
• Harmonize or realign standard deployment environments in the organization—In most large organizations, there are a variety of application infrastructures in use, typically resulting from divisionalized/departmentalized IT or M&A activities. The complexity of maintaining multiple infrastructures makes it difficult to create today’s distributed application service environments. It also requires costly staff duplication to support differing technologies and release cycles. By shifting to a single infrastructure, with enough flexibility to support a wide range of application requirements, it becomes much easier to develop and maintain applications across the organization.

Cost Considerations

Return-on-investment should drive the decision to migrate; ultimately, benefits must outweigh costs. Unfortunately, accurate quantification of both the benefits and the costs can be somewhat elusive, so it is important to take the process step by step and maintain careful records to build an experience base for future decision making. Carefully assess the costs (some of which may be fuzzy) of migrating against both the obvious costs (annual maintenance contracts, for example), as well as the “invisible” costs (difficulty of finding skilled IT operations staff, overly complex application support, etc) of not migrating:

• Consider the acquisition costs for Tomcat, and in particular for any third party technologies needed to supplement Tomcat’s functionality. In most migration situations, the JEE application server cost has already been written off, so license cost is only relevant in the capacity expansion situation. In a capacity expansion situation, the cost of acquiring new JEE licenses and the mega-hardware to support them should also be factored into the decision.
• Consider the costs of actually doing the migration, including the effect of committing scarce development resources to “doing it over”, rather than meeting another business need. While migration should be much less effort than creating the application in the first place (assuming we’ve properly selected the migration target), in some cases migration can actually become a top to bottom re-write. In either case, you are developing and releasing a somewhat new application on a completely new infrastructure, which requires utilizing all standard development processes (design, code, test, document, release, etc).
• Consider the cost of ongoing infrastructure maintenance with both JEE and Tomcat infrastructures. Include both vendor costs and identifiable internal costs, such as accepting and applying vendor maintenance releases (in some environments, the level of patch activity is so high that it swamps license costs in the first few months). The commercial JEE application server vendors share a common characteristic…they all make far more on their maintenance than they do on their license fees (see any annual report for verification), and their maintenance contracts are particularly rigid. On the Tomcat side, consider the cost of potentially dealing with multiple open source communities or vendors, each of whom has their own release cycles and virtually none of which do integration testing with other vendors/communities technologies.
• Consider the cost of maintaining (or perhaps extending) the application itself. The “mega-blob” architectures that characterize all too many JEE applications can make it very difficult to fix even small problems, particularly when the original authors have moved on to other things, and may make those applications virtually impossible to extend/improve. On the other side, consider the cost of “migrating” the application code from the JEE servers to Tomcat and the costs of maintaining the migrated application in a Tomcat environment.
• Consider the cost of quality issues that can arise due to increased lines of code and the challenges of implementing and testing applications based on a traditional full-stack Java EE, compared with lighter-weight technologies now available, such as the Spring Framework on top of Tomcat.

The chart below provides a brief look at the readily measurable outside costs for a typical JEE server (in this case, WebLogic because Oracle price lists are readily available) and for a typical commercially supported version of Tomcat. We will be talking about costs in more detail in a future whitepaper, including discussion of some of the “hidden costs”, like developer productivity and application maintenance.

As the above clearly shows, the cost savings for acquiring comparable functionality, support, and performance can be very significant. Over 5 years, the Tomcat solution is nearly 1/5 the cost of WebLogic, which can add up to millions annually for even a moderate sized IT operation. This factor alone creates significant interest in budget conscious IT organizations, although it is only part of the decision process. When we talk about “migration”, we are generally not considering prior license acquisition cost, which is a “sunk cost”. Looking only at maintenance and operations cost savings, we still see a $19,000/server savings over the 5 year period. That said, the ability to re-cycle the JEE licenses, servers, and maintenance agreements for other uses may offer significant migration savings, because you don’t have to acquire new JEE servers for those applications that really do benefit from the JEE Server.

Shifts in Application and Deployment Architectures

A second major factor driving IT organizations to consider migrating their applications (or more often selected portions of their applications) from JEE to Tomcat is the transition away from “mega-blob” application architectures and toward more modular/layered, horizontally scalable, architectures. While there was nothing in JEE that prevented the development of cleanly layered applications, the developer tendency was to lump everything associated with an application into one place and take full advantage of the highly integrated services provided by these costly commercial JEE servers.

The unfortunate result of that process was to create huge application monoliths, which have proven to be very hard to maintain and extremely hard to extend to meet today’s rapidly evolving business requirements. Because of this situation, many IT organizations have been busy de-composing their mega-blob applications into more modular layered architectures, enabling portions of the application to be extended without having to tackle the whole thing. A second approach is to encapsulate the mega-blob application and expose portions of it’s functionality as services. The resulting application modules rarely require more than a very small portion of the commercial JEE server’s capabilities, thus opening the door to improved deployment architectures based on light weight containers such as Tomcat with very little additional effort.

While the Service Oriented Architecture (SOA) mania (which various vendors killed by over complicating it with expensive and complicated ESB’s and the like) has significantly faded, and wasn’t really anything new in the first place (that’s what CORBA was about…more than 20 years ago), it remains the case that the concept of breaking an application into bite sized services…what ever we call them (modules/components/etc)…offers significant benefits. Development organizations have used this concept to leverage emerging programming models and cost effective parallel deployment architectures to meet the business demands for more agile and accessible applications. Taking the application module (e.g. “service”) to its logical conclusion, we wind up with highly distributed applications that offer truly scalable performance and excellent business flexibility. These deployment architectures are made for Tomcat, with some applications utilizing dozens to hundreds of service instances…the ultimate in redundancy and scalability.

Harmonize or realign standard deployment/deployment environments in the organization

A third driver for migrating JEE applications to Tomcat is to converge the IT organization around a common set of infrastructures and tooling. This is a highly desirable goal and each of the major vendors has their suite of products and insists that they can provide the whole answer, but the reality is that they can not. Even where the single vendor does offer a wide range of capability, the fact remains that some portion of these solutions are “orphan products”, merely there to complete the suite, and don’t compare to other alternatives for the same functionality. This can drive individual development teams to select technologies that best suit their particular needs…good for the project, but very costly for the IT organization as a whole.

Another factor that has driven fragmented development/deployment architectures is that with a high degree of business consolidation, it was inevitably the case that individual IT organizations had selected their own favorite technologies and were then forced to “just merge” and behave as one. Every JEE Application Server utilization survey shows one very interesting thing, that each organization uses products from multiple JEE server vendors, each of which is complex and no two of which are actually “compatible” from a plug-and-play or administrative point of view. In many cases, it is a major development project to migrate a significant application from one vendor’s JEE server to another, for reasons having nothing to do with the JEE standard itself.

Managing all this is a costly and error prone process, leading IT organizations to try to converge on one common, standards based, commonly manageable, deployment architecture. Realistically, converging on a single JEE Application Server is highly costly and fails to accomplish other objectives of migration. This factor, along with those mentioned above, provides significant value to the organization by converging on a more cost effective and agile deployment infrastructure…Tomcat.

Andy has recently decided to make the jump from individual consulting to join the Spring Source team. He will continue to be working with major clients to assist them with IT architecture evolution, now as a member of a large and growing organization. His first project will be leveraging Tomcat, Spring, and a Tomcat based data grid/cache called GemFire. He’s looking forward to sharing the lessons learned with the tomcatexpert community. Andy has been architecting, designing, and building enterprise infrastructure and applications software for most of his career. He’s been responsible for BEA’s “Blended Source” initiative, combining the best of Open Source (including both Tomcat and Spring) with WebLogic, BEA’s WebLogic Enterprise Security product family, MEI Software’s financial systems, Netegrity’s SiteMinder security product, Camex’s electronic publishing systems, mainframe applications for Bell Telephone, and many others. During that time his hands on technology experience has ranged from octal coding into neon lighted switches all the way through JAVA and beyond, including many generations of “the best and final thing we will ever need”, and he looks forward to working on the even better things coming in the future. He was involved in the early days of Open Source software as a contributor to EMACS and refocused on Open Source during his tenure as Director of Product Management with BEA Systems, combined with a fascination for the rapidly evolving application deployment architectures and technologies driving today’s development. Andy has provided architecture and technology guidance for both vendors and IT organizations and he shares what he is learning through consulting services and through his web site, Enterprise Software Trends (www.estrends.com).