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.

At this moment, billions of people are rushing to the internet for work, entertainment, shopping - everything, really. It’s great that we developed this virtual world and can keep the lights on, despite what’s happening outside. On the other hand, cloud systems and developers are under pressure to meet an unparalleled demand. At Dashbird, we have always thought developers deserve the most efficient tools to discover and resolve issues in order to keep cloud apps running smoothly.