Daemonic Dispatches

My re:Invent asks

As an AWS Hero I get free admission to the AWS re:Invent conference; while it's rare that I'm interested in many talks — in previous years I've attended "Advanced" talks which didn't say anything which wasn't already in the published documentation — I do find that it provides a very good opportunity to talk to Amazonians.

While I'm sure many of the things I ask for get filed under "Colin is weird", I know sometimes Amazon does pay attention — at least, once I find the right person to talk to. Since I have quite a list this year, and I know some Amazonians (and maybe even non-Amazonians) may be interested, I figured I might as well post them here.

1. More Amazonian OSS developers at re:Invent. I'm looking forward to meeting some Valkey developers on Wednesday, but I was disappointed that none of the Firecracker developers are in attendance. Amazon has a policy of not having engineers attend re:Invent unless they're giving talks (and I'd love to see this policy changed in general) but it's absolutely essential for Open Source developers to go to conferences; that's how we meet potential contributors. If your open source team doesn't go to conferences, they're not really doing open source, no matter what license you put on the code.
2. Lower cross-AZ bandwidth pricing. I don't even particularly care about the cost; but being worried about avoiding cross-AZ bandwidth is making people design bad systems. One of the guidelines in Amazon's "well-architected framework" is to deploy the workload to multiple locations and Amazon specificially calls out using a single Availability Zone as a problem — but concerns about cross-AZ bandwidth (even if it turns out that the concerns are unwarranted!) are preventing people from following this guideline.
3. On-the-rack EBS storage. I don't know how Amazon datacenters are set up, but the latency of disk I/O to "SSD" EBS volumes strongly suggests that they are a significant distance away from EC2 instances which are accessing them. At the other end of the latency scale, some EC2 instance types have SSDs directly attached to the instance hardware, with dramatically better I/O performance — but have low durability (if the instance dies the data is gone) and no elasticity (each instance type has a certain amount of disk attached).
   Having EBS storage available on the same racks as EC2 nodes would provide an intermediate point, allowing lower latency than the speed of light allows for across-the-datacenter I/Os, while allowing some flexibility in the size of volumes. Users would have to accept that "provision me a volume on the same rack as this instance" might return "sorry all the disks on that rack are full"; but at least at instance launch time requests could be satisfied by searching for a rack with sufficient rack-local disk.
4. CHERI capable instances. This has been a long standing wishlist item for me and I know I'm not going to get it any time soon; but I know Amazon (and other clouds) have Morello boards for research purposes. CHERI has huge advantages for security and whichever cloud pursues this first will be miles ahead of the competition.
5. Marketplace support for "pending" or "scheduled" releases. When I add new FreeBSD releases to the AWS Marketplace, they first go through an approval process and then get copied out to all the EC2 regions; once that is done, the Marketplace updates the "product" listing with the new version and sends out emails to all the current users telling them about the new version. This often means that Amazon is sending emails announcing new FreeBSD releases a couple days before I send out the official FreeBSD release announcement.
   I don't want to wait and add new versions to the Marketplace later, because the timeline is unpredictable — usually a couple hours but sometimes a day or more — so I'd like to be able to tell the Marketplace about the upcoming FreeBSD release and have them get everything ready but not update the website or send out email until I'm ready to send out our announcement (we usually allow a few days for mirrors and clouds to sync).

In addition to these, I also had a couple requests which I can't write about due to the nature of what I was asking for. I did however have one more request I can write about — not for AWS, but for a re:Invent sponsor. I ran into some people from Zoom and mentioned that every time I join a call from my (FreeBSD) laptop, the Zoom website tries to get me to open a Zoom client, and only offers "open the meeting in your web browser" after failing repeatedly. Since my web browser's user-agent string includes "FreeBSD", they should be able to detect that there is no Zoom client and go straight to opening the meeting in my web browser. To their credit, they immediately understood what I was complaining about, and even offered to look into whether they could port their Linux client to FreeBSD.

I don't know if or when I'm likely to get any of these, but I like to think that I convinced people that what I was asking for was at least somewhat sensible. Maybe between them and other Amazonians who will no doubt read this, I'll get at least a few of the things on my wishlist.

For the sake of transparency: In addition to giving me (and other AWS Heroes) free admission and travel to re:Invent, Amazon is sponsoring my FreeBSD work. About half of what they're paying for is EC2-specific stuff; the other half is FreeBSD release engineering. Without their support, a number of important features would not have landed in FreeBSD 14.2-RELEASE; thank you Amazon.

blog comments powered by Disqus