Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Curse you choices! Kubernetes or Application Servers? (Part 3)

January 30, 2019
Ken Finnigan
Related topics:
ContainersJavaKubernetesMicroservices
Related products:
Red Hat OpenShift Container Platform

Share:

    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: October 14, 2021

    Recent Posts

    • GuideLLM: Evaluate LLM deployments for real-world inference

    • Unleashing multimodal magic with RamaLama

    • Integrate Red Hat AI Inference Server & LangChain in agentic workflows

    • Streamline multi-cloud operations with Ansible and ServiceNow

    • Automate dynamic application security testing with RapiDAST

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue