DevOps. Platform Engineer. Cloud Engineer. So many terms and roles! But they all seem to mean the same thing. So when it comes to this new term Cloud Engineer. What do Cloud Engineers do all day? And do cloud engineers code?
The short answer to whether Cloud Engineers code is: yes. But, Cloud Engineers don’t write any old code, they write very specific types of code.
By the end of this article you’ll know what a Cloud Engineer is and whether they code (spoiler alert: they do).
So you’ve heard about this Terraform thing and want to get in on the action? Learning a new technology such as Terraform can be a daunting task at first. Today we’re going to go through the best way to learn Terraform so that you can break through the fog of uncertainty and start learning today.
In this article we’ll discuss the different considerations you should make when learning Terraform, the main features you’ll need to know and the features you can safely ignore (at first) to give you the confidence to start working with Terraform.
By the end of this article you should have an understanding of what Terraform is, and the best way to start to learn it.
We’ve talked a lot recently about infrastructure as code and setting up cloud environments. But nothing beats getting hands on with a technology to help learning. A workflow I’ve used a lot recently is Terraform (and remote state) using a Github Actions pipeline. It’s cheap, straight-forward and a great little workflow for creating cloud resources. Today, let me show you why.
So I thought setting up a basic workflow for creating a website would be a great hands-on way to get your head around some different topics: AWS, Terraform and Github Actions. Today we’ll go through how to setup an S3 bucket (which could function as a website) in AWS and use a Github Actions pipeline to create the infrastructure and upload our files.
By the end of this article you’ll know how to configure an AWS S3 bucket using Terraform and deploy it using Github Actions.
At the end of the year it’s now become somewhat of a tradition that I partake in the whole year in summary thing. I do find it interesting to read these posts, and I like doing my own since it’s a good way to reflect.
After a year of how-to type blog posts it feels odd, yet fun to be back talking in first person again. Today we’ll cover quite a lot of (varied) ground in a way I wouldn’t typically be comfortable with. But I’m hoping the informality works out. The following are some of the key things I learned in 2019 that I’ll go into more detail on very soon:
It seems it’s going to be a pretty detailed post so let’s get to it…
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.
