Eric Sammer

The kind of thing being posted in Decodable's slack today (this one is from @rmoff.net):

And his epitaph read:

The consensus seems to be SaaS or Fully Managed SaaS. Really appreciate everyone weighing in on this. The internal debate remains lively. 😉

It's not often, but more than you might expect. Varies by role and how hot the market is. Some people just live life dangerously.

This is approximately what we do today, yea. "Traditional" just has this weird connotation of "legacy." It's also not specific or descriptive. "Normal" also makes BYOC sound abnormal which it is increasingly not.

Is it actually dedicated or is it multi-tenant? Ours is the latter.

Some terms people use:
- (Full, Hosted, Managed) SaaS
- Serverless

The confusion is that our BYOC option can also be managed by us. 🤷‍♂️

Poll:

We (Decodable) have a managed stream processing platform. It has a control plane (CP) and data plane (DP). We always run the CP. Customers can choose to let us run the DP or they can run it in their VPC (BYOC).

What do you call the type of account where we run both the CP and DP? Plz repost!

Unsolicited evergreen career advice: show up for interviews or at least send a note if you can't make it.

Ok, fair question! I think it's because of the way it's used. Unmounting and remounting it in a failure case is weird and slow and subject to bad corner cases (local i/o abstraction over a network service). Same issues as NFS, plus or minus.

I was lucky enough to see a very large, very high throughput, very margin-sensitive system, with enterprise SLAs in the cloud that informed my most recent opinions on this. Those include never using EBS. Even there, and to the earlier point, a storage service w/ ephemeral disk backed by s3 = better.

Yes, totally agree.

Yes. This.

I'm not shilling for rocksdb or anything. Flink's state backends and checkpointing system are due for an update. The Flink 2.x work might be The Way (too early to tell). Just suggesting we don't throw the baby out with the bath water on this one.

There are valid questions about how things like rescaling and restoration work, but I think there are good patterns for dealing with this that get into the design of the storage layout and primitives. TLDR, it should be possible to page in/flush chunks rather than everything, but that's obvious.

The current discourse on disaggregated compute and storage in data infra says local disk is bad. I think this lacks nuance. Local persistent disk (e.g. EBS) is bad. Ephemeral local disk should be embraced as a block cache for reads and staging of writes to durable storage. The cost/op is a win.

Half of what I talk to technical founders about is learning and building this stuff for the first time. I wish I had these things two companies ago.

Strongly considering open sourcing a bunch of our key docs and templates at Decodable for technical (would-be) founders: MSA, NDA, operational model, marketing and sales funnel / revenue model. Stuff like that. Is this interesting to anyone but me?

I made an infra engineer starter pack. Folks posting about databases, stream processing, durable execution, orchestrators, service meshes, and more.

go.bsky.app/SCZe42X

Thanks for including me. Great list!

Unfortunately things I'm not yet ready to talk about. Database stuff.

Ok, so have you met my friend `#[async_trait]`?

Of course my first real contribution to tech-bluesky is to complain about the ergonomics of a async programming in Rust. I'm the worst.

I've been writing a ton of Rust lately. I know this isn't a hot take, and I know why it's the way that it is, but async still feels so bolt-on. The way async, closures, generics, and (object-safe) traits work together (or don't) is really painful. It's still good, but it definitely hinders adoption.

I’d be immensely excited to rebuild tech twitter here. Let’s make it happen.

Hello world.