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.
Ever had to SSH into a production server to manually copy over files, or to run a command? Palms sweaty and shaking. You don’t know what the outcome of the update will be, and if something goes wrong the system could go down? If you haven’t, you’re one of the lucky ones!
Making manual changes onto an existing server means you’re likely operating with “mutable infrastructure” — whether you know it or not. But, there is another way. And that’s immutable infrastructure. And today we’re discussing exactly that, what immutable infrastructure is, the benefits and the tools you can use to implement it.
By the end of this article you’ll have a clear understanding of what immutable infrastructure is and why it’s important, the pro’s, con’s and trade offs.
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.
Everyone keeps talking about “Infrastructure As Code” but when you read about it, you feel stuck and frustrated. A long time ago a lot of your cloud infrastructure was created manually and it’s now all a bit of a mess.
Infrastructure As Code feels like a million miles away for you…
If that sounds too real for you, fear not. Because there is a way to get a state-of-the-art Infrastructure As Code workflow applied onto your existing infrastructure, and it’s easy. Let me show you how.
With Terraform it’s possible to bring existing infrastructure under code management in a safe, and incremental way. And today we’re going to go through the three steps you’ll need to take if you want to apply Terraform Infrastructure As Code to your existing infrastructure.
By the end of this article you’ll understand the 3 steps to get started with Terraform Infrastructure As Code on existing infrastructure.
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.
Ever wanted to learn Kubernetes? Serverless? Write some Microservices in AWS or GCP? Awesome… But don’t. Or at least, not yet. Why? Because the first thing you should learn is Terraform. Don’t touch Serverless. Definitely don’t touch Kubernetes, and I’d probably not even bother creating an AWS S3 bucket.
There are many reasons for you to be excited to learn Cloud Engineering as a whole. But no other decision impacted my ability to learn Cloud Engineering than: first learning Infrastructure As Code. In hindsight, I wish I did it sooner.
In todays article I’ll try (and hopefully successfully) to convince you why Infrastructure As Code is the most logical starting point for learning Cloud Engineering concepts and tools.
By the end of the article you’ll know what Infrastructure As Code (with Terraform) is and I’ll give you 5 reasons why Terraform should be your starting skill when learning Cloud Engineering.
Yarn doesn't handle the underlying NPM infrastructure with elegance — and it might never do so.
I’ve spent the last few days wrangling with Yarn errors. Our builds we’re failing in some weird and random ways — and all signs pointed at Yarn. I can give you the TL;DR; of the investigation, and it’s this: Yarn doesn’t handle upstream NPM infrastructure errors in ideal ways.
But the problem is not that Yarn code is buggy — the problem is in the disconnect which exists between Yarn (the client) and NPM’s infrastructure. The errors caused are significant enough to start conversations for moving to the NPM client. But moving back to NPM raises a bigger question about the viability of third-party package managers that rely on NPM infrastructure.
Not all infrastructure as code is born equal. Some styles of infrastructure as code give us great benefits — whereas other kinds can cause a lot of headache.
Writing good infrastructure as code doesn’t mean simply bundling code that creates infrastructure into a repository and walking away. Knowing the in declarative vs. imperative infrastructure as code can mean the difference between having an easy life or a total nightmare.
By the end of this article you’ll know what the difference is between declarative and imperative infrastructure as code, why it matters and when you should use each.
AWS Access Keys are how you can programatically access the AWS cloud. AWS Access Keys can be used to provision, update — or even delete cloud resources. When it comes to your cloud account, personal or work you don’t want your account to be compromised — it could cost you at a minimum thousands of pounds. So keeping your AWS Access Keys safe is paramount.
Managing your AWS Access keys isn’t as scary as it first seems. With a little knowledge you can experiment and build software in the cloud, all whilst staying safe.
By the end of this article you should know what AWS keys are, why they’re important and five tips you can use to make sure you’re safe when using your access keys.