"Tomcat First" is part of a guest blog series I am doing for OpenLogic. In my previous article, Open Source in the Enterprise: A Shift in Prevailing Views, I discussed the changing enterprise use case for Free & Open Source Software (FOSS). In that blog piece, I posited that the use case for FOSS in the enterprise has changed, and that this change is attributable to three important factors:
-
The barrier to entry to use open source is very low
-
Downward pressure on IT budgets makes the community model look much more appealing
-
As FOSS becomes more pervasive in the overall marketplace, enterprises are waking up to the fact that they have the power to solve their own software problems
I will endeavor to illustrate how enterprises are leveraging these shifts in the prevailing view of FOSS to drive its adoption within the enterprise. This article will focus on the infrastructure software space; the second part of this series will discuss how FOSS is being used to facilitate enterprise software development. That said, in the next article, largely because I will not be able to control myself, it’s a very good bet that I will again find myself blurting out the "C-word," and will stray onto the topic of the use of FOSS to enable devops in "the cloud."
Let’s begin… Maybe you are a mid- to large-size enterprise operation that has just successfully walked through the valley of enterprise FUD and developer bias. Your CTO is convinced that the use of open source will not bring about Armageddon. Your development community is on board, and has successfully piloted some FOSS applications. Your infrastructure support teams have begrudgingly agreed to start including open source standards in the service catalog.
You’ve just measured your open source usage, and have found, like most enterprises, that just because no one was actively working towards an open source strategy in your company, it has somehow managed to seep into your software operations. Some of you may have even discovered that the level of ungoverned FOSS use in your company is simply startling. So, like most enterprises, you rush to control your FOSS use.
If this blog were about all of the silly things I have had to deal with during my own employment as open source evangelist and program manager, I would probably stray off topic here and tell you about an interesting paradox whereby the greatest supporter of open source in an enterprise usually finds himself in the position of having to write the laws (policy) that govern it’s use! But, I digress.
In any event, your next move after discovering that people do things with FOSS, even when the CTO says it’s not OK, is probably to write a policy and set up some form of FOSS governance. You may even have solicited OpenLogic’s help in this process and you are now enjoying the many downstream benefits associated with this wise decision. Look, it’s their blog and, more importantly, I really do like their product! Moreover, if I were blogging for Ford Motor Company, I’d be compelled to mention that I own an F-150.
So, your open source management practice is up and running. and you find yourself day after day dealing with governance issues (i.e., license analysis, training, policy audit, etc.). This is probably not what you had in mind when you originally set out to foster the use of open source within your enterprise and to accelerate its adoption ultimately.
At this point, as was discussed in my first blog piece, many second wave adopters are naturally coming around to the idea that open source is just another class of software and that it can be used to derive IT business value. In turn, this has alleviated some of the pressure on you to govern "absolutely" the use of FOSS in your enterprise. You now start to classify corporate use, and most FOSS governance is now directed at the elements that represent the greatest risks (i.e. wonky licenses, patent trolls, distribution of modified source code, etc.). This frees you to work on the goal that you originally dreamed would be your mission as your company’s open source evangelist – to drive FOSS adoption.
Now what do you do? Linux has already happened. (At least, it should have already happened. If, in 2012, your company has not found a way to drive Linux successfully into your enterprise server space, then you require a much larger prescription than I can possibly write within this blog piece.) Opportunistic, component-level adoption (e.g., PERL, Eclipse, etc.), is just not the big score you’re after. The system management software space is where religious wars are fought. End-user applications are interesting and are fun to brag about, but change usually happens over a long period of time and adoption is usually contained within one vertical. This leads us back to the infrastructure software space.
Linux has been hugely successful; why not consider the infrastructure applications that sit on top of the operating system? But, which tier? The web server war is over, and relational database, like the systems management space, is for religious crusaders. That said, the NoSQL/distributed database space is interesting, but this space is still evolving. That leaves the middleware space, specifically application servers. While most every application programming language has the concept of an application server, Java is still the most pervasive application programming language found in the corporate IT Linux space today.
This brings me to the true topic of this piece, "Tomcat First." Many companies are finding Tomcat, more appropriately Tomcat coupled with application frameworks such as Spring, to be the most logical next step for a large percentage of their Java middleware applications. Independent studies, conducted by reputable firms over the last several years, tout the benefits of application portability and scalability that Tomcat and open source frameworks enable. Although recent JEE standards and product releases have delivered a similar lightweight architectural platform to that underlying Tomcat, quite frankly, my money is with Tomcat and open source. That is where the innovation is occurring.
To prepare for this blog piece I interviewed several Fortune 100 companies and discovered that many already have variants of a "Tomcat First" strategy in place (with the finance sector leading the way). The goal of any FOSS "do this first" strategy is not simply to have the FOSS component added to the service catalog alongside its proprietary equivalents, but to engender your company’s architecture and software development community to direct that the FOSS component always be considered first. Ergo, "Tomcat First" means that software development and infrastructure software engineering teams are required to use Tomcat in all cases where EJBs are not required (or as one developer put it, “full-blown monolithic JEE stack”).
Next, I validated the external research with internal research. The companies I interviewed that successfully launched "Tomcat First" strategies all discovered that approximately half of their existing Java applications could run in a Tomcat container only (EJBs were not required). One company that modeled potential software licensing and support cost savings associated with switching from proprietary application servers to Tomcat reported that the potential savings ran in excess of $5M annually.
Thus far we have focused on the fact that Tomcat can be used in place of proprietary software equivalents, and the potential for cost savings. Perhaps even more exciting are the operational benefits. If you believe the research along with what many developers and software engineers who received their training within the last five years have to say, Tomcat, combined with flexible application frameworks like Spring, just flat out makes sense. Tomcat applications are more portable, easier to scale, and are more extensible thanks to thousands of additional and freely available open source framework components.
Here is another interesting perspective, developers report that Tomcat code is more nimble, both in terms of it is code footprint and its simple and precise programming construct. This translates into faster deployments and greater ease of management once in production. If you are still not convinced, Google and review the research data yourself, and talk to any Java developer under the age of 30. Recently, I interviewed one such animal. He had a very interesting perspective on this topic that I had not considered previously:
“Why do I like Tomcat? Easy. I can grab whatever versions I need and have them on my desktop in less than 10 minutes. You can’t do that with [insert name of your favorite proprietary application server here]. Plus, I can install several different versions without them stepping on each other! Here is another aspect of cost savings you don’t hear about often... my time! Notice how I said "10 minutes" above? Try to get [deleted] through procurement, find the binaries and unpack them, and load them into your development environment in less than three days. Go ahead, try it! I’ll be over here in the shade... running Tomcat! It's hard to call yourself 'agile' when you have to count licenses. Bottom line, using Tomcat I'm happier. I can be up and running in a matter of minutes, and I know that if I have questions, I have a whole Google of friends out there that can help me.”
I suppose I could go on to describe at least three other benefits associated with the use of Tomcat, but I’m anxious to move onto discussing how one implements a "Tomcat First" strategy within their enterprise. All companies are, of course, different and there are several important elements in play that govern whether your attempt to implement a "Tomcat First" strategy will be a steep incline or a modest slope.
Watch out for my next post. I will provide 10 Steps for a Successful "Tomcat First" Strategy.
