I joined Google in October 2022, so I’ve been here about a year and a half now. Looking back, what were my expectations coming into the job? The Initial Offer and Team Matching Let me rewind a bit. I signed the offer surprisingly early, back in March 2022. This was even before team matching, so I had no idea which team I’d end up on. Fortunately, the team matching process worked out well in the end. The first potential match was with an Android team. My recruiter reached out to ask if I was interested, and I was quick to say no. I’m not really into Android development, and mobile development isn’t my primary interest. While I enjoy dabbling with mobile projects sometimes, I didn’t want it to be my full-time focus. ...

It’s time for the yearly “Tech Infra at home” update. Feel free to take a look at the last posts from 2022 and 2020 on that topic. This one is reasonably short, let’s start with having a look at the device diagram: There are a number of important changes present: First and foremost, I got rid of the EdgeRouter-X. Ubiquiti stopped updating it and it couldn’t handle 700 Mbps routing anyway. Now I’m back to using the ISP-provided modem box. It works reasonably well, at least it can handle my upstream/downstream speeds. My building uses G.fast to provide Gigabit access through old phones lines up until the signal reaches the ONT in the cellar. I was quite sceptical of the technology initially, but so far I’m really quite happy with the connectivity and reliability of the uplink. ...

First, a bit of context: I run a side-project called Valar, which is kind of a cluster-scale systemd-socket-activation container engine. I’m currently focusing on performance improvements and one of my targets was the proxy component. It terminates TLS connections and hands the HTTP requests off to the respective handler. As I did some load testing, I ran into the fact that my proxy spend about 70% of its CPU time multiplying some big.Int for the TLS handshake, which seemed kind of excessive. I published a little demo repository where you can try it yourself. ...

This is an update on a previous post on the technical infrastructure I run at home. This post will be similarly structured to its predecessor. I will start with giving a detailed description of the base network, continue with my storage setup and finish with compute. Tier I: Physical layout & network Router: Two years after my initial post I’m still happily using my EdgeRouter-X. It works fine for my needs, although I’m probably gonna switch to a self-built router at some point due to upgrading to 10G/25G Ethernet. Running 10G at home was quite pricey just a couple years ago, but these days you can find older 10GBit cards like the Mellanox ConnectX-3 cards for less than 50€. ...

Today I wondered what makes a good computing infrastructure setup? Of course, the context matters here. Does one measure good infrastructure in terms of “enterprise-grade” or prefer just a well working home setup? Or can one actually transfer ideas from enterprises to its smaller scale sister? Just to clarify: I will focus on the environment at home, since these kind of fast-moving thought experiments don’t go well with enterprises. What does one require? I had to think about what kind of requirements do I have? Which kind of infrastructure do I use at home? ...

A small disclaimer at the beginning: while I have some background in Java, I would never consider myself a superb Java developer. In the recent years I mainly opted for Go to get stuff done, maybe missing out on some of the more interesting programming language trends. This is the main reason I decided to learn Kotlin: dipping around in new concepts. I chose Kotlin because of the recent 2019 Stack Overflow survey. By developers Kotlin is ranked at the 4th rank of most loved programming languages. Since I know Python (mainly for ML use), have learned a bit of Rust (but I found it way to verbose) and written quite a bit of TypeScript in combination with Vue.js web framework; I decided to investigate why exactly Kotlin is so popular. ...

In my last blog post I talked about setting up your own Kubernetes cluster at home. Since we don’t run our cluster on a big cloud platform, we have no access to comfortable tools like a built-in load balancer. Time to go ashore But, don’t despair! We can deploy our own load balancer using the Kubernetes Ingress object. It allows us to define routing rules and use a backend of our choice that uses these rules to route traffic to our cluster. And the most exiting thing: to build an Ingress controller is really simple. ...

You may find yourself sitting at home, thinking about software and stuff and what to do with that spare PC of yours. I’ve got an idea: set up a single-node run-at-home Kubernetes cluster! We need a ship (or a whale) A little disclaimer to start with: the configuration here provides no recovery mechanisms since it is based on a single master node. If you want to set up a high availability cluster, I recommend you consult the excellent Kubernetes documentation. ...

In this post I will explain how to build a nice and working RESTful API for our weather service using only the Go standard library. If you missed the first part of this series, I recommend reading it before continuing here. You can find the codebase of this introductory series on GitHub. Extending the blueprint Well, we have a nice blueprint of the handlers we want, but shoving around global variables is neither fun nor good style. So we will extend each of our handlers to use Go’s support of higher-order functions, that allows us to use functions as values. We will do this for each of our handlers. Our final result should look something like this. Notice the changes in the main method when registering the handlers. ...