Common sense says that application logging is a good thing. But common advice doesn’t answer questions like: what to log, when to log, or the format to log, which can get really frustrating especially if you’re looking for precise guidance on to structure your logs. Today, we’re going to change that.
After years of struggling to find a canonical this-is-how-you-should-log advice I came across a concept of: one-per-service logs. But be warned: It’s a heretical idea that challenges common logging advice. But after my own experiments with the one-per-service logging, I’ve found it to have considerable benefits.
By the end of this article you will understand what a one-per-service Phat Event log is and why they can be superior to regular log entries.
AWS (Amazon Web Services) is overwhelming. If you’re new to AWS you’ll know all too well the feeling of being lost and not knowing where to start. Today, we’re going to change that. We’re going to clear the mist of uncertainty and discuss everything you need to know to begin your learning journey on AWS.
Today we’ll talk about three things that will help you start learning AWS. And they are: focusing on the core services, getting hands-on and structuring your learning. We’ll go through each area in a decent amount of detail, so that you have a great starting point for your learning.
By the end of this article you’ll have an understanding of the core services of AWS, how to structure your learning around them and how to get up and running with some hands on experimentation.
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.
If you’re new to Terraform, you might have started experimenting creating resources. Before long it’s likely that all your Terraform files are inside one large file, or even many large files.
After a certain amount of time this process will start to break down and become hard to maintain. And that’s where Terraform modules come in.
By the end of this article you’ll understand the basics of Terraform modules, and know how to break down large Terraform files into modules.
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.