Blog - My thoughts and ideas
According to Phil Karlton there are only two hard things in computer science: Cache invalidation and naming things. I have experienced on multiple occasions how important the latter one is: Finding the right name for something and (perhaps evenly important) sticking to that name.
In another article I described how to set up a VPN using WireGuard on a dedicated EC2 instance at AWS.
If you happen to run a Kubernetes cluster then the configuration becomes even simpler, as we don’t have to set up a dedicated EC2 instance but can build upon the infrastructure provided by Kubernetes.
As someone who has experienced both sides (being a manager as well having been managed myself) I see some behaviors popping up again and again that I very much oppose and clearly identify as actively hurting the productivity of any team.
During my career I was very fortunate in that almost all of my managers were people that I enjoyed working with and more than once looked up to.
But all good things eventually come to an end and not that long ago I encountered the exact opposite of what I consider a good manager.
Most of our resources at AWS aren’t publicly accessible via the Internet.
Instead we placed them in a separate VPC to isolate them from any malicious access by an attacker or even accidental access by ourselves.
However from time to time we do want to access the resources directly:
- During local development it may save us an enormous amount of time not having to build complex tunneling solutions within our application.
- Certain systems should never be exposed via the public Internet but should only be reachable for dedicated and authenticated users.
My first approach was to use AWS’s internal VPN solution which turned out to be both complex to setup as well as pretty expensive to use.
So while looking for alternatives my colleague Lukas pointed me towards WireGuard which turned out to be exactly what I was looking for.
In this posting I will describe how to setup a WireGuard VPN at AWS completely from scratch, using Terraform as infrastructure as code framework.
The time of binders full of invoices and other documents is over.
At least for me.
Almost all of my personal home office is paperless these days. However almost everything still arrives on paper.
This article tells you how I deal with it.
To separate our services and the data our service operates on we use separate GitHub repositories as storage.
This article will demonstrate how we make sure that our operational services always have the latest data available.
Every once in a while I publish stuff.
This one is for my German speaking and reading audience.
My article about “How to be a happy developer” has been published in the February 2020 edition of the German magazine “Java Aktuell” by the iJUG (Interessenverbund der Java User Groups e.V.).
The German title is: “Als Entwickler glücklich sein – Tipps und Tricks”.
This article shows how to optimize a Docker image for a Ruby on Rails application both in terms of making the image as small as possible as well as how to improve the time it takes to create the image.
We’re in the middle of migrating a lot of our infrastructure components to AWS.
One thing that took me a while to wrap my head around is how to setup a VPC (Virtual Private Cloud) at AWS in a way that all our outgoing traffic is routed via a fixed IP address.
In this article I will demonstrate how this can be done, using Terraform to setup all required resources at AWS.
As we create more and more new service and require more and more infrastructure resources to support those services, we have started to use Terraform to manage our infrastructure.
In this article, I would like to give an overview of how we structure our Terraform setup.
It’s designed to build up a common vocabulary and understanding of why we do things the way we do them and provide a little bit of background information how and why we made the decisions that lead to the current setup.
As we’re using AWS to deploy our cloud infrastructure, most of the examples will relate to AWS but in principle should be provider-agnostic and can apply to other providers as well.