@kfitz S3 is the main thing I'd currently like to switch.
I'm not super aware of the other parts of it because I avoid it as I don't want the lock-in. (Though I have used a few bits on client projects where they've wanted it)
The Lambda stuff feels like it could enable a bunch of interesting use cases for community-scale tech to have cloud glue code to orchestrate other off-the-shelf parts. That's getting beyond your thought experiment though, I fear 😀
@kfitz I mean it's the only thing I'm currently paying AWS for, and would love to have a broadly-similarly-priced co-operative alternative to switch to 😀
I'm not hung up on the protocol per-se, it's the cost-effective binary blob (images and audio mostly) hosting that's the real feature; however there's lots of S3-compatible tooling already lying around that's easy to integrate.
@williampietri @kfitz Oh and you'll need to provide object storage, of course.
A PaaS is also not great for heavy ETL/machine-learning due to limited local disk.
My feeling after looking at the Supabase stack a lot lately is that "just use postgres" is a boring but also winning architecture strategy for most of what people want to make, but as the service provider you might not get much say over what they are working with.
@williampietri @kfitz So, depending on who you want to serve, I'd probably just start with hardware and OpenStack (IaaS), then work up to OpenShift+Korifi or BOSH+Cloud Foundry (PaaS).
After that, listen to what people want and start providing those as brokered services that they don't have to operate themselves. I'm not crazy about k8s, but if you start with OpenShift you're in a good position both to provide a k8s service, and to use it yourself to operate specialized brokered services.
@williampietri @kfitz It helps to give them guidance/therapy, though, in the edge cases where change is more possible than it first appears. Example: I was sure we wouldn't be able to run Hypothes.is because it uses RabbitMQ but it turned out that it uses RMQ via a library abstraction that can just as easily use Redis/Valkey with a one-line config change.
So: Invest early in pre-sales engineering.
@kfitz I genuinely don’t think centralised services are the right solution in most cases, and that they all but guarantee walled gardens, vendor lock in (by solution providers), and all sorts of really harmful effects for users.
So if i had those resources and expertise, I would put them in to developing technology for local first and decentralised approaches.
Any of that can then be run on remote servers as well, but that should be a generic commodity facility, without vendor provided magic.