Monitoring platform for keeping systems up and running at all times.
Full stack visibility across the entire stack.
Detect and resolve any incident in record time.
Conform to industry best practices.
Dashbird continuously monitors and analyses your serverless applications to ensure reliability, cost and performance optimisation and alignment with the Well Architected Framework.
What defines a serverless system, main characteristics and how it operates
What are the types of serverless systems for computing, storage, queue processing, etc.
What are the challenges of serverless infrastructures and how to overcome them?
How systems can be reliable and the importance to cloud applications
What is a scalable system and how to handle increasing loads
Making systems easy to operate, manage and evolve
Learn the three basic concepts to build scalable and maintainable applications on serverless backends
The pros and cons of each architecture and insights to choose the best option for your projects
Battle-tested serverless patterns to make sure your cloud architecture is ready to production use
Strategies to compose functions into flexible, scalable and maintainable systems
Achieving loosely-coupled architectures with the asynchronous messaging pattern
Using message queues to manage task processing asynchronously
Asynchronous message and task processing with Pub/Sub
A software pattern to control workflows and state transitions on complex processes
The strategy and practical considerations about AWS physical infrastructure
How cloud resources are identified across the AWS stack
What makes up a Lambda function?
What is AWS Lambda and how it works
Suitable use cases and advantages of using AWS Lambda
How much AWS Lambda costs, pricing model structure and how to save money on Lambda workloads
Learn the main pros/cons of AWS Lambda, and how to solve the FaaS development challenges
Main aspects of the Lambda architecture that impact application development
Quick guide for Lambda applications in Nodejs, Python, Ruby, Java, Go, C# / .NET
Different ways of invoking a Lambda function and integrating to other services
Building fault-tolerant serverless functions with AWS Lambda
Understand how Lambda scales and deals with concurrency
How to use Provisioned Concurrency to reduce function latency and improve overall performance
What are Lambda Layers and how to use them
What are cold starts, why they happen and what to do about them
Understand the Lambda retry mechanism and how functions should be designed
Managing AWS Lambda versions and aliases
How to best allocate resources and improve Lambda performance
What is DynamoDB, how it works and the main concepts of its data model
How much DynamoDB costs and its different pricing models
Query and Scan operations and how to access data on DynamoDB
Alternative indexing methods for flexible data access patterns
How to organize information and leverage DynamoDB features for advanced ways of accessing data
Different models for throughput capacity allocation and optimization in DynamoDB
Comparing NoSQL databases: DynamoDB and Mongo
Comparing managed database services: DynamoDB vs. Mongo Atlas
How does an API gateway work and what are some of the most common usecases
Learn what are the benefits or drawbacks of using APIGateway
Picking the correct one API Gateway service provider can be difficult
Types of possible errors in an AWS Lambda function and how to handle them
Best practices for what to log in an AWS Lambda function
How to log objects and classes from the Lambda application code
Program a proactive alerting system to stay on top of the serverless stack
DynamoDB offers two ways to access information stored: Query and Scan.
A Query will rely on the primary-key to find information. Query can point directly to a particular item (or set ot items) and retrieve them in a fast and efficient way.
primary-key
Scan, as the name suggests, will browse table items from start to finish. The sort-key allows to determine the scanning order direction.
sort-key
It is possible to apply filtersto both a Query and a Scan operation and control which items are returned. Filters do not contribute to optimizing the operation. They are applied after the operation execution and before results are returned.
filters
Running a Scan is expensive and inefficient, thus should be avoided in almost all use cases. Unless one really needs to browse the entire set of items, for instance.
Querying by the primary-key is the most efficient manner of retrieving data from a DynamoDB table. Most applications require more flexible querying capabilities[^1], though.
DynamoDB supports transactions and conditional updates for enhanced data integrity.
Transactions work similarly to traditional databases: either all queries in a transaction succeed or none does. This is useful when there are queries coupled with each other.
A common example is a banking balance: when transfering funds from Account A to B, we want to avoid crediting one account without debiting the other.
Conditional updates are useful to link a write request to a particular item value. Say Account A wishes to transfer $10 to Account B. The request should only proceed if the current balance is greater than or equal to $10.
The system could read the balance first, then issue the transfer request. But a second transfer request may be received in the meanwhile. This could lead to a negative account balance. Conditional updates are verified atomically, avoiding race conditions.
Due to its distributed and high availability model, DynamoDB stores each item in various servers. To update an item, each server version must be renewed. Since read requests can be served by distinct servers, an inconsistent value for the item can be provided.
That is the default model for read requests in DynamoDB. If a read request somes too close to a previous update, it might serve an old version of an item. That is called eventual consistency.
This model can be a problem to some applications. In the bank account example, a possibly outdated balance cannot be used to validate a request to transfer funds.
For that reason, DynamoDB offers a strong consistency model. When this option is set to True in a read request, Dynamo will make sure the value returned is the most up-to-date across all copies of the item.
True
DynamoDB can generate a constant stream of time-sorted write operations in a table. Streams can be used by external applications for various purposes.
A possible use case is aggregating metrics from multiple operations. A table receives user likes to a social media post. A service can aggregate to count total likes, for example.
Streams can group items up to a certain number of operations or for a given time period. It could buffer social media likes for, say 15 minutes. Hundreds or thousands of likes might come in during this time. The aggregator service updates the total likes value only once, which saves resources.
Each item in a Stream can contain the previous and new version of the item, so it’s possible for the Stream consumer to evaluate what has been changed by each operation recorded.
Items can have an attribute called ExpirationTime. When it’s set to a unix timestamp in the future, DynamoDB will auto-delete the item when the time expires. This is useful to keep tables clean when data loses relevance over time.
ExpirationTime
Then the TTL process auto-deletes an item from a table, it is also recorded in Streams. This can be used to audit expired items. A service consuming streams can move old data to a cold storage, for example.
[^1] Refer to the Access Pattern Strategies page
No results found