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.
Terraform is a fundamental tool for Cloud Native software engineers to learn. In my opinion Terraform should (and will) be as ubiquitous for infrastructure provisioning as tools like git are for version control.
Today we’re going to talk about the 6 key fundamentals topics you need to know in order to get working with Terraform quickly. We won’t be covering the concepts in great depth (a good thing!) but we’ll just enough so that you’re aware of what the concept is and how it works before you go diving deep.
By the end of this article you’ll be aware of the 6 key concepts of Terraform. Everything from the language structure to file format.
I spend a lot of time researching Cloud Native technologies. Also whilst editing the Cloud Native Software Engineering Newsletter I’m always looking for the best sources of knowledege and high quality content. Everything on the list is things I read, people I follow or books I’ve read. I’m not recommending anything I haven’t used.
By the end of this article you’ll know about the best Cloud Native resources that I’ve found to-date. Make sure to come back as I’ll be constantly updating this page!
Have you ever been into the AWS console and been completely baffled about all the concepts and jargon? You’ve got: Security Groups, Inbound rules, VPC’s, Subnets, Internet Gateways, NAT, ENI’s and all of them are related to networking somehow. Put simply: there’s a lot to AWS networking. So if you’re going to break into it somehow you need to know what to focus on: the fundamentals.
Today we’re going to be going through the main networking components you should be familiar with in AWS. We’ll talk you through why you’d need the component, what it is and how you’d use it. Throughout the article we’ll be building up an example of running a web server in a public subnet as part of our own VPC.
By the end of this article you’ll understand the main networking concepts: Private IP’s, Virtual Private Cloud (VPC), Classless Inter Domain Routing (CIDR), Subnets, Internet Gateways and Security Groups and use these to implement a basic network design.