Operations | Monitoring | ITSM | DevOps | Cloud

We’ve talked about how serverless architecture is a great option for companies that are looking to optimize costs. Just like with all app building and developments, monitoring the performance of your implementation is crucial and we, the folks at Dashbird, understand this need all too well – this is why we’ve spent the better part of the past year and a half to create a monitoring and observability solution for AWS Lambda and other Serverless services.

Due to rapid cloud adoption and with never-ending user requirements, the Azure architecture might become complex and you might eventually lose sight of the overall cloud estate and how it relates to each other. Since the Azure portal was designed in a technology vertical silo and it has near zero application visibility, it is not possible to monitor them as a business application in the Azure portal.

Monitoring and analytics have been an issue for Serverless systems since they were invented. While it’s easy to attach an agent like NewRelic or DataDog to a server or container, function monitoring requires a different approach. Serverless applications, where logic is distributed over a large number of functions, attaching agents or wrappers leads to cost increase and development overhead.

This blog post was written jointly by the teams at Lumigo and Cloudway. It’s a step-by-step guide to AWS Step Functions workflows with full monitoring and troubleshooting capabilities. We will use the “right to be forgotten” GDPR workflow as an example application.

The first keynote is over, the talks have started, and the AWS Heroes all got to feel motion-sick but appreciated in their AWS-supplied VR helmets. Good one Tom Here are my week 1 thoughts: Throughout the keynote it was clear that serverless is here to stay. One detail stood out to me above all others: Nearly half of all new compute workloads in Amazon in 2020 were Lambda based. During Andy Jassy’s keynote, a veritable wall of major customers that use Lambda.

This is part four of the “Well-Architected Serverless” series. In this post, we’ll talk about the Cost Optimization (COST) pillar of the Well-Architected Framework (WAF). Part 1: Security Part 2: Operational Excellence Part 3: Reliability The COST pillar concerns itself with the money you spend on your cloud infrastructure. It’s important to think about your system’s cost because, in reality, the perfect system won’t be used simply because it’s too expensive.

Today, AWS announced another major feature to the Lambda platform: the option to package your code and dependencies as container images. The advantage of this capability is that it makes it easier for enterprise users to use a consistent set of tools for security scanning, code signing, and more. It also raises the maximum code package size for a function to a whopping 10GB.

The serverless technology feels as exciting and challenging as it was deploying our first app to the internet, seeing it come to life, work and also crash a lot. The latter happening more than we wanted at the begging, but later, when we managed to overcome that challenge, we felt like we could do anything. Depending on the interests, we could focus more on our code and leave that task of deploying, monitoring, and giving support for the apps to the DevOps guys.

Serverless architectures are all about offloading as much operational overhead to the cloud as possible. For the past six years, this primarily meant writing business logic as small pieces of code (< 250MB in size) that are zipped up and given to the cloud to run on demand. This simple model deceptively belies the true power of serverless applications. Because modern applications are often composed of a set of small microservices, each compute resource can itself be minimal in size.