Serverless with Spring Boot?

Last Update: 11.10.2018. By Jens in Newsletter

Yes, it is doable.

Check this tutorial for example.

It works. But should you use it?

The benefit of this serverless thingie is that we can just deploy a single function without worrying about any Tomcats or alike. Just a piece of code doing it thing. Nothing more.

On the other hand, it comes with a few constraints. Like our function is only started when it is requested. And if it is idle for some time it gets shut down.

Now imagine we deployed a Spring Boot app as such a function. The first request will take a few seconds until the app is up and can handle the actual request. The following ones can be handled as usual. The app is already running. But at some time in the future, it might get shut down because of inactivity. This is where the startup time hits us again.

If your app is always up and running anyways because of the sheer amount of requests, you will probably never notice this startup lag (I am not sure about load balancing on Lambda, so there might be more hiccups). But isn’t the serverless thingie not about sparing resources because your app is not handling request all the time?

This also shows in the pricing model. Yep, you pay for the resources used. Unpredictable, you never know in advance what you have to pay.

So, if my app is working nonstop anyways, the traditional FatJar deployment on Heroku or your own metal for Spring Boot apps makes more sense. Predictable cost and more predictable behavior/performance.

So, for me, it’s no Spring Boot apps on AWS Lambda.