Application developers today have more choices than ever before. Choices of programming languages, UI and backend frameworks, libraries, IDEs, operating systems, databases, clouds. It appears that the most difficult thing in application development today is to make a decision which of these technologies to use. There is pervasive fear in IT community that the choice made today may turn out to be “wrong” and the project may need to be migrated, or worse, rewritten to a different platform tomorrow.
Every application needs a stack of technology to run. Different layers in this stack are responsible to different things and very significant chunk of this responsibility falls on shoulders of the application server runtime as shown on the diagram below.
While most applications that run today use majority of the services (and more) on the left side of the picture, yet every architect brings his unique perspective into the right side of the picture and decides how to implement those services for his application. These choices are driven by requirements, such as quality of services, skills in the company, existing infrastructure, legacy applications that need to be integrated, expected application life time, market trends (latest buzzwords), etc. As you may have guessed, there are many ways to build an app and there is no one right answer. Even the concept of “right answer” is fuzzy. I would argue that in most cases the “right answer” is the one that will allow for fastest implementation time at lowest cost while still providing for sufficient flexibility to maintain and enhance the application over its life time. Other possible choices for “right answer” could be to have fun while building an app, learn something new, etc., but these are not in the interest of the business that pays for the project.
Let’s get back to the subject of this post and discuss the state of the “Application Server” business. Before we can do that, we need to define what “Application Server” is. While there are many formal definitions, I would simply define application server as a layer in the architecture (right side of the picture above) that is responsible for implementing a number of useful services (left side of the picture) to make it easy to write, run and manage business logic. This simple definition includes things, such as abstraction from lower level technical artifacts (OS, hardware, networking), horizontal and vertical scalability, set of common programming APIs (messaging, HTTP, database access, security, etc.) and any other function that is not business logic specific. In other words, there are only three things in the logical architecture: (1) Business logic unique for each application, (2) Networking/Hardware/OS/Container and (3) the middleware that glues #1 and #2 together. And this #3 is Application Server – you might want to call it “middleware” – and that is what it used to be called long time ago.
There are many different ways how this middleware (or shall we keep calling it Application Server?) can be implemented. These different implementations offer different levels of abstraction, ease of use, footprint, cost, maturity, scope, scalability and differ from each other in many ways. Since I work for IBM, I will paint this picture as if the world revolved around WebSphere Application Server:
What this picture shows is that the task of running business logic for enterprise and web applications that was traditionally done by WebSphere Application Server is now being “under attack” from many different directions. In other words, business logic that is developed today can run on top of different middleware products and languages with various levels of capabilities. Let’s briefly look into these:
The Java EE camp is competition as usual for WAS.List of Java EE 6 and Java EE 7 certified servers can be found on Oracle website.
WebLogic was the first application server on the market since 1997. Oracle now owns WebLogic and the product is quite popular and has a large install base. However, the product appears to stagnate in terms of capabilities as evidenced by lackluster new features (or lack of thereof) in the past few years. As the result, it is now lagging in capability behind WebSphere as described in my recent white paper.
Red Hat JBoss EAP and its open source cousin WildFly are also popular and provide Java EE 6 and Java EE 7 certified runtimes, but are lacking some qualities of services as described in my recent blog post. Yet, depending on the type of project, these could be fine choices and there is certainly a loyal following, especially for the WildFly project. It is estimated that WildFly, being a free version, has much larger install base and is #1 competitor to the commercial JBoss EAP as paradoxical as it may sound. Such are the realities of Open Source business model. But I digress… Considering a small revenue that Red Hat derives from JBoss EAP and the significant investment required to build a more comprehensive middleware and cloud platform (JBoss BPM, JBoss FUSE, Red Hat OpenShift, to name a few) and the Open Source model, which means that only a small percent of install base is monetized, it is no wonder that JBoss EAP, not unlike Oracle WebLogic, has stagnated in recent years.
There are several other Java EE 6 and Java EE 7 certified servers, but they either lack production support (GlassFish, Geronimo, TomEE) or geographically limited to a local market (Cosminexus, InforSuite, TMAX JEUS, NEC WebOTX, etc.).
IBM has been laser focused on middleware for the past 20+ years and kept up the level of investment into WebSphere Application Server foreseeing the emergence of cloud. This resulted in refactoring of WebSphere traditional into WebSphere Liberty, which first shipped in early 2012. Since that time it grew at very rapid pace and became first to become Java EE 7 production certified runtime, added a host of advanced features and is now embedded in 130+ IBM products and many 3rd party products and applications.
Back in a day when JEE was synonymous with heavy EJB, the alternative Open Source lightweight server frameworks emerged. Prime examples being Hibernate, Spring, Tomcat and others. The idea was driven by practical need of developers to have a simple and small frameworks. This resulted in explosion of Open Source projects that could do one little thing, but to develop a complete application, a developer need to knit these things together and figure out how to make them work with each other (watch this video fragment for more on this topic). While the appeal of the small framework (for example Jersey) coupled with Tomcat or Jetty runtime is tempting, the snowball of complexity grows over time as more is required from the server. Programming APIs are only one side of the puzzle, the other side is management, monitoring, scalability, failover, security and other qualities of services shown on the left side of the first diagram in this post.Many “normal” companies find themselves outgrowing their initial Tomcat or Jetty implementations. This argument may not apply to a pure IT company where the main business is software development. In these companies the pride, sense of adventure and the desire to overcome adversity pushes them to the bleeding edge of experimentation. Google, Facebook and others like them can afford to build their own middleware. Heck, Google build their own servers and now they even build their own CPUs for networking and AI. If you are a bank or retail shop, I doubt you want to follow, unless you are Amazon…
For those who want to use Open Source frameworks on WebSphere, or want to move existing application from Tomcat or Jetty, the good news is that WebSphere Liberty is very well suited to run these frameworks (in fact it fares better in almost every developer focused test) with its flexible class loading policy in large part due to its robust OSGi architecture. When you move an application from Jetty, you do not have to get rid of all of those 3rd party frameworks all at once. You can start by running them “as is” on Liberty and then gradually shift your application into standards based Java EE APIs provided within Liberty. IBM happens to have free migration tool and free services to help you do just that.
Business logic is not always written in Java. There are plenty of old and new programming languages available and there are productivity frameworks and libraries for those languages. Such is the case with StrongLoop framework for Node.js, which was acquired by IBM in 2015. StrongLoop not only comes with developer tools, but also provides a subset of qualities of services for Node.js similar to what WebSphere Application Server does for Java.
CICS on z Systems is perhaps the best QoS runtime environment for business logic, but traditionally it was limited to COBOL and few years ago IBM introduced Java support in CICS.
Oracle TUXEDO is another example of an excellent middleware runtime for C/C++, but is not a popular choice these days. I have built a handful of apps using Tuxedo before 1999 when I joined IBM, but would definitely not use Tuxedo today because of its outdated architecture, lack of skills on the market, extremely high cost, lack of tooling, lack of Oracle commitment to the product and dozens of other reasons.
Another example of the QoS runtime for non-Java is a TorqueBox for Ruby, which is built on JBoss AS. It is not clear how committed Red Hat is to the project as the latest release was 13 months ago and production support is not available.
With very few exceptions (i.e. CICS and Tuxedo), none of the language runtimes have anywhere near the level of qualities of services similar to those provided by WebSphere Application Server. The transactionality, scalability, performance, security are all very important considerations for enterprise applications. If you are building a simpler web app where some of those are not required, you may be ok with Ruby on Rails or alike, but as many companies realized, this has its limitations and once you get into it, it is very hard to get out.
Because of the logic above, if you are to start a new project, but are not fond of paying $ for commercial application server, do yourself a favor and at least use Java. (I know I know, the fans of Node.js, and Scala, and Ruby and Go are all screaming at me now.) Perhaps initially you decide to run on Jetty or Tomcat with Hibernate and alike, but at the very least you have a very easy migration path to an industrial server (WebLogic or WebSphere or at the very least JBoss). If you are stuck in Ruby or PHP, you will find it very hard to get out and may need a total rewrite. With Java you have the best path to move up from small to large, from simple to sophisticated. And the ecosystem of Java is surely top notch.
Total rewrite “all at once” is not realistic and many companies do it gradually. This is where microservices may come to the rescue. Hopefully your application architecture allows for nice partitioning of business logic and most critical parts of that logic can be rewritten or ported into a solid middleware runtime, while the rest can run on Ruby or whatever language you chose initially.
If you prefer closed proprietary ecosystems (recent open sourcing of .NET hardly changes anything, at least not yet) and single vendor solutions, then Microsoft may be a “fine” choice with its C# and .NET runtimes and development tools. I see fewer and fewer new projects started on Microsoft for many reasons, not least of which is the fall of desktop, rise of mobile and cloud, lack of true open community and portability, lack of container support, high costs, etc. There are many articles that discuss these issues (here and here are just some examples).
This is a relatively new development driven primarily by web giants that slowly trickles down to the rest of the industry with the rotation of talent and direct use of Open Source that Twitter, LinkedIn, Facebook, Google and other have contributed to. The emergence of tools, such as Apache Mesos, Google Kubernetes, and more recently Docker Swarm, Docker Datacenter (which IBM resells) and some of their commercial versions (did you know that IBM is the only Docker authorized support partner offering level 1 and level 2 support for Docker Subscriptions?) is not a direct threat to the notion of application server, but those tools are now taking on some responsibilities that formerly were only available in application server products – namely high availability, workload management, workload scheduling, location transparency, some aspects of application deployment and management, security, etc. Cluster management delivers some QoS found in high end application servers, but it can also work in conjunction with them. For example, WebSphere Liberty can be easily provisioned into Kubernetes and Swarm clusters. But in this case Liberty is used more because it provides advanced programming APIs and less because it provides QoS capabilities, which are partially being replaced by cluster management products.
It is worth mentioning that “cluster management” is not a strict category defined by analysts and one could also classify on-premise PaaS products into the same camp. This could be the case with IBM Bluemix Local, which is based on Cloud Foundry and can be installed on your own servers and can manage and run many different workloads, including application servers, databases, messaging, integration, analytics, cognitive, etc. The scope of these products is beyond what application server does, but since it is all middleware, I thought I would mention it here.
Why would I mention “Clouds” as a threat to a traditional application server? The reason is that business logic run in the cloud can be designed in a different way from the traditional programming models. Good examples are new event driven programming models, such as Amazon Lambda, Google Cloud Functions, IBM OpenWhisk described in this article. Another example is SalesForce proprietary Apex programming language. Business application can be built and run on Apex and may not need any application server, hence it is taking workloads away from application server vendors and private datacenters. Heroku is cloud-only offering that supports all kinds of runtimes and variety of programming languages, hence taking away more of a traditional on-premise workloads.
While cloud is definitely a threat to a traditional on-premise workload, it is also an opportunity. For example, IBM provides WebSphere Liberty buildpacks, Liberty Container Runtime and WebSphere as a Service in a VM – all with hourly pricing model for IBM Bluemix. WebSphere is also available as a runtime on other clouds (Cloud Foundry, AWS, OpenShift, Heroku, etc.) and can be used very effectively in both on-premise and cloud deployments. WebLogic does not provide quite the same versatility as it has no buildpacks for Cloud Foundry or Heroku or Bluemix. JBoss does have decent cloud support, except that there is no hourly pricing available from Red Hat for AWS, no buildpack for Bluemix or Heroku.
New playground and opportunity for WebSphere Liberty
As you can see there are many choices when it comes to the application architecture and middleware selections. Competition is a good thing and innovation in this space is moving at a fast pace. IBM shipped first version of WebSphere Liberty in 2012. This took some balls to do, but was a fantastic move. Not only it made developer experience with WebSphere better than with other lightweight servers, but it also made it easy to run in the cloud and integrate with 3rd party software and fits very well with Open Source packages. Let’s inverse the picture and look at it from a different perspective. Notice anything different?
What if you do not have Java skills and are an all <put-your-favorite-language-and-framework-here> shop? Not ready to jump “all in” with Java and WebSphere Liberty? No worries! Try small and simple. Use microservices approach and build small services on Liberty and connect it with the rest of your enterprise. You may be surprised how easy it is to use and how fast it runs.
In short, WebSphere Liberty is a great choice for running your business logic because it:
- Provides a comprehensive programming model, which is a standards based (!!) Java EE 7 (see this post for more details)
- Provides a high QoS environment (with dynamic scaling, performance, security, container support, etc.)
- Can run anywhere, including on-prem, on IBM Bluemix Cloud or in a cloud provider of your choice
- Is very cost competitive and in some cases free (Cloud Cost Calculator, Competitive Cost Calculator, Free 2GB worth of Liberty Licenses, Free Liberty Core for ISVs, Free 375 GB hours of Liberty on Bluemix per month).