This is the finale of a series on whether Kubernetes is the new Application Server. In this part I discuss the choice between Kubernetes, a traditional application server, and alternatives. Such alternatives can be referred to as "Just enough Application Server", like Thorntail. There are several articles on Thorntail (previously known as Wildfly Swarm) on the Red Hat Developer blog. A good introduction to Thorntail is in the 2.2 product announcement.
Quick Recap
We’ve discussed the benefits and drawbacks of containers within Kubernetes environments in Part 1. In particular that containers help with packaging deployments, but they’re not a panacea. It’s still possible to create containers with bad content.
Application Servers have been a crucial piece of middleware for decades. They provide integration with crucial services, such as security and transactions, required when developing complex applications. In Part 2 we outlined the use cases for Application Servers, and their continued relevance today. The problems that Application Servers solve are still present. Kubernetes and Linux containers do not remove the need for security or transactions.
Right Tool for the Right Job!
Though it’s a cliche, it’s also completely accurate in this instance. We're certainly spoiled for choice:
- Kubernetes
- Traditional Application Servers, such as WildFly / Red Hat JBoss Enterprise Application Server
- Just enough Application Server, such as Thorntail
Kubernetes alone is great for lots of applications not requiring the services offered by Application Servers. On the flip side, there will be applications that do require those services or frameworks. Those applications need functionality offered by WildFly and Thorntail. Whatever their final operating environment is, Kubernetes or bare metal.
Where does that leave us?
As a whole the IT industry often swings between ideas as if they’re polar opposites. Even worse, that one idea is the only solution for everything! That’s neither a realistic or practical approach for the majority of enterprises today.
Greenfield development is very rare. While switching between “solutions” on a frequent basis is completely impractical. With the time and cost to switch, there's also different developer skills for a new "solution". Most enterprises don't have the resources to retrain their developers on new technology every few years. Sticking with a common programming model is key to long term success.
Since microservices first came to prominence, we realized that not everything needs to fit a single mold. Could a monolith be good enough? Are thousands of distributed microservices too complicated? Maybe a simple Java application doesn’t need an Application Server but just the JVM as a container. Though you may not see the JVM as a container. It offers similar isolation as Linux containers, but was around long before.
These are all great questions to ask. Some, or all, of which should be answered before choosing the operating environment for an application.
In the end, it’s about knowing your application needs. Then using that information to determine the best Application Server or container, framework, and environment combination to bring it to life. Sometimes that’s Kubernetes, other times it’s Application Servers, whether traditional or "just enough". Goals of the application and the skillsets of existing resources are key factors in determining the fit.
Conclusion
Is Kubernetes the new Application Server? Yes and no. For some uses it will be. For others it won't.
Is there a new Application Server, at least for those dealing with Java? Not in the strict sense. The JVM container is the new "Application Server", but certainly isn't new. With the rise of executable jars (Fat JARs) and Just enough Application Servers, the JVM is seeing growth again.
Whether it’s an Application Server, a Fat JAR, a hollow JAR, layered container images, or anything else that might come along in the future for Java. The JVM is the new container of choice, with Kubernetes as the operating environment. Offering the flexibility to choose an Application Server, or utilize plain Java, for an application. With the JVM container as the common denominator across applications.
Maybe “containers” do rule the world?!
Last updated: September 3, 2019