Red Hat held its 2015 summit last week in Boston. One of the most important announcements was the general availability of version 3 of OpenShift. After my discussion with Jim Whitehurst, president and CEO of Red Hat, as well as other executives, partners and, clients, I believe that Red Hat has made a strategic move and is taking the lead in enterprise-class container solutions for hybrid cloud enablement. This is because:
Red Hat has an early-mover advantage in platform refactoring.OpenShift and Cloud Foundry, two major open source PaaS platforms, both started refactoring with container technology last year. The developers of Cloud Foundry are still working hard to complete the platform’s framework after implementing Diego, the rewrite of its runtime. But OpenShift has already completed its commercial release, with two major replacements around containers: It replaced Gears, its original homegrown container model, with Docker and replaced Broker, its old orchestration engine, with Kubernetes.
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.
I was lucky enough last week [22 March 2010] to moderate a panel at EclipseCon on the future of application servers. The panelists did a great job, but I thought were far too conservative in their views. I agree with them that many customers want evolutionary change from today to future app servers, but I see requirements driving app servers toward radical change. Inevitably.
The changes I see:
Get more value from servers, get responsive, get agile and flexible