2024.03 Release Notes Notes

Substrate 2024.03 turned out to be a much bigger release than I’d intended or anticipated, at least as measured by the length of the release notes. It’s still a quieter release than the last couple, focused mostly on closing the book on the big architectural and philosophical changes from the past few months. The new command structure is stable, there are no more generated Terraform resources (only Terraform configuration), and all the transitional micromanagement of Terraform state has been removed. Feels good.

AWS public IPv4 price increase

AWS’ pricing change on public IPv4 addresses is now live. This change impacts Substrate in two ways. The Instance Factory offers a convenient way to access AWS via an EC2 instance that’s on your network; those instances have public IP addresses and now cost about $3.60 more per month, if they run that long. Then there are NAT Gateways, which Substrate will happily manage for you to the tune of at least $108 per month, up from about $98 thanks to the new charge on in-use Elastic IP addresses.

It seemed only right to warn customers about this change, which got me to thinking about how regressive this new pricing can be.

Consider a large-scale AWS infrastructure spending millions of dollars per month. It might plausibly have as few as six public IP addresses. (That’s three for an NLB and three for NAT Gateways to serve inbound and outbound Internet traffic in three availability zones of a single region.) These public IPv4 addresses will cost them about $21 out of those millions.

Now consider a hobby project small enough to run on a single t4g.nano, still the smallest, cheapest EC2 instance on offer at $0.0042 per hour (on-demand). A public IPv4 address, at $0.005 per hour, more than doubles the cost of that project.

I get it. Public IPv4 address space is scarce. I don’t begrudge AWS charging for it. I just wish the side-effect wasn’t making the weird and wonderful that little bit harder to put out into the world.

Perhaps the Internet is about to get weird again over IPv6.

Apropos of nothing

█ $ dig +short A github.com
192.30.255.113
█ $ dig +short AAAA github.com
█ $

Things CI products should be able to do

When Substrate 2024.01 integrated with the macOS keychain, I had to start doing macOS builds on macOS (ARM on ARM and Intel on Intel). It was almost enough to make me build a homelab. Thankfully, GitHub Actions swooped in with ARM macOS runners at just the right moment.

Getting Substrate to build there was the easy part, which I did at the very last minute with zero stress and only a couple of bugs. There’s honestly nothing much to report there. GitHub Actions does what it says on the tin.

RNN 2024.01 pointed out that, in the context of writing command-line tools, actually running different code given different arguments is easy. The hard parts there are tab completion and contextual help. CI systems seem cursed to suffer from the same misunderstanding of what the hard part actually is.

Both AWS CodeBuild and GitHub Actions make it extraordinarily difficult to send a message to Slack when a project/workflow/job/whatever fails and a different message to Slack when one succeeds. In case of failure, I might want to include the trailing kilobyte of standard output/error or a specific log file. In case of success, I might want to include URLs for the installable artifacts. In all cases, I probably want to link to the full diagnostics for this project/workflow/job/whatever.

Running commands is the easy part. Observation is the killer app.