Download to read offline
Uploaded byKrzysztof Pawlowski
Serverless in java Lessons learnt
The document discusses lessons learned from using Java in serverless computing, highlighting the benefits of serverless architecture such as cost-efficiency and simplified deployment. It covers various aspects including project structure, complexity in endpoint definitions, debugging techniques, performance challenges, and best practices for AWS Lambda functions. The conclusion emphasizes that while Java can be effective for serverless applications, its suitability depends on specific use cases and team preferences.
Serverless in java Lessons learnt
- 1. Serverless in Java Lessonslearnt Krzysztof Pawlowski krzysztof.pawlowski@merapar.com JEE Conf, 27.04.2019 Kyiv
- 2. About me • Helpingclients create value with innovative cloud solutions @ Merapar • Teaching students good programming practices @ Polish- Japanese Academy of IT • 10+ years of experience with Java • 2 years of experience with AWS • Certified AWS Solutions Architect and AWS Developer
- 3. Agenda • What isserverless? • Why did we choose serverless and Java? • What did we learn when using Java for serverless solution? • Best practices
- 4. –Techopedia “Serverless computing isa type of cloud computing where the customer does not have to provision servers for the back-end code to run on, but (…) cloud provider starts and stops a container platform as a service as requests come (…).”
- 5. How does serverlesswork? Function A Function A code / jars storage Serverless Computing Platform Execution Environment Server Execution Environment Server Execution Environment Server Execution Environment Server Client Function A 1. Execute Function A 2. Retrieve Function A 5. Return result 3. Deploy Function A 4. Run Function A
- 6. How does serverlesswork? EC2 instance (server) Execution environment JVM Request Handler
- 7. Our use-case: migrationproject • Migration of several million users and devices to a new platform • Users decide when they want to migrate • Users and data are migrated to a new backoffice • Firmware is upgraded • How to orchestrate the migration process?
- 8. Our use-case: migrationproject
- 9. Why serverless? • Noservers to manage • Simplified deployment and packaging (AWS Cloudformation) • Automatic continuous scaling • No idle / cold servers = no costs when not used • Pay per request • Availability and fault tolerance build in
- 10. Why Java? • Competenciesin a team • Well tested libraries • Strongly typed language • AWS SDK for Java • Tooling: IntelliJ IDEA, Maven etc.
- 11. Lesson 1: What shouldbe the project structure?
- 12. Project structure or One bigMaven project Maven project per AWS Lambda
- 13. Project structure One bigmaven project Pros: • easier building process • code re-usage Cons: • longer time needed to download/unpack package before invocation Maven project per lambda Pros: • single functionality deployment • lambda code separation / loose coupling • shorter time needed to download/ unpack package before invocation Cons: • code duplication
- 14. Lesson 2: Wherehas the complexity moved to?
- 15. Endpoint definition inSpring Boot @RequestMapping(method = RequestMethod.POST) @ResponseStatus(HttpStatus.CREATED) @ResponseBody @Path(“/foo”) public Long create(@RequestBody Foo resource) { return service.create(resource); }
- 16. Endpoint definition inAWS AWS IAM AWS API Gateway AWS Lambda • complexity moved from one codebase to multiple services • initial bootstrapping is more work
- 17. Endpoint definition inAWS 1. implement AWS Lambda handler import com.amazonaws.services.lambda.runtime.Context import com.amazonaws.services.lambda.runtime.RequestHandler; public class Hello implements RequestHandler<Foo, Long> { public Long myHandler(Foo resource, Context context) { return service.create(resource); } }
- 18. Endpoint definition inAWS 2. create API Gateway endpoint definition • a long json definition including: • OpenAPI definition (aka Swagger) of the endpoint • all responses mappings • all errors mappings
- 19. Endpoint definition inAWS 3. create IAM role for API Gateway to call AWS Lambda "LambdaPermission": { "Type": "AWS::Lambda::Permission", "Properties": { "Action": "lambda:invokeFunction", "FunctionName": “arn:aws:lambda:<region> :<account-id>:function:hello”, "Principal": "apigateway.amazonaws.com", “SourceArn”:”arn:aws:execute-api:<region> :<account_id>:HelloApi" } }
- 20. Developer now needsto know more about infrastructure/platform
- 21. Lesson 3: Howto debug/troubleshoot?
- 22.
- 23. Running your codelocally • AWS SAM (Serverless Application Model) Local • simulates AWS cloud on your machine • Eclipse/IntelliJ plugin - possible to debug locally • not all the services are implemented
- 24. IntelliJ AWS toolkit source:https://aws.amazon.com/blogs/developer/aws-toolkit-for-intellij-now-generally-available/
- 25. IntelliJ AWS toolkit source:https://aws.amazon.com/blogs/developer/aws-toolkit-for-intellij-now-generally-available/
- 26. IntelliJ AWS toolkit source:https://aws.amazon.com/blogs/developer/aws-toolkit-for-intellij-now-generally-available/
- 27. Metrics and logs •Metrics and monitoring • CloudWatch • X-Ray
- 28. Metrics and logs •Logs • CloudWatch Logs Insights • ElasticSearch / Kibana • All managed by AWS
- 29. Lesson 4: Whatis the performance?
- 30. Java performance inAWS • AWS Lambda performance test based simple application exposing GET endpoint returning “Hello world” response written in: • Java • Node.JS • C# (.net core sdk 2.0) • F# • Go • Python • Run in with 1024MB MEM • Cold start not taken into account
- 31. Java performance inAWS Java code had average performance
- 32. Java performance inAWS Java code had consistent performance
- 33. Java performance inAWS Java endpoint had similar performance to other languages
- 34. Java performance inAWS Java endpoint had a consistent performance
- 35. Performance tuning AWS Lambda •you pay per 100 ms • price depends on amount of memory • cpu depends on amount of memory
- 36.
- 37.
- 38. Lesson 5: Coldstart might be an issue
- 39. Cold start Downloading the code Startingthe execution environment Bootstrapping the runtime Running the code AWS optimisation User optimisation Cold start Total execution time Warm start
- 40. Cold start 1st call Coldstart Running the code Running the code Running the code Running the code 2nd call 3rd call 4th call First execution of lambda function
- 41. Cold start Cold start Running thecode Cold start Running the code > 20..45mins Big interval between lambdas invocation
- 42. Cold start Cold start Running thecode Running the code Running the code Running the code Cold start Running the code Running the code Cold start Running the code Running the code Running the code Concurrent lambda invocations (can be limited in lambda definition) - new execution environment created
- 43. Cold start • Incase of Java cold start might take couple of seconds • Less harmful in dynamically typed languages (Python, Node.JS) • Bigger jar file increases cold start
- 44. Decreasing cold starttime • Increase memory/cpu for lambda function • might increase the cost • Separate jar file for each lambda function • Go for dynamically typed language
- 45. Eliminating cold starttime • Pre-warm lambda • call lambda every ~20 min to keep it warm (cronjob) • cost assuming 3GB mem lambda running for 1s every 20 min is about $1 per year • for n concurrent lambda executions - run at once n concurrent lambdas with the same interval
- 46. Cold start • Otheroption how to handle cold start: • do nothing! • it might not be an issue in your case
- 47. Lesson 6: Understand anduse AWS best practices
- 48. –Best Practices forWorking with AWS Lambda Functions (https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) “Take advantage of Execution Context reuse to improve the performance of your function.”
- 49. Reusing execution context •Execution context is created during bootstrapping the environment (part of cold start) • use static initialisation/constructor, global/static variables and singletons • reuse connections: database, http, etc. • do not create long-initialised objects in the handleRequest method
- 50. –Best Practices forWorking with AWS Lambda Functions (https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) “Use AWS Lambda Environment Variables to pass operational parameters to your function.”
- 51. AWS Lambda EnvironmentVariables
- 52. –Best Practices forWorking with AWS Lambda Functions (https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) “Be familiar with AWS Lambda Limits.”
- 53. AWS Lambda limits •Concurrent executions: 1000 • Function timeout: 900 seconds • Function memory allocation: 128MB to 3008 MB • Function environment variables: 4KB • /tmp directory storage: 512MB
- 54. Conclusion • Is Javagood for serverless? • Definitely yes! • Is Java always good for serverless? • Definitely not!
- 55. Conclusion • When touse serverless? • Unpredictable load of your app • Low load of the app -> low cost • No long running processes • When to use Java in serverless? • Cold start is not an issue • Java is a language of preference for the team
- 56. Thank you! Q &A Krzysztof Pawlowski krzychpawlowski krzysztof.pawlowski@merapar.com