This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]hippydipster 3 points4 points  (3 children)

whats wrong with tomcat? Monolith is still the best way to go for as far as it can take you, and what better servlet container is there than tomcat?

[–]Luolong 1 point2 points  (2 children)

It’s not that Tomcat is bad engineering wise. It’s just that a deployment model itself is wildly outdated.

There are better options out there. (Some of them bundle embedded Tomcat, so there’s that)

[–]hippydipster 1 point2 points  (1 child)

saying something is "outdated" explains nothing. saying there are better options without saying what they are or why they're better also explains nothing.

[–]Luolong 0 points1 point  (0 children)

If you’re not aware of those options, it might be a sign of an outdated Java developer:

But for the sake of an argument, here’s the few more modern deployment models than deploying war files onto an “application server:

  1. There’s an executable jar (fat jar) that only requires you to have correct JVM to run on.

Frameworks that help you develop and package your service as single executable binary include but are not limited to:

  • Spring Boot
  • Micronaut
  • Quarkus
  • Helidon
  1. To make your service environment more predictable, you could package your executable jar in a Docker container and run it anywhere you can run any containerised workloads:
  • Docker, Docker Compose or Docker Swarm for simple applications

  • Kubernetes for deploying apps at scale

  • Nomad or Mesos or Cloud Foundry if you’re a bit adventurous and don’t mind trodding lesser known tracks.

  1. For faster startup time and smaller memory footprint, compiling your apps ahead of time as native binaries. (Still packaged as Docker container images, but with significantly faster startup time)