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.
Organizations that choose to migrate existing applications to a new application server are typically motivated by one or more of the following goals:
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.
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:
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.
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.
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.