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 is a managed NoSQL database by Amazon Web Services. MongoDB Atlas is a managed service used to provision, maintain and scale clusters of instances running the MongoDB database engine.
In this comparison, we will not cover DB differences in terms of data model, schema, and access patterns. For this, please refer to the DynamoDB vs. MongoDB page.
The main advantages of each service are:
TL;DR: As part of the AWS ecosystem, DynamoDB provides great integration with other cloud services. Integrating MongoDB would require considerably higher development and maintenance efforts.
DynamoDB integrates with other AWS Services, such as AWS Lambda.
It is possible, for example, to:
As a standalone database system, MongoDB Atlas does not integrate out-of-the-box with other AWS services. Any integration would need to be implemented by the development team.
TL;DR: DynamoDB offers high scalability by relying on HTTPs API endpoints. Mongo, on the other way, still requires socket connections, which can be an additional source of bottleneck in the database infrastructure.
Applications don’t need to open connections in order to query a DynamoDB table. All operations are performed through HTTPs endpoints, which makes it as scalable as possible.
MongoDB requires a TCP socket connection open in order to perform operations. There is a maximum number of concurrent connections in MongoDB Atlas, which depends on the server instance1.
MongoDB connection model offers some constraints that might collide with the high-concurrency of the serverless paradigm. In projects using high-throughput compute services, such as AWS Lambda, this can be a problem.
TL;DR: DynamoDB offers unparalleled scalability. For small to medium sized applications, MongoDB Atlas would probably meet throughput and storage scalability requirements, though. For projects that expect high increases in demand, DynamoDB might be the safest option to cope with growth.
MongoDB Atlas uses a sharding2 strategy to distribute documents (items in the database) across multiple nodes, in order to cope with higher scalability needs.
DynamoDB can scale to virtually as many instances as needed. The scaling model of DynamoDB is based not only on data storage, but also I/O demand. When the application demands higher read/write throughput, it automatically increases the number of instances in the background to handle the load.
One of the main differences between the two services that arise at this point is: Atlas exposes instance provisioning to the developer, while DynamoDB abstracts all that away.
Using sharding restricts3 the usage of some database features in MongoDB, while DynamoDB offers the same feature-set regardless of the scale level. How many shards it’s possible in MongoDB and the maximum data size it can hold depends on a formula4.
In the best-case scenario, MongoDB can store up to 32 Terabytes of data.
In DynamoDB, developers can store virtually an infinite amount of data. Throughput level is controlled by provisioning I/O capacity5, or select an on-demand model6, in which DynamoDB will optimize I/O allocation according to demand.
In summary, DynamoDB scalability model requires very little to no effort at all from developers. MongoDB Atlas is not as straightforward and cannot provide a throughput threshold that developers can trust in advance.
TL;DR: Very similar offering from both services. Since MongoDB Atlas can be deployed on AWS itself, developers can benefit from the cloud provider’s high reliability.
DynamoDB follows the battle-tested AWS Multi-AZ7 and Multi-Region8 implementations, providing maximum reliability possible.
MongoDB Atlas uses multiple replica-sets9 to maintain the same dataset across multiple nodes in order to achieve high reliability and availability of the data.
TL;DR: Backup options are quite similar in both services and would meet the needs of most cloud applications.
DynamoDB provides two backup options:
Point-in-time backups protect the application against mistaken modifications to the data. It eliminates the need to schedule and run periodic on-demand backups, since it automatically keeps a record of multiple versions of the table.
DynamoDB backup processes (creation or restoration) run in the background using a state-of-the-art technology model that allows to backup an entire table in a matter of a few seconds, regardless of its size. A backup process does not affect table performance and capacity. Backups are retained on external and highly durable storage.
MongoDB offers similar features for backing up data:
TL;DR: By relying on an open-source engine, MongoDB Atlas provides much higher portability than DynamoDB, which is a proprietary, closed-source database system.
Since Mongo Atlas relies on MongoDB, which is an open platform, it naturally offers higher portability than DynamoDB. Atlas itself can run on multiple cloud providers.
Nonetheless, some users have reported an unusual difficulty when they tried to move data out10 of Mongo Atlas. Although it doesn’t prevent developers from porting its databases to another service, this increases migration costs.
DynamoDB, in fact, provides zero portability. It is impossible to run it outside of AWS domains. Lock-in worries are legitimate and should be considered in this case.
For projects in which it’s important to keep the option of migrating to another cloud provider in the future, using DynamoDB can impose big migration costs down the road. There is no other database on the market that can serve as a drop-in replacement for DynamoDB API and functionalities. In the event of a migration out of DynamoDB, considerable refactoring work of the application will be required.
TL;DR: Both services provide a level of security that should be enough for most production cloud deployments. Applications in financials or health data industries might need extra security only provided by AWS.
DynamoDB provides simple and easy-to-use encryption-at-rest, either with AWS’s keys or custom keys by integrating with AWS KMS (Key Management Service)11.
Encryption-in-transit is provided through HTTP REST API endpoints using TSL (Transport Layer Security) and encryption models with the highest security standards. If it is necessary to expose DynamoDB for connections from external on-premise systems, AWS offers Site-to-Site VPN connections12 option. Each endpoint provides certain functionality. Some examples below:
DynamoDB relies on the battle-tested IAM (Identity Access Management)15 service. In short, data consumers can use IAM roles and policies with fine-grained permission levels that are used to authenticate and authorize connections to a certain DynamoDB endpoint in order to perform data-level and database-level operations.
In MongoDB Atlas, IP addresses must be whitelisted, which can be a problem for applications using ephemeral compute services, such as AWS Lambda (no fixed IP unless in a VPC).
Clusters can be deployed in a VPC (Virtual Private Cloud16), providing security and isolation to the networking. MongoDB also offers TLS and LDAP17 and a user authentication mechanism as an added security layer.
No results found
End-to-end observability and real-time error tracking for AWS applications.