Lambda functions on their own are pretty useless. Lambda’s need someone — or something — to initiate them. An important (and fun) trigger for Lambda is the CloudWatch event. With CloudWatch events we can trigger Lambda’s on a recurring schedule that we define.
Scheduled Lambda’s are useful for executing tasks like backups, or running security scanning. Today we’re going to go through what you need to do in order to Terraform Lambda Scheduled Event’s. We’ll cover everything you need to know about CloudWatch Events, CloudWatch Event Targets and Lambda permissions.
By the end of this article you’ll know how to execute a Lambda on a scheduled CloudWatch event (and write it all in Terraform).
Your AWS Lambda code is throwing errors in production. To defuse the situation, you need to pinpoint what’s going wrong and find the fix. It’s a good thing you already instrumented your Lambda with high quality, well structured logs, right?
There are many aspects to monitoring a distributed system. And a big part is understanding how, and what to log. But, fear not, you’re in the right place!
Today we’re going to talk about the first step: how you can get Lambda logs into CloudWatch for analysis. Once we’ve discussed that, in the next article, we’ll discuss how to analyse those logs to properly extract the data.
By the end of this article you’ll understand the three steps you’ll need to take to enable CloudWatch logging for a Lambda function.
The marketing around Serverless likes to make it out like “spinning up” a function is a simple task with no other dependencies. However, Serverless functions have to be triggered somehow. And one of your options is to use AWS Lambda with an ALB.
But if you’ve just learned AWS Lambda and want to set it up with an ALB you’re about to run face first into a ton of new jargon: target groups, listeners, listener rules, ports etc. So if you’re not already familiar with AWS ALB and it’s various ideas you’re going to need to get up to speed.
By the end of this article you’ll understand the main concepts related to AWS ALB’s so that you can expose your Lambda function publically.
Recently I’ve been experimenting with Github Actions as a CI tool, specifically for setting up AWS Lambda on Github Actions.
Container based CI is awesome. And I’m really excited about the community that is building up around it. I hope with container based CI we spend less time fighting CI, and more time building apps.
But until we get there — I’ll try and make the CI fighting a little less painful by giving you a head start. And in this case, we’ll be pushing zipped artifacts for AWS Lambda on Github Actions.
AWS Lambda works by associating artifacts with the running Lambda exectuion. Therefore it’s quite common to zip our artifacts and upload them onto S3 to be used by Lambda. Today I’ll walk you through a quick three step method to upload zipped artifacts onto AWS for later use with AWS Lambda.
By the end of this article you’ll know the first step towards working with AWS Lambda on Github Actions and that means setting up pushing of zipped artifacts to S3.
Microservices have been talked about a lot in the last few years. And it’s commonly accepted practice that applications should start as monolithic applications before being broken down into Microservices. In fact that’s exactly how we made Splitoo.
Earlier in 2019 I made a commitment to improve some technical aspects of Splitoo. One of which aspect you could call Microservices. At Splitoo since we’re a small team, we made some fairly intuitive decisions to break down the application into Microservices based on some tell-tale signs that it needed it.
What we realised is that our decisions to break down the app came from getting more intuitive about the tell-tale signs that an application is getting too big, and could benefit from being broken down into microservices. And that’s what we’ll be talking about today.
By the end of this article you should know four tell-tale signs that an application could benefit from being architected with a Microservice approach.
So you’ve been hearing a lot about Serverless? Maybe you’ve started to see some tell-tale signs your app could be broken down into microservices?
Serverless is a really awesome technology in the realms of Cloud Native Software Engineering. But, it can be a bit of a hard concept to get your ahead around if you’re not already familiar with many concepts of serverless.
Serverless computing as a principle is fairly easy to understand. But in order to effectively work with Serverless there are some other concepts that you should know about before you get going. And today we’re going to cover some of these unknown unknowns for working with serverless.
Today we’re going to discuss the following 6 concepts you need to know in order to get going with Serverless: Cloud Provider Knowledge, Microservices, Distributed Systems, Deployments, Monitoring & Observability and Infrastructure as Code.
By the end of this article you should know the main concepts related to serverless and you should be confident in developing your own Serverless application!
Hello all and welcome to the first in an in-depth multi-part series on breaking down a monolithic application into a Cloud Native Lambda-based architecture!
Can you say #buzzword!?
Only kidding — we’ll be low on jargon but high on details today. I’ve not (yet) done a real series on this site, so I’m pretty excited!
By the end of this article you’ll know how to get setup and running with the Serverless Framework on AWS to create an HTTP Lambda-based API.
Here is my latest post for Raygun.
If you’re thinking of running a serverless setup, congratulations!
But…that means you’re running a distributed system.
With all the benefits and simplicities that come with going serverless comes this tradeoff: You potentially also have some increases in complexity.