Posts

A common obstacle I encounter when building deployments outside the typical hyperscalers like AWS or Azure is the issue where to store the initial artifacts needed to bootstrap the new deployment. Typical artifacts here are static files, like a Maven repositories, executables for services, Terraform state, Docker images or basically everything else that can be served via HTTP. While for many uses-cases serving static data via S3 buckets is the best way to go, doing so in AWS may not always be the best option due to complicated account setup, or costly egress traffic when the data is accessed from the internet. [Read More]

As laid out in my previous post “out of cloud” migrating applications from the big-hyperscalers to smaller (and cheaper) alternatives sometimes comes with the challenge to figure out alternatives for features that may be missing in the target environment you are moving the application to. In the past I have done a lot of AWS/GCP/Azure to Hetzner cloud migrations, and one particular feature I was missing, especially for plain-VM deployments are the AWS Auto Scaling groups that automatically mange VMs attached to load balancers and are capable of conducting rolling deployment updates of those severs. [Read More]

If you are using Terraform (or Tofu nowadays) you might already have run into the chicken-and-egg issue that comes with the infrastructure state storage. To store the state you need to have some kind of container for that state to live in, assuming you don’t want to store it locally which comes with its own set of issues. And also because you always do infrastructure as code by the book (:-)), this container should automatically be provisioned so the process is properly automated and fully reproducible. [Read More]

This post will detail and summarize the key architectural considerations and findings based on the experience of moving several environments from one of the usual hyperscaler-suspects like AWS/Azure/GCP to a self-managed, but still cloud hosted solution based on the Hetzner Cloud. The goal is to show the different considerations before attempting such an approach, as well as an exemplary target architecture.

[Read More]

If you are ready for another instance of me rambling about developer experience, this post will detail a Gradle pattern to ensure that secrets for Java or Kotlin integration tests are readily available locally and in CI, without the need to manually set up the development environment.

[Read More]

When selecting a tech stack for my personal backup needs, I aim for the most boring but still supported software that is available. When it comes to data safety and resilience against disk failures and other disasters, the last thing I want is to discover that the shiny new feature that was just introduced in my backup solution ate all my data and saved 0s all the time.

I have been a heavy user of borgbackup for nearly a decade now, where it flawlessly worked in the background without any fuzz. The only downside for new users adopting borgbackup, can be the rather complicated setup of a remote backup repository which is a little finicky to say the least, this is an example for the Hetzner storage box solution

Luckily with the new 2.x version, rclone was added as a new repository backend, adding a lot of new options where backup repositories can be stored.

In particular S3 is now also an option for remote storage, which together with the new object storage offering from Hetzner, offers a nice and cheap option to store your backups without using the usual suspects like AWS or Cloudflare.

This post outlines the steps you need to do to test-drive this new feature while also giving a rough overview of the general borgbackup usage.

[Read More]

Just in time for the public holiday in Germany, the Solidblocks infrastructure components collection got another addition. solidblocks-dns is a Kotlin library that lets you interact with the Hetzner DNS API to easily manage DNS zones and records.

[Read More]

One of the main benefits of using infrastructure-as-code is the reproducibility of your environments. No matter what happens, you can wipe everything away and rebuild from scratch. Like with many things, practice is required to ensure that the bootstrap capability is not lost over time. Typically, you will want to regularly wipe and rebuild your test (or development) environment to prevent cyclic dependencies from creeping in, ensuring that your bootstrapping code still functions as intended. [Read More]

As time goes by and a project grows, ideas and concepts that initially seemed like good and pragmatic solutions can sometimes deteriorate into a convoluted mess. Recently, implementing a small feature in the Solidblocks infrastructure suite went from a pleasant Friday afternoon coding session to an integration testing nightmare, caused by an overabundance of infrastructure testing approaches.

This post will highlight the different approaches and offer a streamlined solution that will work indefinitely (until it doesn’t :-)).

[Read More]

Providing test utility classes or test fixtures for other projects in Gradle environments can be an annoying and cumbersome endeavor. Often the solutions involve the creation of extra projects to provide the needed testing functionality for other modules or projects, or include manipulation of Gradle source sets and configurations. This post shows how to achieve this using functionality that is already included in Gradle and Junit.

[Read More]