�ݺ�ߣ

Editor's Notes

• #2: Hello ZED Conference 2021Let’s talk about …
• #3: Based on real life experience in Insurance domain
• #4: Kharkiv, Ukraine Solution Architect Passionate and successful Architect with over 17 years of experience including 6 years of experience in Software Architecture Experience in Digital Transformation projects with Microservices & Serverless Multi-cloud experience: AWS, Azure
• #5: Next evolution of cloud computing. Serverless <> not only lambda, it is serverless DBs Engines, Container services, BPMN engines. Servers not have gone you do not manage them only.
• #8: Faster time to market (Business logic –> API) – >Messaging & Orchestration -> Storage & Databases -> Compute -> Physical Infrastructure AWS Lambda automatically runs your code without requiring you to provision or manage infrastructure. Just write the code and upload it to Lambda either as a ZIP file or container image. Focus on most important part of your application Technology abstraction allows us to focus on building just the pieces of code and configuration that are providing truly unique value for the client. Productive for the day one
• #9: Cost optimized with millisecond metering With AWS Lambda, you only pay for the compute time you consume, so you’re never paying for over-provisioned infrastructure. You are charged for every millisecond your code executes and the number of times your code is triggered. At its most basic, the cost case for serverless boils down to utilization. You’ve probably seen the numbers — traditional, on-premise datacenter servers tend to be only 15 to 30% utilized. (We’ve even heard that most large EC2 users struggle to reach this utilization rate as well!) Put the other way, that means 70 to 85% of your server costs are dead weight. Waste. Аналогия – абонемент в спортзале No hidden costs: Security Platform outdated (personal story) test environment for 18 teams ~ $400
• #10: Scale from zero to infinity and back Consistent performance at any scale(smooths) With AWS Lambda, you can optimize your code execution time by choosing the right memory size for your function. You can also keep your functions initialized and hyper-ready to respond within double digit milliseconds by enabling Provisioned Concurrency.
• #11: Easy to start new project, very cheap, modularity, elasticity Experiments, new environment, iteration cycle A lot of integrations. Event based. Out of the box. Architecture improvement: breaking the monolith into functions that could be independently deployed, meant that they were better able to split the team up to work on more things in parallel, and to deploy each feature separately Next evolution of cloud computing. Continuously improving: ARM + Graviton
• #13: Don’t invent a wheel and review AWS resources Try to search and adopt existing to your case Also this is a good reason to learn how to draw diagrams for AWS
• #14: AWS Well-Architected Framework The AWS Well-Architected Framework Lens provides a set of foundational questions for you to consider for all of your cloud architectures. Serverless Lens Description The AWS Serverless Application Lens provides a set of additional questions for you to consider for your serverless applications.
• #15: Tell how you open AWS console, add workload, grouped questions, download a report
• #16: Tell how you open AWS console, add workload, grouped questions, download a report
• #18: Serverless can gain polarized opinion starting from “use it everywhere, it’s cool!” to “just a hype, I’m good with my Java 5 + tomcat”And this emotional attitude often drives technology selection That’s why this slide is more about myths about serverless than about antipatterns Myth #1: Serverless means “no server and hardware” Servers not have gone you do not manage them only. And sometimes this abstraction leaks – for lambda you need to setup required RAM size Serverless more means “no infrastructure work” – all the infrastructure maintenance is on provider Portability, Vendor lock Myth #2: Serverless == Lambda (AWS Lambda, Azure Functions etc.) As Serverless means “no infrastructure work”, many of services familiar to you are already serverless. AWS S3 for example. Amazon enumerates as serverless such services as S3, SQS, SNS, API Gateway, DynamoDB Even modification of Aurora falls into this category Myth #3: Serverless is cheap, definitely cheaper than serverfull solution Not always, you always should calculate costs ahead to see if it’s good fit Not all workloads are suitable for serverless Example from Insurance domain, predictable loadAd tech, stock exchange – could bad domain example
• #19: The Sirens & Odysseus Antipattern #1: Going stateful (in-memory state) We are not talking about state saved in external service (caches like Redis, databases etc) – that approach is fine But accumulating in-memory state is definitely antipattern: Though lambda instance can be preserved for the next requests (such called “hot start”), it is not guaranteed After lambda run, lambda instance can be terminated anytime So the pattern is: if you need a state, store it in external services. For fast access use distributed caches as AWS ElastiCache (managed Redis) You CAN go with in-memory state if you know what you are doing (lambdas are in warm state, have provisioned/reserved concurrency on – so instances will likely be reused)
• #20: Icarus
• #21: Myth of Jason and the Argonauts Antipattern #3: Use your favorite tech stack without paying attention at cost “I will write this on Spring Boot” can have such downsides: You might need more memory for lambda than for the same logic written in Go or Python (up to 4 times and more) Startup can be much slower in comparison to using plain old java or another language Can be mitigated by keeping lambda at warm state for hot start Often for cold start the startup time can be longer than processing time itself Both memory size and startup time add a cost You are charged on a second basis. Reducing overall duration from 10 seconds to 5 seconds will cut your costs twice Decreasing memory size (because code in Java was rewritten in Go) by two times will cut your costs twice As lambda should be small, you can write it in Go/Python/JavaScript even if you are not a Pro in this language So the pattern is: consider if the cost benefit worth learning a bit of Python No Dependency Injection frameworks?
• #22: King Midas and his touch Antipattern #4: Using old-fashioned way for orchestration “I will save a record in DynamoDB from lambda and then Thread.sleep for another service to update it’s status” Each second if lambda does not do anything, you still pay money Design for retries So the pattern is: Avoid explicit and try to avoid implicit waits Implicit wait – blocking lambda instance awaiting for response from synchronous calls (RESTs) Explicit wait – Thread.sleep, polling messages from queues in while loops, checking state in while loops etc. Use Cloud-Native way of logic organization: Orchestration using AWS Step Functions choreography using message brokers (SQS, EventBridge, Kinesis, DynamoDB Streams)
• #26: Nested Stacks Monorepo – one repo for workload Good to keep order, atomic deployments, PR in one repo, easier engennering best practices
• #27: 11. AWS Account strategy (Sizing (Account per Team), sharing resources, hard to performance test, limits) a. See Laura's Blog for some details on Lambda Concurrency issues :https://myconnections.lmig.com/blogs/n0085283/2019/03/14/aws-lambdas-setting-a-max-concurrency-its-consequences Best practices: - Dashboards Alerts, Notifications Sets of best practices
• #29: Nested Stacks