Chief information officers (CIOs) are dedicating more of their budgets to what we call “systems of engagement” (technologies that help win, serve, and retain customers) rather than “systems of record” (back-office technologies). According to research here at Forrester, new business investment in the former will be eight times that of the latter in 2014. All of which means CIOs are re-examining their back-office legacy spend to see what savings can be made to fund new front-office innovations.
But releasing back-office spend is not easy. For many companies, most of the ‘easy’ savings have already been achieved - so squeezing even more savings has become a tougher game. For example, you can only try to re-negotiate legacy support costs a few times before the vendors say ‘enough is enough’. While such comments may have discouraged negotiators in past, the advent of third party software support in the last five years has, for Oracle and SAP users at least, kicked the cost savings door back open and given fresh impetus to procurement people seeking to reduce software support costs.
I am sure that many of you have read some of my previous comments on the emergence of the third party software support market over the past number of years. Companies like Rimini Street, Spinnaker Support and Alui have saved some Oracle and SAP clients a lot of money. For companies who have moved to third party support, or who have simply used the threat of moving to third party support in order to drive the vendor’s costs lower, the savings they are enjoying have freed up cash to spend on new innovations and front-office client engaging stuff.
In the latest evolution of its Linux push, IBM has added to its non-x86 Linux server line with the introduction of new dedicated Power 7 rack and blade servers that only run Linux. “Hah!” you say. “Power already runs Linux, and quite well according to IBM.” This is indeed true, but when you look at the price/performance of Linux on standard Power, the picture is not quite as advantageous, with the higher cost of Power servers compared to x86 servers offsetting much if not all of the performance advantage.
Enter the new Flex System p24L (Linux) Compute Node blade for the new PureFlex system and the IBM PowerLinuxTM 7R2 rack server. Both are dedicated Linux-only systems with 2 Power 7 6/8 core, 4 threads/core processors, and are shipped with unlimited licenses for IBM’s PowerVM hypervisor. Most importantly, these systems, in exchange for the limitation that they will run only Linux, are priced competitively with similarly configured x86 systems from major competitors, and IBM is betting on the improvement in performance, shown by IBM-supplied benchmarks, to overcome any resistance to running Linux on a non-x86 system. Note that this is a different proposition than Linux running on an IFL in a zSeries, since the mainframe is usually not the entry for the customer — IBM typically sells to customers with existing mainframe, whereas with Power Linux they will also be attempting to sell to net new customers as well as established accounts.
I don’t understand why firms spend millions of dollars on Java application servers like Oracle Weblogic or IBM WebSphere Application Server. I get why firms spend money on Red Hat JBoss -- they want to spend less on application servers. But, why spend anything at all? Apache Tomcat will satisfy the deployment requirements of most Java web applications.
Your Java Web Applications Need A Safe, Fast Place To Run
Most Java applications don’t need a fancy container that has umpteen features. Do you want to pay for a car that has windshield wipers on the headlights? (I wish I could afford it.) Most Java applications do not need these luxuriant features or can be designed not to need them. Many firms do, in fact, deploy enterprise-class Java web applications on Apache Tomcat. It works. It is cheap. It can save tons of dough.
Expensive Java Application Servers Sometimes Add Value
There is a need for luxury. But, you probably don’t need it to provide reliable, performant, and scalable Java web applications. Application server vendors will argue that:
You need an application container that supports EJBs. EJB3 fixed the original EJB debacle, but why bother? Use Spring, and you don’t need an EJB-compliant container. Many applications don’t even need Spring. EJBs are not needed to create scalable or reliable applications.