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.
A few days ago I stumbled upon a discussion on Twitter of whether or not a local development environment should be kept identical to the production environment:
A decade ago, we had a simple rule: Keep your dev environment identical to production environment.
The original assumption in the tweet is by itself interesting: Did we actually have that rule? Keep the development environment identical to the production environment? Did it ever work?
From my personal close to 20 year experience in software engineering I never had the situation where a development environment actually mirrored the production environment.
And I would even go as far as to say: That’s a good thing!
In May I had the honor of having been invited as opening keynote speaker to the DevDays 2019 in Vilnius.
Luckily I also had the chance to see a lot of other great talks that made me curious about new technologies, showed me things I hadn’t thought about before and made me appreciate a few things I always took for granted.
In this post I would like to highlight a few of my favorites: