Project intro: Going Cloud Native for internal services


Introduction

I run some internal (web-)services for our household. Boring stuff: pihole, mail, calendar, temperature server, shared drives, AirPlay for YAS-207, various IoT endpoints, etc.

I decided I would like to go with the flow, and go Cloud Native, to experience the full richness of this newfangled flavor.

Because working for many years for a big corp that runs this water-aerosol-y stack likely rubbed off on me. I long for the seamless auto-discovery of new backends, easy load balancing and scaling, etc1. And the running of stuff as vanilla processes (most of them chroot-ed) seems backwards. And the new way of doing stuff likely had plenty of time to mature and be just as good, or better.

In other words, I’m planning going from this:

status quo

to this:

expected endstate

Plan

With my liking of Alpine Linux well established I suspect it’ll go down like this:

  1. Getting containers to run on my Alpine setup (a.k.a. vanilla alpine with full disk encryption on ZFS)
  2. Choosing and configuring http reverse proxy
  3. Deploying first few web apps

I’ll link the posts below as they become available, all tagged with hawa2.

Execution

Stay tuned, one more to come.

  1. And also for the nightmares of exploding microservice mesh stack, sampled distributed tracing, the ever-present “Why is it slow?” question of distributed systems. Maybe I’m just a glutton for punishment.

  2. After “High Altitude Water Aerosols”. Because calling it Cloud Native would be equally stupid.