One of my PostgreSQL tables recently just hit 50 million rows. For cost reduction and because this is just a pet project, I run all my databases in AWS ECS with persistent storage in EFS. While this does mean a only couple dollars for computing and a few dollars for storage per day, this also means I get none of the benefits of an actual AWS RDS instance. No backups or anything.
Automating backups of databases in ECS containers with EFS persistent storage
March 29, 2025
How to wait for a .NET test based on environment requirements
February 18, 2025
This is a follow-up to my previous post where Testcontainers was not freeing up ports in build pipelines.
I am using .NET PostgreSQL Testcontainers to ensure my application runs end-to-end. My integration tests would always run fine on my local machine but occasionally in the GitHub runners environment, I would see a Connection refused
error ("It worked on my computer!").
My guess is the container did not finish the PostgreSQL start up processes by the time the tests started.
Running MongoDB in AWS ECS with persistent EFS storage
February 4, 2025
I recently deployed an app to AWS ECS and since it is in its early stages, I wanted to pay as little for storage as possible. So instead of a dedicated MongoDB instance, I spun it up as a service in my ECS cluster.
I also opted for Fargate Spot Instances since I could live with a container restarting once every day or so. But this meant I had to make sure I had persistent storage so that I wouldn’t lose data if the MongoDB containers cycled.
Decorating containerized .NET apps with build info
January 30, 2025
When deploying containerized applications to cloud environments it is important to be able to know which version you are running. In the past, sometimes it was hard to know if container orchestration systems like kubernetes had picked up your new Docker images. In our production environments, we would specifically reference our deployment tags (eg, some-registry/some-project:1.2
). But for dev environments, we would simply overwrite a dev
tag similar to a latest
tag so that we wouldn’t pollute our registry.
Ocelot Dynamic Routes Runtime Configuration
November 24, 2024
My experience with Ocelot as an entry point to an app was mostly good. I like that it is cloud-agnostic – it’s good to go on Azure, AWS, or whatever.
The biggest issue I had was with route configuration. You are stuck writing a static config file (separate from appsettings.json
) or creating an overkill provider.
In my dev environment, I used Ocelot’s config file and my routes all pointed to localhost
. But when deploying to the cloud, did I really want to create another config file (ocelot.production.json
) just for a different hostname or port? My solution was to dynamically build the routes at runtime using injected ENV
variables.