A Dingo Ate My Framework: Succeeding with Serverless

Serverless is a computing paradigm that changes the way in which we build and run applications. Pay-per-use managed services make it easier than ever to focus on creating compelling experiences for our users, but this comes at a cost. Sure, some problems are easier to solve with serverless, but others are harder. It can be a rough experience coming from popular web frameworks like Ruby-on-Rails, Express and .NET MVC.

I’ll go over what is driving my approach with serverless on AWS with some practical examples, and offer my thoughts on how to start succeeding with serverless.

Transcript

2. A Dingo Ate My Framework: Succeeding with Serverless
3. Better Software, Faster Infrastructure Modernisation | Data Platforms | Cloud Native Applications | Enterprise DevOps Infrastructure Modernisation | Data Platforms | Cloud Native Applications | Enterprise DevOps @mechanicalrock_ mechanicalrock.io mechanical-rock
5. Bar Clamps Sensor
6. “Cold Starts” “Performance” “Testing!” How to Serverless Like it’s 2016
8. Performance? Testing? Storage? Frameworks? Getting from A to B
9. Code is a liability
10. • Prefer managed services over rolling your own • Explore alternatives to writing code (functions) if possible (e.g. service integrations, VTL etc) • Identify functionality that is likely to be offered as a managed service in future and prepare to deprecate
11. The worst kind of lock-in is the kind you create yourself
13. - Corey Quinn “Something that gets lost a lot in cloud discussions: if you build an app and let it sit in a cloud provider for a decade, it gets better. 
 
 Reliability improves, hardware gets faster. 
 
 Do that on-premise (sic) and the raccoons take your site down by year 3.”
14. AppSync
 (Managed GraphQL) API Gateway
 
 (Managed & Mature API Service)
15. Hot Air over Cold Starts
16. Source: https://twitter.com/chrismunns/status/1158807270605709313
18. PW Isolate Critical Functions in 
 Fargate Redesign to Use Service Integrations Redesign with an Asynchronous Model Delete it
19. Code is a liability
20. You still have to write some
21. S3 Service Catalog Big ‘Ol Pile of YAML PutObject Lambda S3 Event “Publish” Given a CloudFormation Template
 When I publish the template to S3
 Then the template should be published as a product in Service Catalog
22. Before/After
25. Before After
28. After
29. A failure to associate the product will cause the function to be reinvoked again This will cause an attempt to recreate the product that will fail Therefore it will not reattempt to associate the product QED: This function is not idempotent
30. • Keep conditional branching to a minimum; don’t try to do too much! • Separate business logic; Apply hexagonal/onion/port & adaptor architecture! • Validate inputs early; try to fail fast! • Load configuration (environment variables, secrets, etc) early; try to fail fast! • Understand how your function is invoked
31. Testing
32. I’m not keen on locally emulated services
33. • I would not be comfortable with a test suite consisting *only* of locally run unit tests. • I would be more comfortable with a test suite consisting entirely of integration tests • Service integrations, VTL, API transformations - all of these are very difficult to test locally.
34. So why bother?
35. What prevented me relying mainly on integration tests pre-cloud? • Because they are are slow to run • Because they are executed sequentially • Because the tests might interfere with each other • Because they make external calls to an external environment • Because it is expensive (time + money) to create additional environments
36. Configuration Unit Testing “Business” Logic
37. Given a valid cloudformation template, When I publish the template to service catalog,
 
 Then the product should appear in the catalog

40. Parallel Test Executions 
 = 
 Happy Test Executions “Namespace” external resources
42. What about [N>1] Functions?
43. Service Integrations via
 API Gateway / AppSync or Lambda Orchestration via
 EventBridge or Step Functions Invoke Step Function Poll For Completion Upload Template Check for Product Check for Product
 in Portfolio
44. Recap • Focus on integration tests • Ensure you can run integration tests in parallel • Try to reuse logic from your integration tests in your end-to-end tests
45. Databases *
 
 * You probably don’t want RDS
46. Amazon RDS • You will need to run lambda in a VPC to access it e.g. cold start penalty • Designed with the expectations of a few long-lived connections NOT many short-lived connections
47. DynamoDB Aurora • DynamoDB and Aurora can both handle large numbers of short-lived connections • DynamoDB will typically have better performance • You may appreciate the ability to scale but your wallet may not.
48. Frameworks, Frameworks, Everywhere
 …pick one for me, no time to think!
49. CloudFormation Serverless Application Model AWS Cloud Development Kit Serverless Framework AWS Amplify
50. Are there a lot of resources involved? Building a Web App? Does SAM support all the features you need? Can you split things up? No Yes No Yes No No Yes Yes
51. • Frameworks have mostly solved the problem of deploying lambda-backed solutions • Frameworks have solved *some* issues with testing locally • Commercial offerings seem to be fixated on improving observability • Little focus on providing libraries for functions
52. The dingo did not take your framework
53. The Cloud IS the Framework
54. > questions? @matthewtyler13 matthewtyler.io /in/iammatthewtyler