As the famous saying goes, “reach for the stars”, and who better to embrace this ideology than the tech industry that for the past few decades has redefined innovation. We may not have reached the stars yet, but we definitely do see a shift to the cloud. Considering its humble beginnings, the question in today’s day and age is not “should we migrate to the cloud?”, but how? This trend is reflected in various reports, community discussions, and literature on the matter.

Microservices have become the answer to the many challenges faced when building reliable, robust, and scalable applications. However, visibility through event-driven microservices is difficult to achieve due to the asynchronous nature of such architectures.

API is the most important part of any customer facing web application since it’s directly tied up to the satisfaction of customers and the health of the business. Among numerous alternative ways of creating an API, serverless is one approach gaining popularity during the last few years because of its cost efficiency, scalability, and relative simplicity.

Serverless has brought many benefits to the application owners such as scalability, reliability, pay-per-use, and so on. However, building applications in a “serverless” way does not sweep away the errors which stems from bad coding practices, broken third-party integrations, and many other reasons. Moreover, serverless introduces some new types of unique failures such as timeout errors, or out of memory errors.

Thundra provides rich auto-tracing out of the box to instrument AWS SDKs, infrastructure, and Lambda. Engineers can enhance the traces to provide additional business context. This enhancement is referred to as “logical” or custom spans, which help end users debug and understand performance in the context of business operations. Logical tracing isn’t difficult, but it does require custom instrumentation.

When I invited Tim Wagner to our recent “State of Serverless in 2020” webinar, I was very surprised and excited to hear he was working on something new, but at the time it was still in stealth mode. Considering the vision he created for serverless, I immediately thought that this will be the next big thing for the cloud enthusiasts.

Mono-repo or multi-repo is a decision every organization must make at a certain point if it has a growing number of services. As your organization grows, speed and performance become critical, and you’ll need to decide whether to structure your services in a single repository or use a separate one for each service. Developer productivity and fast delivery of business values are a necessity if you want to take on the competitors.

So what’s a monolithic application anyway? It’s essentially an application where almost every single piece of functionality has been written in the code by its developers and is typically built to run as a single unit on a single server. A typical example is WordPress, by far the main model in the past, and many applications are still developed this way today. Monolithic applications can come with a number of issues.

AWS SAM is rapidly growing in popularity. It’s a powerful tool for serverless development that integrates development, testing, and deployment strategies behind a comprehensive CLI, and it’s also a model of development that’s extensible and flexible. While AWS SAM does a lot to reduce configuration complexity, this doesn’t necessarily translate into greater platform observability.