I am building a cloud
41 points by tsg
41 points by tsg
The part about the hobbled IOPS of typical hyperscaler VMs is spot on. But don't DigitalOcean and Vultr have local SSD storage by default?
Also, exe.dev, as I understand it, is a step backward from current standard practices in production cloud infrastructure. It makes it easy to spin up mutable Linux VMs, also called pets or snowflake servers. Current standard practice in production infrastructure is all about declarative infrastructure and managing cattle, running mostly ephemeral containers on harden host operating systems, ideally locking down the containers themselves with read-only root filesystems and even leaving out the shell entirely ("distroless" images).
Edit to add: I think fly.io had basically the right idea with their Fly Machines product (not their new Sprites thing, which like exe.dev is riding the AI/agent hype train). Fly Machines do use local SSD storage. But their global anycast front-end proxy is prone to global failures, which is not something you get with AWS-style per-region infrastructure or the mostly self-sufficient VMs of classic DigitalOcean or Vultr. Also, I haven't forgiven fly.io for the mass layoffs of 2024, in which my friend lost his job. More precisely, I haven't forgiven them for the mismanagement that led to premature mass hiring, which then later had to be corrected through mass layoffs. So I would be reluctant to ever use their product again.
a step backward from current standard practices in production cloud infrastructure
you're correct that it is a step back to "pets", but I think this is all under the assumption that pet-like servers are actually enough for most peoples' needs. IMO the "servers as cattle" mentality is part of the reason we see so much complication in modern software deployments, even when "web scale" isn't really a requirement.
It is true that they're banking on widespread LLM-use changing what people want from cloud providers. If you think LLMs are all hype, then everything exe.dev is doing will seem backwards.
Platforms like exe.dev and Sprites from Fly seem to be more targeted towards running agents, providing a sandboxed environments where agents can run without the worry of breaking anything. The goal does not seem to be to run production web apps directly on these instances, they could be used to run agentic workloads initiated from other conventional instances . For production deployments, declarative infrastructure and cattle not pets model does make a lot of sense.
I have been building a project https://github.com/openrundev/openrun, which does declarative deployments with scale to zero on top of Docker or Kubernetes. It is targeted towards deploying internal tools for teams, with features like SAML/OAuth auth with RBAC, not targeted towards agents.
I will follow this one for sure. There are a few more companies with the extremely ambitious goal of "a better AWS", and I am interested in the various strategies they take to approach that goal incrementally.
A service offering VMs for $20 is a long way from AWS, but I see how it makes sense as a first step. AWS also started with EC2, but in a completely different environment with no competition.
I'm not an expert, but I don't really see the difference with Fly.io. Isn't "cloud provider with world class devx" already their thing?
Could somebody explain the point of Shelley Tokens in this context?
Disclosure: I work on Miren, a deployment platform.
Love seeing fresh swings at this space. We've landed on a similar diagnosis (the cloud gave us so much complexity that we forgot what we were trying to do in the first place), and we're having a great time working on a different layer of the problem.
exe.dev is rebuilding the cloud primitives from underneath. Our take has been to stay at the workflow layer, arranging primitives so there's real durability behind the curtain and a smooth experience out front for the day-to-day work of shipping software on the internet. We're focused on small teams, building a substrate runs on pretty much any Linux box, so you can keep it close or put it wherever already makes sense for you.
The more teams taking this seriously, the better. Cheering them on!
I bet he wrote this with chat gpt. He says the clouds aren't the right shape. I actually commanded my AI not to use the word shape. It was so annoying
Doesn't read like an LLM to me.
Providers seem to use "type" for this but I've heard shape colloquialy used in this context. There's a (single) usage in this official page as well https://docs.cloud.google.com/compute/docs/machine-resource
There are plenty of existing cloud providers which align with their stated goals. They're either being disingenuous about the state of things on accident, or are purposefully misrepresenting the situation to justify their plan.
I was a bit surprised by the anti-k8s stuff. I'm sure there are lots of good arguments against k8s, but this one feels like a glaring straw man. K8s was never advertised as an abstraction over cloud APIs; it doesn't even include APIs that are tablestakes for virtually every cloud (relational databases as a service, object storage, VMs, disks, etc).
All k8s does is take 1+ computers and make it/them available in a way that doesn't require operators to think about which specific service a given application instance is running on (and a framework for building more complex abstractions on top of this). If you use it this way, it's fine. If you think it's supposed to provide cloud APIs out of the box, then yeah, you're going to be having a bad time.
They're either being disingenuous about the state of things on accident, or are purposefully misrepresenting the situation to justify their plan.
Oh come on... Do we need to be this cynical? Time will tell, but I for one am enthusiastic about this :)
Their proposition seems to be to buy CPU/memory and split that in any number of VM (like exe.dev), local SSD only with async replica (I don't think this is common), anycast (I don't think this is common without bringing your own IPs).