3 Steps To Migrate Manually Created Infrastructure To Terraform

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.

Terraform logo

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. 

AWS Lambda on Github Actions: How To Send Zipped Artifacts to AWS S3

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.

YAML for pushing artifacts to S3

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. 

5 Important Reasons To Learn Terraform Before Cloud Computing.

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.

Terraform

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. 

Terraform Modules: A Guide To Maintainable Infrastructure As Code

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.

Planning a Terraform resource

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. 

Yarn and the dark future of third party NPM clients

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.