I’m an AWS solutions architect with over 14 years of experience building highly scalable, high performance infrastructure. My passion is scaling out infrastructure from 0 to millions of users while adhering to industry best-practices in a cost-effective manner.
You can follow me on Mastodon. 🐘
Anyone who uses Terraform must be familiar with the import command; it allows you to gather existing resources and put them into your statefile. This way, existing resources which were previously not created using Terraform are now under management of your infrastructure as code.
You can import your resources in the terminal, but you still have to write the code for the resources you import. With Terraform version 1.5 there’s a better solution: import blocks.
In the realm of Amazon Web Services there’s this thing called a Landing Zone, a set of infrastructure as code modules built to deploy new environments faster. You can build a Landing Zone using CloudFormation, CDK, Terraform, or any other tool you like. The point is that you have a starting point for as many use-cases as possible. For a Landing Zone to work you have to write reusable generalized code that could work for any client and any combination of infrastructure.
While trying to create a Landing Zone in Terraform I found that it’s very hard to make them follow the DRY principle (Don’t Repeat Yourself). After a while the code started to be really hard to maintain. But then I found Dynamic blocks.
For years and years I’ve been using Jekyll as my static site generator of choice, mostly because I like their templating engine and I’m a fan of Ruby as a programming language. I’ve been experimenting with Hugo as well, but it never really clicked for me. Well, until I found the perfect theme for my needs. The same theme is now used here and on the toot.community blog so I wanted to set mine apart a little bit by adding banner images on some posts. Downloading an image from Unsplash and manually resizing it wasn’t an option though - I need things to be frictionless when I want to add a blog entry.
If you’re serious about scaling your company you should stop doing DevOps teams. I realise this is probably a controversial opinion and one I’m most likely almost alone in thinking, but it’s something I’ve been thinking about a lot as of late.
Tomorrow marks the first full month of my move to toot.community, a Mastodon instance initially set up by my friend Jorijn. My move to Mastodon wasn’t motivated by what’s going at Twitter right now, but rather the technical challenges of scaling the shit out of it. In the first week we welcomed thousands of people and we certainly had to put out a fire or two, but most of the time we had the time to focus on optimization.
I’ve been a Vim user for as long as I can remember, but in the last few years VS Code kind of took over as the defacto choice for us DevOps engineers. VS Code is great at offering all kinds of plugins that should, in theory, make life a little easier. It’s funny actually, because plugins are the sole reason I never quite got into using Vim fulltime. To me, plugins in Vim just added to the complexity of remembering all of the keyboard shortcuts and quite frankly, the many ways of installing a plugin didn’t help me make sense of things either.
But then Vim 8 was released.
The end of the year or your own birthday are both for reflection on the days and months that came before. We try to look back on all the things that went right and the things that maybe could’ve been better. The highs and the lows, the moments where we experienced stress, where we felt love. We try to make new resolutions for the year ahead. But sometimes we fail to notice trends as the years go by quicker and quicker.
One of the most well-known patterns in infrastructure is having an internal load balancer in front of backend services like application servers. When you’re migrating your workloads to say AWS Fargate it’s easy to just carry over that same pattern because, well, it works. But, as with all things in the cloud, internal load balancers cost money and add complexity. When you’re just migrating to using containers for the first time, adding complexity to an already steep learning curve might not be the best way to go about things.
To be clear right off the bat: I don’t do well in busy offices. I get distracted easily, I don’t like it when people can see what I’m doing, I don’t like people talking and radio’s blaring. The open office plan truly is the bane of my existence. Therefore, noise cancelling headphones are a Godsend.
I’ve owned just about every popular pair of noise cancelling headphones out there. That doesn’t mean I’m an expert or anything, it just means I know what I like and don’t like.
I’ve been an avid user of various Linux distributions for 22+ years now and I will forever love everything about it and what it brought me. I have my entire carreer built on Linux and open source software. I’ve also known about BSD for about as long, but I never quite got into it, until now. I’m as much a minimalist as I am a nerd and I love simple software that does one thing well. I want all of my software to Just Work, no hassle or needless features added. After coming across OpenBSD.ams I decided to read up on OpenBSD and its goals.