We've been discussing the various support options, including community support, available for Apache Tomcat, and contrasting those to Commercial JEE Application Server Support options. In this final blog in the series, we're focusing on the remaining two Tomcat Options, Self Support and Vendor Support agreements.
The second option is supporting Tomcat within the IT organization. In this case, the IT organization must have significant Tomcat expertise on staff and they provide much/all of the support to the various users within the organization. Both the level of expertise required and the challenges of providing that for 24x7x365 mission critical applications are neither simple nor inexpensive.
Less understood is that server infrastructure software is inherently different from application software. It’s a specialty within the software industry; relatively few programmers have the skills and expertise to deal with the kinds of problems found within operating systems and application containers. Realistically, it takes a substantial scale of operations to make this option viable, but for very large organizations, the cost savings and ability to control the process may make self support worthwhile.
The major JEE Application Server vendors offer sophisticated, feature rich, products sold under vendor licenses, together with providing annual maintenance support agreements. While it may not be strictly mandatory (salesmen often tell the customer that it is…commissions on support are very high) for the customer to purchase a support agreement, virtually 100% of the customers do. Since these products are based on proprietary closed source software technology, only those with access to the vendor’s source code can provide maintenance or enhancements to the product. Given the choice of forgoing support, patches, and upgrades, or of paying for the vendor’s maintenance agreement, customers pay, and pay, and pay.
There are third parties providing consulting services and training, but anything involving the internals of the Application Server is inaccessible. Hardly surprisingly, software vendors use this leverage to their best advantage, making maintenance the most profitable portion of their businesses.
The JEE Application Server vendors offer multiple levels of products with software Iicense list pricing/CPU varying from just under $5,000 to over $25,000. It is also common for these list prices to be heavily discounted during the purchase negotiations, particularly for large volume customers. Additionally, many major customers enter into Enterprise License Agreements (ELA) which provides them even more advantageous bulk pricing.
One area that is getting a lot of attention in these days of "do more with less" is the cost of infrastructure maintenance. Many studies show that maintaining software is much more expensive over it's life cycle than purchasing/building it in the first place, so IT management is looking at these costs with renewed interest. The issue turns out to be a bit more complex than it originally appears, although one thing that leaps out is that all of the options for supporting Tomcat are far better than the options we all had with commercial JEE Application Servers. First, let's look at what we mean by "support". In this series of blogs, I'll be sharing some thoughts about the various supportions available for Tomcat, as well as contrasting those with the JEE commercial Application Server support situation.
While it is theoretically possible to forgo support entirely, and sometimes this is forced by software vendor failure or acquisition/product retirement, realistically IT organizations require ongoing support for their mission critical infrastructure. In this post, we will be discussing the various options available to IT organizations for supporting Tomcat environments. We will also be discussing the important differences between commercial proprietary closed source vendor JEE application server support and Apache Tomcat.
One of the most important and valuable “features” of Tomcat from the IT Operations point of view is support choice. Proprietary software can only be supported by the vendor, at that vendor’s monopolistic support pricing, while using Tomcat provides multiple viable options in a competitive support environment. Hardly surprisingly, excellent Tomcat support can therefore be obtained at much lower cost. That said, while Tomcat itself is “free”, there are real internal and external costs associated with using Tomcat as an IT infrastructure. It is important to understand these costs when comparing the various support options.
I want to share with you a recent experience from one of my clients. They have been using Apache Tomcat for several years, often combined with WebSphere (they are a “Big Blue” shop end to end) for supporting back office stateful applications. Early on, they decided to support Tomcat themselves, primarily because they did not find any viable vendors, but mostly because the development team (who had been using Tomcat on their desktops) convinced management that this would be “virtually free”. “No problem!
This has worked very well, particularly while the original Tomcat aficionado continued to provide "support" and...unknown to management...enhancements. There have been only occasional issues, easily handled by their in-house application programmers, with occasional help from the Tomcat community. No one even bothered to keep track of time spent maintaining Tomcat, because it was “free”. Over that time, however, their Tomcat version has diverged from the Apache project, because maintaining compatibility wasn't an objective, because the cost (mostly developer time) to submit their fixes to the Apache community wasn’t in anyone budget, and partly because re-integrating ongoing Apache changes was also un-funded drudgery. So, this organization is “using Tomcat” as far as management knows, but is actually using a diverging branch. All that said, the process continued to work fine and the visible costs were indeed low.
About a month ago, a new application was developed and put into test. This application was fairly simple, but it was projected to generate $ 100,000/week (TINY by their standards) initially, ramping up to over a half million/week by Q3. It was also the first visible peek at a new business strategy. The problem was that the application failed erratically during test. Subsequent debugging indicated this was due to a bug in Tomcat, not the application, so one of their application guru’s quickly rolled out a Tomcat bug fix (enhancement???) and delivered the result back to test.
At first, everything seemed fine. The new application worked great and passed thru QA with flying colors. “Free” self support won again…or did it? Application developers working on other projects fairly rapidly found that the new version was breaking some of their legacy applications, including several commercial apps. So, the application developer went back to the drawing board and quickly generated another fix.The new application failed, as did almost everything they tried to run. So, the process continued, with more than two dozen fixes generated and tried, and generated and tried, and…
Popular Links