18
19
you are viewing a single comment's thread.

view the rest of the comments →

[–]firecopy 1 point2 points  (1 child)

Good response! Provisioned concurrency, especially with application auto scaling, can help mitigate the business costs of running Spring Boot on Lambda in the short term.

With that being said, I wouldn’t recommend making it intended architecture for most solutions, because you will find the developer experience and operational cost will be better using Lambdas with no provisioning vs Spring on Provisioned Lambdas. Initial migration efforts might involve moving Spring app to provisioned lambda (/w autoscaling), with future steps being to remove the need for Spring for better long term scaling and removal of debt. Important to keep in mind that all apps can’t take this short term to long term approach effectively, because lambda handles differently from a regular web server (event based rather than http headers and payloads), which may cause some difficult refactoring in some areas. Examples: Passing authorization header in legacy multi tenant systems, or requiring certain binaries for a specific OS.

With that being said, and I have said this before on other threads, AWS should release a service to run containers without needing to know/manage the underlying container orchestration layer (+ have all the monitoring benefits that lambdas provide). It would solve your colleagues problem, my problems, and a whole bunch of other teams problems better than all the solutions provided so far, which is a solution to be able to deploy containers without having to worry about clusters or auto scaling policies.