Download as PDF, PPTX
![Lambda
Handler
Challenges > Vendor lock-in > Lambda Anti-pattern
{
"Records": [
{
"EventVersion": "1.0",
"EventSubscriptionArn": "somearn",
"EventSource": "aws:sns",
"Sns": {
...
}
}
]
}
{
"Success": true
}](https://image.slidesharecdn.com/awssydneyworkshop-2018-06-08-180608033305/85/Trends-and-development-practices-in-Serverless-architectures-40-320.jpg)
Uploaded byDiUS
Trends and development practices in Serverless architectures
The document discusses the evolution and architecture of serverless and asynchronous systems, focusing on the transition from monolithic to microservices. It highlights the challenges of vendor lock-in, testing, and increasing complexity, while emphasizing the importance of automation, observability, and design patterns like event-driven approaches. Recommendations include using stubs for testing, leveraging contract tests, and creating a protocol anti-corruption layer to better manage the complexities of serverless architectures.
More Related Content
Similar to Trends and development practices in Serverless architectures
Trends and development practices in Serverless architectures
- 1. Testing large-scale, serverless andasynchronous systems Matt Fellows @matthewfellows ...without end-to-end integrated tests! #AWSAgility
- 2.
- 3. WHAT WE AREKNOWN FOR 3 Microservices Evolution Drivers for levelling up ● Increase time-to-value ● Increase utilisation / cost reduction ● Raise abstraction; focus on composition ● Scale product teams ● Massively distributed, real-time apps ● API contracts (e.g. OAS) ● Ubiquity of cloud computing ● Rise of containers ● Unreliable networking / components ● Rise of the Service Mesh ● Improved observability Why Serverless? > Drivers
- 4.
- 5. 5 Data Pipelines Trends >Data pipelines
- 6. 6 Trends > Datapipelines
- 7.
- 8.
- 9. 9 Trends > Datapipelines > Before Systems of Record Integration / Middleware APIs Presentation Synchronous, coupled invocation Data locked here
- 10. 10 Trends > Datapipelines > After System of Record Event API Local cache / materialised view API 3. Event processed into local view of data 1. Change of system state 2. Event is shared
- 11. Observations Architecture > Microservices ●Democratisation of data ○ “Everyone gets a data” ● Hollywood Principle ● Pipelines are the new batch ● Prerequisite for AI/ML ● Composition and enrichment ● Lambda to “glue” steps together
- 12. 12 IT Ops. Automation Trends> IT Ops Automation
- 13. Before... ● Ad-hoc ● Cronjobs running on instances ● Scripts > code ● Shared “Job” machines, with broad security permissions and “all-the-tools” ● Lots of manual “glue” and orchestration Trends > IT Ops Automation
- 14. 14 Trends > ITOps Automation Decide Alarm Schedule Event subscription Notify Pagerduty Act Isolate instance from ASG Ship logs to Splunk Offsite backup Orient Security Analysis Application Anomaly / Canary Detection Policy Violation Chaos Engineering Observe Flow Logs CloudTrail CloudWatch Logs Application Event Configured Rule
- 15. New approach ● ScheduledLambda to replace “cron” jobs ● Real-time cron - event-driven ● Function written and deployed as code - first class citizens Rise of the OODA loop Trends > IT Ops Automation
- 16. 16 The new uService Trends> Microservices
- 17. 17 Trends > Microservices> Before Instances Team 1 Team 2 Team 3 Team ...
- 18. 18 API Gateway Trends >Microservices > Before Services Services Team 1: Orders Team 2: Identity Services Team ... Team 3: Experience
- 19. 19 Trends > Microservices> After > New Patterns API External Events API Outside World Microservice Interface API Master Data API Inside bounded context Event Emitters API Materialised view / cache Events and Processing Data Event Handlers Processing Offline Processing
- 20. 20 Provisioning Amazon ML Trends >Microservices > After > Example Team 1 Bounded Context Place Order API External Events Order Status API Outside World Internal Events Microservice Interface Data, Events and Processing Suggestions API Publish Event to external subscribers Insights / Predictions Customer / Other Event Orders Push API Inside bounded context CRM Materialised view of customer Provisioning Event External Events … API
- 21. 21 Trends > Microservices> Evolution Sizeofthing Number of communicating things Monolith SOA Serverless Microservices Fn Luckily, built on the same primitive!
- 22. Observations Architecture > Microservices ●Microservices still a thing ○ ..but are now just the interface of the iceberg ● Further decomposition of services into smaller functions ● Event-driven + asynchronous > synchronous invocation ● Lambda and managed services as “glue” ● Architectural composition BUT - More things to manage
- 23. Summary Architecture > Microservices ●Serverless as a higher-order system ○ Composition ● IT Operations Automation ○ Better discipline (OODA) ○ Everything as code ● Microservices still a thing, new designs emerging ○ Event-driven and loosely coupled ○ “Iceberg” patterns
- 24. 24 Much Compose! Sospeed! Architecture > Functions + Serverless (Cloud Native)Architecture > Functions + Serverless (Cloud Native)
- 25. 25 New challenges Architecture >Functions + Serverless (Cloud Native)
- 26. 26 If you can’tbuild a good monolith you shouldn’t be doing microservices Architecture > Microservices
- 27. ...the µServices ride ● Abilityto write a modular monolith ● Strong grasp on your domain model ● Ability to design loosely coupled services ○ = state + transactions ● Ability to scale and decouple teams ● Ability to deploy continuously ● A strong “DevOps” culture ● Be comfortable with decentralised, complex systems + uncertainty Architecture > Microservices
- 28. 28 If you can’tbuild good microservices you shouldn’t be doing serverless Architecture > Functions + Serverless (Cloud Native)
- 29. 29 What practices dowe need in this new world? Architecture > Functions + Serverless (Cloud Native)
- 30.
- 31. 31 Demo: AWS MeetupLounge CloudFront API Gateway Authentication You! awslounge.onegeek.com.au Twitter Fetch Twitter feed Twitter Push IoT Message Broker Sentiment Analysis Checkpoint Amazon ML #AWSAgility
- 32. 32 Demo: AWS MeetupLounge Demo
- 33.
- 34. 34 Smaller functions =more things! Challenges > Async
- 35. WHAT WE AREKNOWN FOR 35 Options ● ... Challenges ● Observability + Tracing ● Structured logging ● Shift responsibility into platform ● Good acceptance tests Challenges > Vendor lock-in
- 36. 36 Vendor lock-in Challenges >Vendor lock-in
- 37.
- 38. WHAT WE AREKNOWN FOR 38 Options ● Multi-cloud = lowest common denominator ● There is always a vendor (even if it’s you!) ● You’ll never be completely vendor agnostic ● Multi-cloud abstraction ● Avoid altogether ● Structure your code better Challenges Challenges > Vendor lock-in
- 39. WHAT WE AREKNOWN FOR 39 Options ● Multi-cloud = lowest common denominator ● There is always a vendor (even if it’s you!) ● You’ll never be completely vendor agnostic ● Multi-cloud abstraction ● Avoid altogether ● Structure your code better Challenges Challenges > Vendor lock-in
- 40. Lambda Handler Challenges > Vendorlock-in > Lambda Anti-pattern { "Records": [ { "EventVersion": "1.0", "EventSubscriptionArn": "somearn", "EventSource": "aws:sns", "Sns": { ... } } ] } { "Success": true }
- 41. MQ Handler WebSocket handler MQ AdapterWS Adapter Azure Function Adapter Google Cloud Fn Adapter Azure Function Handler Google Cloud Fn Handler Lambda Handler Lambda Adapter Service Repository Adapter (Anti-corruption layer) Ports Business Logic Collaborators ... Challenges > Vendor lock-in > Ports and Adaptors
- 42. 42 Challenges > Vendorlock-in > Ports and Adaptors > Sentiment Analysis Example Twitter feed Sentiment Analysis IoT Message Broker
- 43. Challenges > Vendorlock-in > Ports and Adaptors > Lambda Port
- 44. Challenges > Vendorlock-in > Ports and Adaptors > SNS Adapter
- 45. Challenges > Vendorlock-in > Ports and Adaptors > Lambda Sentiment Service
- 46. Summary Architecture > Microservices ●Separate protocol handling from business logic ● Business logic shouldn’t change with introduction of a new protocol ● Port, Adapter and Business Logic are independently testable
- 47. 47 How do youtest locally? Challenges > Testing Locally
- 48. WHAT WE AREKNOWN FOR 48 Options Challenges > Testing Locally ● Stub services (e.g. Localstack) ● Multiple handlers ● Stub API (e.g. Moto) ● Unit tests
- 49. 49 Challenges > TestingLocally
- 50. WHAT WE AREKNOWN FOR 50 Options ● Feature arms race ● Trustworthy? ● Integration style = slower ● All cloud providers? ● Stub services (e.g. Localstack) ● Stub API (e.g. Moto) ● Multiple handlers ● Unit tests Challenges > Testing Locally Challenges
- 51. WHAT WE AREKNOWN FOR 51 Writing good unit tests ● Follow test pyramid ● Stub out AWS APIs ● Test your business logic separately from any serverless features (e.g. lambda handler) ● Callback pyramid of death ● Tests are hard to write ● Your business logic knows about AWS ● You have to stub multiple services per test ● Large methods ● Confusing control flow Challenges > Testing Locally > Unit Test Code Smells
- 52. 52 Challenges > TestingLocally > Unit Test > Twitter Fetch Checkpoint Twitter Fetch
- 53. Challenges > TestingLocally > Unit Test > Lambda Service Look ma, no AWS Code
- 54. Challenges > TestingLocally > Unit Test > Lambda Service Look ma, no AWS Code
- 55. 55 Challenges > TestingLocally > Unit Test > Sentiment Analysis Example Twitter feed Sentiment Analysis
- 56. Integration-style test of handler Challenges> Testing Locally > Unit Test > Lambda Handler
- 57. Summary Architecture > Microservices ●Business logic should be tested separately from port + adapter ● Majority of tests, should be fast unit tests ● Stub AWS Services where required ● (Lambda) Handlers can be locally integration tested with pre-canned JSON events
- 58. 58 Async - whois my consumer? Challenges > Async
- 59. 59 Async - delayin feedback Challenges > Async
- 60. WHAT WE AREKNOWN FOR 60 Options ● Local integration testing ● Cloud env. integration testing ● Contract testing Challenges > Async
- 61. WHAT WE AREKNOWN FOR 61 Options ● Can’t run complete local environment ● Many moving parts ● Problems with integration testing... ● Local integration testing ● Cloud env. integration testing ● Contract testing Challenges Challenges > Async
- 62. WHAT WE AREKNOWN FOR 62 Options ● Can’t run complete local environment ● Many moving parts ● Problems with integration testing... ● Local integration testing ● Cloud env. integration testing ● Contract testing Challenges Challenges > Async
- 63.
- 64. 64 IoT Message Broker Sentiment Analysis Contract { 'Positive': 0.234, 'Negative':10.123, 'Neutral': 7.334, 'Mixed': 0 } Consumer Provider Challenges > Async > Contract Tests
- 65. 65 CloudFront API Gateway Authentication You! awslounge.onegeek.com.au Twitter Fetch Twitterfeed Twitter Push IoT Message Broker Sentiment Analysis Checkpoint Amazon ML #awsmelb Challenges > Async > Contract Tests
- 66. 66 Authentication Twitter Fetch Twitterfeed Twitter Push IoT Message Broker Sentiment Analysis Checkpoint #awsmelb Challenges > Async > Contract Tests > Contracts are everywhere! Contract Contract Contract Contract Contract Contract Contract Contract
- 67. WHAT WE AREKNOWN FOR 67 Problems with automated e2e tests ● Slow ● Easy to break ● Hard to fix ● Scales badly across teams ● Lots of set up maintenance ● $$ potentially costly Challenges > Async > Contract Tests
- 68. 68 C P mock Challenges >Async > Contract Tests Understanding Test Symmetry
- 69. WHAT WE AREKNOWN FOR 69 Test symmetry Solved problems New problems ● Hard to keep both sides in sync ● Fast feedback ● Few dependencies ● No dedicated environment ● Reliable ● Easy to debug Challenges > Async > Contract Tests
- 70. 70 C P mock Challenges >Async > Contract Tests
- 71. 71 C P mock Challenges >Async > Contract Tests
- 72. PPCC mock contract Challenges > Async> Contract Tests
- 73. Bug turnaround - minutes Contractstests Challenges > Async > Contract Tests
- 74. Know before you commit Contractstests Challenges > Async > Contract Tests
- 75. Make changes with speedand confidence Contracts tests Challenges > Async > Contract Tests
- 76. Deploy independently Contracts tests Challenges> Async > Contract Tests
- 77. Better API design (Consumer) Contractstests Challenges > Async > Contract Tests
- 78. 78 ● Open source ●Multiple languages ○ Javascript ○ Go ○ Python ○ JVM ○ .NET ○ + more pact.io ● HTTP contracts ● Message contracts ● … protocol agnostic! Challenges > Async > Contract Tests
- 79. Challenges > Async> Contract Tests Expectations on Sentiment Analyser made clear
- 80. 80 Acceptance Tests vsCanary Release Challenges > Async
- 81. Summary 81 Summary Problems ● Serverless complexity> uServices ● Testing cloud native services ● Avoiding vendor lock-in ● Handling events and asynchronous Fn’s ● More Fn’s = more things!
- 82. Summary 82 Summary Problems Solutions ● Microservices+ ●Create cloud and protocol anti-corruption layer ● Mock out AWS SDK in unit tests ● Use contract tests ● Reduce reliance on end-to-end environments ● Balance ad-hoc exploratory + acceptance tests ● Serverless complexity > uServices ● Testing cloud native services ● Avoiding vendor lock-in ● Handling events + asynchronous Fn’s ● More Fn’s = more things!
- 83. Testing large-scale, serverless andasynchronous systems Matt Fellows @matthewfellows ...without end-to-end integrated tests!