AWS AppSync is a fully managed GraphQL service that makes it easy for you to build scalable and performant GraphQL APIs without having to manage any infrastructure! With AppSync, you get a lot of capabilities out of the box. Such as the ability to integrate directly with DynamoDB, ElasticSearch, Aurora Serverless, and Lambda. AppSync also supports both per-request as well as per-resolver caching and has built-in integration with CloudWatch and X-Ray.
Serverless is synonymous with Event-Driven Architecture, where Events are a fundamental block of information that is passed around to execute certain application logic. It is very important that events are delivered to the right destination with expected behavior to make sure the whole serverless application works as one. Events are relayed from one place to another through communication services, either in sequence or in parallel.
This blog post was written jointly by the teams at Lumigo and Cloudway. It’s a step-by-step guide to AWS Step Functions workflows with full monitoring and troubleshooting capabilities. We will use the “right to be forgotten” GDPR workflow as an example application.
Today, AWS announced another major feature to the Lambda platform: the option to package your code and dependencies as container images. The advantage of this capability is that it makes it easier for enterprise users to use a consistent set of tools for security scanning, code signing, and more. It also raises the maximum code package size for a function to a whopping 10GB.
Serverless is a great way to reduce the cost of running applications. Lambda functions, by nature, make it very easy to use the exact amount of resources we need at any given point. In this post, we deep dive into Lambda costs, how they are calculated, and explore how to optimize them. Lambda costs are calculated from two parameters (all prices are for AWS N.Virginia, US-EAST-1).
AWS released Lambda Extensions just over a month ago, and we explained what they are and why they matter. Today, AWS has announced AWS Lambda Logs API, a way for extensions to subscribe to and process Lambda logs in real-time.
There is a growing ecosystem of vendors that are helping AWS customers gain better observability into their serverless applications. All of them have been facing the same struggle: how to collect telemetry data about AWS Lambda functions in a way that’s both performant and cost-efficient. To address this need, Amazon is announcing today the release of AWS Lambda Extensions.
So much has been written about Lambda cold starts. It’s easily one of the most talked-about and yet, misunderstood topics when it comes to Lambda. Depending on who you talk to, you will likely get different advice on how best to reduce cold starts. So in this post, I will share with you everything I have learned about cold starts in the last few years and back it up with some data.
When you build your application on top of Lambda, AWS automatically scales the number of “workers” (think containers) running your code based on traffic. And by default, your functions are deployed to three Availability Zones (AZs). This gives you a lot of scalability and redundancy out of the box. When it comes to API functions, every user request is processed by a separate worker. So the API-level concurrency is now handled by the platform.
A key metric for measuring how well you handle system outages is the Mean Time To Recovery or MTTR. It’s basically the time it takes you to restore the system to working conditions. The shorter the MTTR, the faster problems are resolved and the less impact your users would experience and hopefully the more likely they will continue to use your product! And the first step to resolve any problem is to know that you have a problem.
