Live data from Hacker News

I am building a cloud

crawshaw.io

581–589 of 589 posts

Re: I am building a cloud

#581
post #190

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.

Well, they don't need to be highly available anymore. They've already cornered their respective markets.

Re: I am building a cloud

#582
post #496

People 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.

We already have the tech for this. It's large! j/k

Re: 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…

Wow, that's very similar to my set up. Their diagram even shows off this staging/production pattern which is nearly identical to my own projects!

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

#585

Potentially 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…

> 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 move that VM to another host if there's a RAM or CPU or other hardware issue on that host.

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…

if your app runs on a single VM, then run it on a VM (two VMs behind LB for extra reliability)

Re: I am building a cloud

#587
post #290

Earlier 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…

Yes I noticed that when designing our ACL usage. I didn’t find it all that useful unless we were inheriting some non tailscale systems with static IPs that we were going to subnet proxy to w/ tailscale.

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

#588

Earlier 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.

I think you're right

Re: I am building a cloud

#589

The 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.

I did a "Show HN" post regarding bhatti here - https://news.ycombinator.com/item?id=47996509
Post reply on HN