If you’re coming into the world of Serverless, especially if you’ve worked in a server-based world, you can end up confused about who exactly “sets up the environment in serverless”, and how the environment in Serverless works.
The whole Serverless ecosystem can be daunting—it definitely was for me when I started. At the end of this article, you’ll have more understanding about serverless, specifically how the environments are setup and hopefully you’ll have some “aha!” moments along the way!
In Serverless Who Sets Up The Environment? In Serverless the environment is setup by the cloud provider. Many server-like access, such as process, log files, and SSH are unavailable to a Serverless user. However, different services and tools are available for serverless users to achieve similar behaviours to their server counterparts.
To understand Serverless, you need to approach the idea with a “fresh mind”. If you have any existing notions about how applications / servers work, try to disregard those ideas for today. Let’s try and get your mind into the “serverless” way of doing things. Between server and serverless architectures, some things are the same, but many things are not.
If you’re just starting out working with AWS Lambda there are a LOT of things for you to understand. And of course, one of those areas is going to be: testing.
How to test AWS Lambda? AWS Lambda can be tested manually using the AWS console with test events. In addition to manual testing, AWS Lambda can also be tested through local replication with tools like as docker-lambda. Or finally, testing AWS Lambda can be done using an automated (CI) pipeline for running unit, component and integration tests.
There’s a few different ways you can go about testing AWS Lambda, today we’ll run through these different options, and I’ll let you know what has worked best in my experience and where I’d suggest you spend your energy on.
Ah, so you’ve reached that point: you’ve been through the euphoria and the buzz of setting up a Lambda function, and the eureka moment when everything is running… but then everything comes crashing down when you realise how painful debugging AWS Lambda is! I know, because I’ve been there too.
How to debug AWS Lambda? Debugging AWS Lambda is achieved through a range of different methods: using local debugging tools e.g. docker-lambda and serverless offline, through monitoring tools e.g. CloudWatch and through the implementation of a test harness.
The topic of debugging an AWS Lambda function can get complicated quickly, as there’s lots of different options and approaches. Today I’ll walk you through all the different options that you have at your disposal for debugging AWS Lambda. Today we’ll cover everything from Docker Lambda to CloudWatch.
The cloud industry is evolving quickly right now, and when it comes to the big trends likes containers and serverless it can be hard to work out the difference.
Are Containers Serverless? No. Containers are a method of packaging up an application with its dependencies. Container technology does not mandate how the application is to be executed. However there are container platforms which allow you to execute containers in a way that is serverless.
That definition might seem like a bit of a tongue twister, but I’m precise for a good reason, as it is important to understand clearly the boundaries of the two technologies. There’s some nuance involved in answering todays question, so let’s break things down. Let’s start with containers and what they are.
This month AWS announced a new feature called Lambda Extensions (Source). AWS release so many features it is hard to keep up. With each new feature we often need to ask ourselves, is this something we should pay attention to or not?
What is Lambda Extensions, and who should pay attention to it? Lambda Extensions are an addition to the Lambda Runtime API, allowing additional control, setup and tooling. Lambda Extensions are mainly aimed at third-party vendors, particularly monitoring but also configuration and security. Lambda Extensions will also be interesting to heavy users of AWS Lambda functions who need standardisation or greater control on their setups.
Now let’s get into more detail on what Lambda Extensions actually are to help you understand whether or not they might be useful in your situation. Let’s start by looking at a core difficulty that Lambda Extensions help solve.
There are a few reasons why you may want to stop a Lambda. Either the Lambda is buggy or performing incorrectly, your Lambda is reading an event source like kinesis and you need to pause it, or your Lambda is being constantly retried.
Can you stop an AWS Lambda Function? There is no way to stop a currently executing AWS Lambda function. But you can stop future invocations by setting concurrency to zero or disabling integrations.
So, there’s a few different aspects to the topic of stopping a Lambda. Let me take you through some different options for stopping your AWS Lambda function so that you can decide which one makes most sense for your situation.
Architecting solutions using AWS Lambda means understanding many nuances in how AWS works, and a main consideration for our application architecture is the database. So we’ll need to need to know whether AWS Lambda can connect to a database at all, and what our options are.
Can AWS lambda access a database? Yes. AWS Lambda can connect to an AWS hosted databases such as RDS or DynamoDB. AWS Lambda can also connect to external databases which are public or grant network access.
Dependent on the database you’re using (or intending to use) there are some considerations you should address. Let’s now go through the different options you have for integrating a database with AWS Lambda, and address some of those considerations so you can make an informed decision.
When it comes to operating Lambda, we often want to configure alarms to alert us when things aren’t running smoothly. Naturally our first choice for Lambda alarms is CloudWatch, the default monitoring service that comes with AWS.
CloudWatch gives us some custom metrics out-of-the-box, such as: errors and invocation rates. But there are some problems we run into when setting up alarms based directly on these metrics.
By the end of this article you’ll understand why alarms based on default AWS Lambda Metrics can cause difficulty, how AWS Metric Math helps us to apply “context” in our alarms and make them more effective, and how to setup an alarm using metric math to calculate an error rate percentage.
Are you creating a lambda function? Are you currently debugging wondering where you can access the output of your console.log entries?
Understanding how logs work is a common confusion area when working with AWS Lambda. Today, we’re going to clear up the confusion and get your hands on your AWS Lambda logs so that you can start to debug your Lambda function.
By the end of this article you’ll understand how and where console.log output goes from an AWS Lambda function, and also how to debug your AWS Lambda setup if you’re still not seeing log output.
When it comes to working with Serverless and AWS Lambda there are many different tools and approaches to choose from. You may have heard about a few already and might be wondering about the differences. To be quite frank with you—there were some aspects I wasn’t event totally sure of myself.
Working with Serverless requires overcoming a few obstacles: How to run your functions locally? How to create your infrastructure? How to deploy your applications? Today we’ll take a look at five main serverless approaches that attempt to help with these obstacles: manually configuring, using Serverless Framework, Terraform, CloudFormation, and SAM.
By the end of this article you should understand what the main approaches to Serverless are and when to consider using them.