#lambdahype

AWS Lambda backed microservices have caught on like wildfire ever since Amazon introduced the first version back in 2014. Dealing with an architecture where your back end logic is distributed over a large amount of functions poses a real problem when a function doesn’t behave as expected. To provide insights into Function as a Service architectures, Dashbird collects all relevant CloudWatch logs and extracts meaningful and actionable metrics which help greatly to bring your service quality up a notch.

One of the requirements highlighted by the Serverless Manifesto is that Metrics and logging are a universal right. As we move towards having more and more serverless microservices, enforcing and supporting said universal right becomes increasingly more important.

While last time we focused on the architecture of a service by presenting a simple made-up example, this time we’ll look at a real-world service we recently built to handle webhooks. In this post we are going to discuss why and how we did this.

In this part, we will combine all of what we learned in previous parts to build a simple example service. We will go through the process of setting up the service, making sure its configuration is correct and we’ll finish off by deploying the service to AWS.

In this part, we will look at Lambda Foundation, a library, which can help us reduce the boilerplate code in our Lambda functions and make functions across services feel more consistent.

In this part, we will introduce the tools and libraries that we believe help us enforce the architecture proposed in Part 1. These are Lambda Tools and Generator Lambda Tools.

In this, the first part of our Lambda posts, we will look at the AWS technologies that make building microservices on Lambda possible - AWS Lambda, AWS API Gateway and AWS CloudFormation