Scheming

May, 2026

New Features

While May was a pretty quiet month in Dorsal, I did manage to sneak in one new feature:

Containerized Applications now run on their assigned Compute

Containerized Applications are the working name for Docker containers that are deployed to Kubernetes with Dorsal, and Compute is Dorsal’s name for Karpenter Node Pool definitions.

It was already, functionally speaking, the case that containerized apps ran on their own compute because the only containerized apps running on Dorsal were Dorsal itself. This meant that there was nowhere else for them to run.

However, as I gear-up for multi-tenancy, it was finally time to add the necessary taints & tolerations to direct the pods to their associated Compute. Now, theoretically, when I make Containerized Application deployments available to Beta users (my personal account), the Beta users’ applications should run on their own EKS Nodes.

Working Backwards

For those who aren’t already aware, one of the key principals guiding Dorsal’s development is that Dorsal is deployed on Dorsal. As such, sometimes I need to work around unfinished functionality.

The Kubernetes resource definitions were one such place. Rather than building out the database tables, populating them, and pulling those values into the Helm Chart(s), I hardcoded some JSON into the codebase to provide the necessary configuration to the Argo CD Applications / Helm Charts. This unblocked the process of iterating on the Kubernetes build-out.

Rather than every change/experiment relying on a database migration, for example, I could simply add something to the Helm Chart, update the Argo CD Application generation to include this value, and pass that value via the hardcoded JSON.

This month, I was unwinding this process. While I had been working backwards, from the EKS Cluster to the database, it was finally time to update the database and have the Kubernetes definitions flow from there.

I’m pleased to report, thanks to work that past Nathan put in to support local development automated testing, this was a relatively smooth process!

The database tables are created and running locally. Once I’ve finished building out the forms in the Console, confirming that the database schema supports the basic functionality that I need, I’ll ship it to Production.

Cleaning Up

One of my first implementations of Dorsal included a plan to leverage AWS Lambda functions. Managing these with Pulumi was a nightmare, and I spent a lot of time getting the gzips building, deploying, and running.

Well, it has been many months (maybe a year?) now since I completely migrated off of these functions, and it was time to accept that this was dead code. I’ve completely deleted every reference to “Functions” from the Console & API.

While there’s a tiny part of me that laments how much time went into code that I’ve now deleted, the vast majority of my being has a very different response: “good riddance.”

When I move from AWS Lambda to a fully Kubernetes-based deployment, I also split the codebase into the “console” and “api.” These separate parts of the codebase have completely distinct concerns, but I had simply copied the package.json file over when I split them.

As a result, there was a lot of unnecessary overlap of unused dependencies between the two. May seemed like as good a time as any to finally reconcile these differences. Given that deleting code is one of my favourite things, this was a very satisfying day for me.

As a final point of cleanup this month, I also removed a bunch of unnecessary conditional rendering logic in the Helm Chart. This was accomplished by migrating nearly all values objects from single objects with an enabled property to a list of values. For example, Values.service became Values.services.

While being much more flexible and forwards-looking, in case I want to support multiples of any Kubernetes objects in a single Helm Chart deploy in the future, it also has the convenient effect of only rendering non-empty resource lists.

Looking Forward

May wasn’t super productive, but I did say last month that having the database schema ready would be enough to consider it a success. So, by my own metrics, I have to consider it a successful month.

If I can stay focused enough in June to finish building-out the Kubernetes forms in the Console, I’ll be maintaining an acceptable pace, balancing real life.

Wish me luck.