Both DynamoDB and MongoDB are NoSQL databases, but the similarities probably end there. In this article, we cover their strengths and weaknesses in 8 basic categories, so that you can decide which one suits best your needs. While the data model behind Mongo is more flexible for storage and retrieval, Dynamo is stronger in terms of scalability, consistent performance under heavy load, and infrastructure abstraction.
We recently wrote about the reasons why serverless apps fail and explored some ideas to make architectures more resilient and scalable. Some of these architectural designs can become expensive if we don’t consider the financial impacts of architectural decisions. With proper care and consideration to this aspect, it is possible to achieve the same value in terms of scalability and resiliency while keeping costs at a manageable level.
There is an interesting discussion going on around how Serverless is more of a spectrum rather than a binary choice. The move towards the Serverless-end of the cloud spectrum builds upon a decades-old trend, which is why Serverless is here to stay.
We’ve been monitoring 100,000’s of serverless backend components for 2+ years at Dashbird. In our experience, Serverless infrastructure failures boil down to: These isolated faults become causes of failure due to dependencies in our cloud architectures (ref. Difference of Fault vs. Failure). If a serverless Lambda function relies on a database that is under stress, the entire API may start returning 5XX errors.
Dashbird, a platform for serverless application monitoring, has raised $2.1 million in a seed round. The investment was led by Paladin Capital Group, with participation from Passion Capital, Icebreaker.vc and Lemonade Stand.
We recently wrote about why serverless applications fail and how to design resilient architectures. Being able to detect early-stage failure indicators can be invaluable. With proper monitoring, developers move from waiting for the system to crash and adopt a more proactive attitude in managing resource allocation and architecture design to avoid bottlenecks and performance degradation.
Cloud applications don’t just run flawlessly by way of magic. Many things can go wrong, and rest assured some will go wrong at one point. For small teams, this can be cumbersome and take a toll at the development speed. A monitoring system will detect these issues on behalf of the development team, so that they can act accordingly. At Dashbird, we think there’s much more to it, though, than just detecting and alerting issues, especially for small teams of developers.
No matter how careful developers are or how comprehensive tests are applied before deployment, there will always be some level of issues to deal with in production. When it comes to managing issues and ensuring application quality, two main metrics should be on our radar: time to discover and time to resolve issues.
That is a common question I see among developers. Most of the time, nobody cares about system logs. But when things go south, we absolutely need them. Like water in the desert, sometimes! At Dashbird, we have a list of criteria compiled to determine a reasonable retention policy for application logs. There is no one-size-fits-all, though. The analytical dimensions below will give a relative notion of how long the retention period should be.
With the rise of cloud computing and modern distributed systems, we also witnessed the rise of a new practice area: DevOps. Despite being fundamental for smooth cloud operations, a dedicated DevOps practitioner is a luxury most teams can’t afford. Salaries average $130K in San Francisco, for example. When a dedicated DevOps practitioner is not available in our team, what should we do? The answer could unfold a multitude of aspects.
