Embedded (Embedded) or external (traditional) application server?

Asked

Viewed 1,700 times

9

There is currently a tendency to deploy Java applications as an executable jar on embedded server (Embedded server). There are very popular frameworks aimed at this approach as Spring Boot and Play.

Thus, the traditional deployment model, where Java applications were published on an external application server (such as Tomcat), through a War file, coexisting on the same server with other applications, in different contexts, lags behind.

In this scenario, would you like to understand the advantages x disadvantages of these models? The adoption of the model embedded has to do with the trend of cloud, containerization and Microservices?

  • 1

    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

3 answers

13


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.

4

Embedded server applications/ classic applications

Perks

  • Production and development environment become more similar, avoiding application errors.
  • Easy distribution, application runs more easily on another machine, avoiding long production environment installations.
  • Applications independent of each other, stopping the server does not affect other applications on the same computer.

Disadvantages

  • Application and server (sometimes database) are transported together, which increases the size of the application.
  • When you have multiple applications on the same machine, server infrastructure would be repeated (increased disk space and RAM) and could even cause port conflicts for example.
  • Server tunning is difficult if necessary.

Market trends

On the aforementioned market trends, this makes it easier for developers who don’t want to worry too much about infrastructure, especially in the case of the web application replacing a desktop application on a computer or intranet. Already applications that really need to be accessed by the web, I believe that the traditional model still reigns absolute (opinion).

1

Follows my opinion:

It is a trend of microservices yes. For companies that have microservice applicability scenarios, are adhering to small solutions and the embedded server model is very good, because it streamlines, leaves the development cycle faster, since in this type of solution there is no service tunning.

But the traditional model will not die. Many companies will not use microservices, many have continued in monolithic medium-sized solutions, many have had to continue tunning servers and services. For these, this built-in model does not work

So we will actually have these 2 styles that are going to be on the market and we will have to select according to the context of the solution.

  • 3

    There is signalling about the quality of the response, can justify not to stay only on the basis of the opinion?

Browser other questions tagged

You are not signed in. Login or sign up in order to post.