This is the first in a series of articles that consider the role of Kubernetes and application servers. Do application servers need to exist? Where does the current situation leave developers trying to choose the right path forward for their applications?
Why Kubernetes is the new application server
By now you’ve likely read “Why Kubernetes is The New Application Server” and you might be wondering what that means for you. How does it impact Java EE or Jakarta EE and Eclipse MicroProfile? What about application servers or fat JARs? Is it the end as we’ve known it for nearly two decades?
In reality, it doesn’t impact the worldview for most. It’s in line with the efforts of a majority of vendors around Docker and Kubernetes deployments over the last few years. In addition, there’s greater interest in service mesh infrastructures, such as Istio, and how they can further assist with managing Kubernetes deployments.
All these factors are drivers for the current trends within development—pushing more concerns traditionally associated with development down into the lower layers of the entire stack, with concerns moving into infrastructure or the operating environment an application runs on.
Throughout the series, we will see that there is no need for doom and gloom. Although the mechanisms might change, there’s still a place for application servers and fat JARs when developing applications.
Kubernetes and containers
As mentioned in the “Why Kubernetes is The New Application Server” article, yes, containers—and by extension Kubernetes—simplify the deployment process, wrapping all the necessary parts into a single piece that can be deployed. Containers also help prevent many problems associated with deploying to application servers. These problems can include incorrect configuration, JDBC driver issues, and inconsistencies between application server environments.
Container benefits
However, it’s not really containers that provide these benefits. It’s the combination of containers being immutable, because Kubernetes requires immutability to implement failover and clustering, and practices such as CI/CD for verifying and deploying containers that offers us the above benefits. We can just as easily put bad configuration or unverified code into a container and deploy it to production, just like we can when deploying to an application server in the past. As is often said, if you put garbage into anything you can expect to receive garbage out.
Mutable containers
Though we’ve mentioned containers that are immutable, they can actually be mutable as well, and in a variety of ways. With Docker, a container can be mutated by pushing an updated image with new content to an existing tag. More problematic is the practice of tags as symlinks to other tags. Though it’s great to be able to reference a more generic tag of a container, such as “8” for the latest MySQL container in the 8.x series, the next time a container using that image starts, it could be using a completely different version of MySQL. Instead of being 8.0.11 it could be 8.0.12, which should be OK, but it could also be 8.1.x instead, which is more likely to be a potential problem.
Will containers save us?
Containers in and of themselves are not a savior from our past transgressions and problems with production deployments. However, they are definitely part of the solution for reducing problems with deployments. Containers on their own require a great deal of process to be done right. Not doing containers the right way can lead to as many, or more, problems as not using containers.
Kubernetes as the new application server
When considering Kubernetes as the new application server, there are several factors. We need to take into account both what Kubernetes provides and what our application or microservice needs. If a deployment doesn’t interact with other applications, and maybe only stores some data in a database, then, yes, Kubernetes does become your new application server.
Coming in Part 2
Next time, we'll go deeper into the problem space that application servers are intended to solve, comparing that to Kubernetes as the new application server.
Last updated: September 3, 2019