What are the disadvantages of using spring boot in production?

Viewed 4726

Spring boot is not adopted in our organisation. The disadvantages cited are bloated jars, less control and flexibility. I have tried to investigate above points but so far they dont seem valid.

  • bloated jars - The spring blog states that a simple web server can be launched with 10 MB of heap.
  • less control and flexibility - Netflix uses spring boot.Moreover,when I did some poc's, I didnt face flexibility issues.

I wanted to know if there are any mistakes in assesment.
1)Any examples on the loss of control/flexibility will be helpfull.
2)What are the anti patterns we need to be aware so the bloated jars issue dosent happen.

3 Answers

It is often a question of concern and responsability. With Spring boot, the developper team has full control of the deployed environment, including the servlet container configuration. And the production team has nothing to tweak.

Without Spring boot, the developper team has only control over the web application. And the production can/has to tweak the servlet container configuration. When you have a large number of different web apps, it can make sense to let the knowledge on that part only in the production team. In that case, you would not use Spring boot.

On the other end, if the hosting is externalized, Spring boot allows to give a full package.

So both approaches can be used but they target different organizations.

  • Bloated Jars - I think this can be fixed by properly maintaining the jars using a build tool like maven (But, yes there are some instances where you may need to add a lot of jars just because spring needs it)

  • Less control and flexiblity - I think this is usually with control freaks who want to control each and every piece of code they write. If you are okay with what spring provides already, this shouldn't be an issue.

I believe that the biggest disadvantage that you might encounter using spring is using it without understanding what value it might add to your project.

It might be completely not aligned with your requirements and it is possible that you will configure everything by yourself at some point, when you think, you should not have started with spring itself.

Ask your self a few questions,

  • You can create standalone java application? Why Spring at the first place? What value it adds to your project?

  • Spring has embedded tomcat, jetty, so no need to build a war. But, what if you have to build war anyway? Little config will do the trick but it's not any major advantage. Also, when you start it as a java service, what happens to your service if somehow the java process got killed?

  • What if you have many legacy spring modules? What if you need to patch it up? This will increase the jar count as well as legacy classes count. Are you sure want to convert this into a spring-boot application?

  • What if spring autoconfig configuration is not aligning with your requirements

And, I myself used spring-boot for a few of our production applications, which are mostly standalone REST API services and, haven't faced any issues with it.

Some best practices will be,

  • Use spring-boot mostly for microservices instead of a single complete (MVC) web application (I always use it to build the standalone REST API and build the UI with ReactJS and NodeJS).

  • Build your spring-boot app as a docker image and deploy using some kubernates cluster (kubernates will take care of failed docker containers and deploying to new containers) for maximum uptime.

  • Always keep only the jars required by your project and remove unwanted jars.

Any examples on the loss of control/flexibility will be helpfull.

  • You need familiarity on the life cycle of a bean in a Spring Boot application. Not knowing this might hinder your experience in spring boot. This will force you to structure your beans to prevent circular dependencies and other problems.
  • In Spring Security, configuring your other login methods is not really that intuitive.
  • In Spring Data JPA, repo classes requires you to name the methods in a specific way to perform queries. Locking/releasing data rows is also not straightforward.
  • etc...

What are the anti patterns we need to be aware so the bloated jars issue dosent happen.

Review the dependency tree of your jars. Make sure to add dependencies only in the modules they are needed. Also, remove dependencies you don't need.

Related