Support deploying to AWS Lambda / aws-serverless-java-container (enhancement)

[ceefour]

I'd like to propose support for AWS Lambda / API Gateway deployment (and other cloud providers). Specifically, in order to do this there are incremental enhancements needed, each one builds upon previous:

1. A standard Spring Boot way and best practices to deploy arbitrary event processing on AWS Lambda, similar to Spring Cloud Function

   • For example, since startup time is more important in cloud functions than regular Spring Boot, there could be a guide that mention best practies on how to reduce startup time
   • Guide on how to optimize the "warm" container state, i.e. reusing Hibernate connections/connection pool
   • Guide for restrictions and gotchas that need to be followed (i.e. 50 MB limit, threading, shared stuff, filesystem, etc.)
   • Guide to optimize/preload classpath scanning

2. A standard Spring Boot way to serve Servlet applications on AWS Lambda and API Gateway, using aws-serverless-java-container-spring made by @SAPessi of AWSLabs

   • This is similar to the spirit of spring-boot-starter-tomcat, but now you have sprint-boot-starter-aws-serverless

3. Extend support for serving Spring MVC controllers.

   • This is already possible as proof-of-concept (thanks @joeyvmason!): Developing Serverless Applications with Spring MVC and AWS Lambda and serverless-spring-boilerplate, however very far from optimized i.e. 20 second startup time (which is normal for some Spring Boot applications but is bad for lambda functions, the default timeout is 6 seconds although it can be increased to 60 seconds).
   • This potentially allows Spring to run many Java web frameworks not on top of servlet container anymore, but on top of serverless. See Zappa for successful example in Python world, that can run microservice frameworks like Flask, Bottle, Pyramid, but also full-stack Django apps, mostly without any code change. Please see Zappa's presentation slides to get a feel why this is important and such a game changer.
     • Of course the "other" web framework will need to ensure behave well in a serverless environment, but this will be much easier if Spring Boot components already laid the foundation to enable this support smoothly.

4. Abstraction / expand support beyond AWS, i.e. Azure, GCP, IBM OpenWhisk. I suggest collaborating with Serverless Framework

5. Tooling to help local development. For example @Serverless annotation, if given, will enable checks during local development to detect restricted features in serverless environment and give WARN or even ERROR log or throw exception.

6. Helpful extras to help Spring app developers deploy Spring Boot/MVC apps to cloud function providers. To illustrate the kind of extras possible, allow me to quote Zappa's feature list:

   • Automatic support for all AWS event sources, allowing you to build robust "hybrid" applications
   • Automatic support for hundreds of pre-compiled and pre-optimized C-extentions packages (SciPy, etc.)
   • Support for applications which use multiple cookies simultaneously (i.e., anything with a login)
   • Free, auto-renewing SSL certificates from Let's Encrypt
   • CI integration
   • Automatic support for "global" (multi-region) applications
   • HTTP logging in the Common Log Format
   • Automatic "keep-warm"
   • Intelligent application and variable caching
   • Zero-effort CORS
   • Automatic and intelligent project initializion (zappa init)
   • Multiple environment variable sources (local, S3)
   • Multiple "secure endpoint" authentication methods (API Key, IAM, custom authorizers)
   • Content-Type aliases
   • Highly customizable configurations
   • Managed IAM credientials with the option to supply custom credentials
   • Package optimization
   • VPC-awareness
   • Ability to deploy HTTP-less, event-driven applications
   • Custom error-reporting (ex, to Sentry or Raygun)
   • Remote command invocation (include raw Python)

In the past, Java EE (and still to some extent Spring Boot) has been regarded to some people as hard to develop, hard to deploy, hard to maintain (DevOps, scaling, etc.), and expensive to operate (requiring servers etc.) Spring Boot is making it easy to develop. And Kotlin and upcoming Java 9 also makes the entire Spring Boot experience pleasant.

If Spring Boot apps can be deployed to cloud function provider like AWS Lambda, that means app developers gain benefits such as easy deployment, automatic scalability, zero maintenance, stability, less vendor lock-in (i.e. Spring Boot app can be moved from AWS Lambda to OpenWhisk and vice versa). This will make Spring Boot much more attractive and increase adoption.

I sincerely hope that this enhancement proposal can be considered. You guys rock. Thank you! :)

[wilkinsona]

Thank you for the very detailed enhancement request. What you're proposing here is outside of the scope of Spring Boot, but is exactly the sort of thing that's being tackled by Spring Cloud Function that you have linked to above. For the record, here are its goals at stated in its README:

• Promote the implementation of business logic via functions.
• Decouple the development lifecycle of business logic from any specific runtime target so that the same code can run as a web endpoint, a stream processor, or a task.
• Support a uniform programming model across serverless providers, as well as the ability to run standalone (locally or in a PaaS).
• Enable Spring Boot features (auto-configuration, dependency injection, metrics) on serverless providers.

Any lower-level goals that require changes in Spring Boot will be handled on a case-by-case basis when they're identified by the SCF team.

/cc @dsyer @markfisher

[snicoll]

@ceefour let's keep the conversation in the issue you've opened in the project @wilkinsona referenced (I can see you've copy/pasted that content anyway).