The "traditional" deployment and operations model used to handle java applications is strictly linked to application servers. The way of administering Application Servers has hardly changed over the years, not keeping up with the needs of developers.
A lot of services under the same server can cause numerous problems, among them (the most serious in my perspective) the possibility of an application with error take down the server and consequently all other applications, even if they have nothing to do! I’ll make a comparison between approaches, topic by topic:
Development impact
For the developer App Server means an additional step in the dev-test cycle. The compilation result is compressed into a War (or jar) file. Then War will be unpacked by App Server so we can see the app running. Then the code is compressed only to be uncompressed again.
I said it was just an additional step, but it occurred to me now that it is necessary to install the server locally first.
With Embedded server, there is no need for an additional installation, the compression/decompression process is non-existent. And you can run the app with a simple command.
Deploy
When we put the system into production, the App Server also adds considerable weight:
The server must be deployed beyond the app. The setup is usually quite complex, sometimes even more complex than setting up the app itself. This makes automation scripts harder to write. The scripts available for tools like Chef or Puppet prove this point.
The server configuration must match the version and configuration of the app. And this must be ensured in each environment (qa, pre Prod, Prod, etc). At the same time, old settings should be available - for possible rollbacks. This is difficult to manage.
This problem becomes even more serious when we make continuous delivery. This process commonly contains several stages of testing - unity, acceptance, load testing and exploratory testing. In each of these steps, possibly the app will be deployed in a different environment - and this pipeline runs several times a day. The additional complexity in the deployment process has a huge impact because there are many deploys made every day. So deploys should be as easy as possible. Avoiding App Server here makes your life a lot easier, otherwise you will have to manage the status of the server as well. The concept of Immutable Server exists to deal with this problem.
So not only are the benefits of using an App Server questionable, but it adds considerable complexity to the app deploy.
Devops
New trends also do not match well with the idea of an App Server. Devops proclaims a fusion of development (Dev) and operations (Ops) for Devops, which leads to a different approach: developers often use specialized tools for the environment where they are programming (java for example).
On the other hand, Operations has a set of tools that support a broader picture - deploy automation that can be based on package managers and tools for metrics, for example.
This approach also makes developers aware of these tools, so they use them to configure the machines themselves. The alternatives to App Server tools are more easily accessible also to developers.
That is, the standard operations tools for monitoring and deploying are a great alternative to the solution that App Servers provide.
Microservices
Another clear influence on this discussion is microservices. With this paradigm, services must have commercial significance and can be deployed independently. So instead of a large monolith, the system is divided into several deployable components that communicate with each other. Each microservice is effectively a separate web application.
Deploying an App Server for each of these microservices adds a considerable overhead. A greater number of instances are needed compared to the traditional configuration model. In addition, microservices focus on specialized infrastructure: an App Server can be a good choice for front-end service. But for data analysis, a Big Data infrastructure like Hadoop will be more appropriate. If there is some kind of batch processing, Spring Batch may be the best choice.
Microservices increase the number of independently deployed components. This means that a complex infrastructure must be avoided.
Completion
If App Servers only cause more complexity, there are no good reasons to use them. Using Embedded Servers, we can package our app into JAR files that contain a main class and thus can be started from the command line. The JAR file contains all the necessary infrastructure, both libraries, and an embedded HTTP server for a web application. The deploy can be done with automation tools like Puppet, Chef or Ansible. They are very easy to set up.
It’s hard to find compelling technical reasons to justify using App Servers today. Deployment and monitoring support can be done with generic tools that operations are already used to. Libraries provide the resources that developers need. Without an App Server, app development is easier - and also deploy, test, and debug.
To support this idea, you can check on Heroku’s website that this is the way they recommend the deploy. The Procfile has a line.
Jetty uses the slogan "Don’t deploy your application in Jetty, deploy Jetty in your application." (Don’t deploy your application to Jetty, deploy Jetty to your application). It’s all about ease of deployment and maintenance.
However, if you already have App Servers running and you’re used to them in production, things change. Switching to Embedded Servers will change a good part of your process. The effort to make these changes must be balanced against the benefits.
I think that even advantages is more because it is a stand alone and therefore easier to deploy in production/test and, also, the configuration becomes more granularized, you can have a more specific control of the container of each application (which sometimes can be bad to spray too much). As far as I know, doing several of these Alones stands implies having an open door for each of them; I owe you confirmation of this
– Jefferson Quesado