The anti-patterns unique to serverless and how observability can cushion the impact of anti-patterns creeping into your serverless architectures.
Serverless offers opportunities that are transforming how we think about building in the cloud. The days of worrying about complex and brittle cloud infrastructure on which sits your entire business logic are soon coming to an end. All of these responsibilities are increasingly now delegated to a cloud vendor, allowing you to focus primarily on your business logic.
However, as we push more of the responsibilities onto the cloud vendor, we not only give up control — but also observability. This inadvertently leads to a black box situation, where we become unaware of how and why our serverless architecture behaves. This makes it harder to detect anti-patterns, exacerbating the situation.
New adopters of serverless are more susceptible to anti-patterns, so not being aware of — or not understanding the effect of — these anti-patterns, may be frustrating. So it acts as a barrier to serverless adoption.
Observability mitigates this black box effect, and understanding the possible anti-patterns allows us to monitor the right metrics and take the right actions. Therefore, this article goes through some of the major anti-patterns unique to serverless and describes how the right strategy in observability can cushion the impact of anti-patterns creeping into your serverless architectures.
Serverless applications tend to work best when asynchronous. This is a concept that was preached by Eric Johnson in his talk at ServerlessDays Istanbul, titled “Thinking Async with Serverless.” He later on went to present a longer version of the talk at ServerlessDays Nashville.
As teams and companies begin to adopt serverless, one of the biggest mistakes they can make is designing their architecture while still having a monolith mentality. This results in a lift and shift of their previous architectures. This means the introduction of major controller functions and misplaced await functions.
As a result, the function that is in the idle state will also be charged, since it is still technically active. This goes against the pay-as-you-go principle of serverless.
The lack of visibility of serverless into the underlying architecture and how the performance of that architecture impacts users is a significant challenge.
In this article we explore the serverless metrics that are critical to the health of your Amazon Web Services application.
How to best monitor your external and third party API integrations and hold partners accountable to SLAs
And to achieve observability in serverless applications, it's important ... Monitoring checks “known” metrics to evaluate the health of the system.
This article explores the issue of observability, how a serverless environment complicates it. We then describe the journey toward ultimate observability.