Earlier quoted context omitted.
Cloud providers have put a lot of time and effort into making you believe every web app needs 99.9999% availability. Making you pay for auto scaled compute, load balancers, shared storage, HA databases, etc, etc. All of this just adds so much extra complexity. If I'm running Amazon.com then sure, but your average app is just fine on a single VM.
And funnily recently many of the Big Serious Cloud Websites are shitting the bed of availability aggressively.
I am building a cloud
581–589 of 589 posts
Re: I am building a cloud
#582People who don't understand the software bloat cycle are doomed to repeat it. Lean software -> missing features users want -> add features over time -> bloated mess -> we need a smaller rewrite -> Lean software -> ...
True. The solution is to make a different piece of software customised for each person.
Re: I am building a cloud
#583Re: I am building a cloud
#584> Making Kubernetes good is inherently impossible, a project in putting (admittedly high quality) lipstick on a pig. So well put, my good sir, this describes exactly my feelings with k8s. It always starts off all good with just managing a couple of containers to run your web app. Then before you know it, the devops folks have decided that they need to put a gazillion other services and an entire software-defined netw…
A single VM is indeed the most pragmatic setup that most apps really need. However I still prefer to have at least two for little redundancy and peace of mind. It’s just less stressful to do any upgrades or changes knowing there is another replica in case of a failure. And I’m building and happily using Uncloud ( https://github.com/psviderski/uncloud ) for this (inspired by Kamal). It makes multi-machine setups as si…
I use ansible to set up my hosts, and from there each app just brings it's own caddy & compose file. A bit of scripting and SOPS wraps the lint / build / deploy steps. Compared to my past life which was all k8s infra projects in helm... it is SO NICE to use these lightweight files instead.
Re: I am building a cloud
#585Potentially useful context: OP is one of the cofounders of Tailscale. > Traditional Cloud 1.0 companies sell you a VM with a default of 3000 IOPS, while your laptop has 500k. Getting the defaults right (and the cost of those defaults right) requires careful thinking through the stack. I wish them a lot of luck! I admire the vision and am definitely a target customer, I'm just afraid this goes the way things always go…
I've run an Openstack cloud. Local to the host NVME's directly attached to VMs is unbeatable. All clouds offer this. But that storage is ephemeral and it was when I implemented it in Openstack too. There's not enough redundancy. You could raid1 those NVME's when before they get attached to a VM and that helps with hardware failures, but you get less of them to attach. Even if you RAID them, there's not a good way to…
The trick is building a block storage system that treats the local disk as write-back cache with async replication to networked storage. Like the blog post says they'll be doing.
The async replication has some integrity/recovery concerns for sure, but it the trick that enables local speeds. And people have been happy with async replication for their database for a very long time. Just need good observability for the durability delay.
Once you have that, you can do live VM migration if you're careful enough about dirty data. The new node just starts out with an empty cache.
It's not exactly trivial, but it's also probably not the biggest challenge if you're genuinely building a brand new cloud and going to compete against the hyperscalers. (Hell, hire me and I can write it for you. It'll take time and CPU hours to get stable, but the magic required is only mildly arcane.)
For example: https://dl.acm.org/doi/10.1145/3492321.3524271
Re: I am building a cloud
#586> Making Kubernetes good is inherently impossible, a project in putting (admittedly high quality) lipstick on a pig. So well put, my good sir, this describes exactly my feelings with k8s. It always starts off all good with just managing a couple of containers to run your web app. Then before you know it, the devops folks have decided that they need to put a gazillion other services and an entire software-defined netw…
Re: I am building a cloud
#587Earlier quoted context omitted.
You can ack based on groups, and you can out users into groups. So if you auth a node, it’s now your node and the ACL for your user / group will apply. But yes I don’t think you can ACL based o the hostname
Hi there, I work at Tailscale. Part of the reason that we don't (currently) let you do this is that a hostname is a user-reported field, and can change over time; it's not a durable form of identity that you can write ACLs on. One could imagine, for example: 1. Creating an ACL rule that allows hostname "webserver" to hostname "db". 2. (time passes) 3. Hostname "webserver" is deleted/changed to "web"/etc. 4. Someone c…
Tags are just a better way to do this for tailscale only nodes, as now the ACL doesn’t require any change during a device key rotation.
Re: I am building a cloud
#588Earlier quoted context omitted.
It's not just low level, in most cases, it's also overkill. Most companies aren't "web scale" ™ and don't need an orchestrator built for google level elasticity, they need a vm autoscaling group if anything. Most apps don't need such granular control over fs access, network policies, root access, etc, they need `ufw allow 80 && ufw enable` Most apps don't need a 15 stage, docker layer caching optimized, archive promo…
I'm afraid the bloat is too lucrative for everyone involved.
Re: I am building a cloud
#589The point about VMs being the wrong shape because they’re tied to CPU/memory resonates hard. The abstraction forces you to pay for time, not work. I ended up buying a cheap auctioned Hetzner server and using my self-hostable Firecracker orchestrator on top of it ( https://github.com/sahil-shubham/bhatti , https://bhatti.sh ) specifically because I wanted the thing he’s describing — buy some hardware, carve it into as…
This looks interesting at first blush. My only feedback so far is that a lot of the documentation, though thorough and useful, looks clearly AI-written. That's not bad in and of itself, but it could be more concise. I especially love the "design decisions" section as I learned something new already. Have you posted it on "Show HN" already? If not, you should.