Live data from Hacker News

I am building a cloud

crawshaw.io

481–490 of 589 posts

Re: I am building a cloud

#481

Earlier quoted context omitted.

>3000 IOPS If that's true, I wonder if this is a deliberate decision by cloud providers to push users towards microservice architectures with proprietary cloud storage like S3, so you can't do on-machine dbs even for simple servers.

It's probably a combination of high density storage nodes getting I/O bound and SSDs having finite write endurance. Anything that improves the first problem costs them money to improve it and then makes the second problem worse, and the second one costs them money again, so why would they want to make the default something that costs then more twice if most people don't need it? Instead they make the default "meager…

I'm not sure about this but I remember that a lot of servers at my old company stuck with hard disks as late as 2018 - exactly for the same reason - HDDs for all their faults dont have write endurance issues. This was quite surprising to me back then.

Re: I am building a cloud

#482

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

I always looked into k8s and then realized it solves YouTube-scale problems, which I don’t have.

Re: I am building a cloud

#483
post #461

Comparing laptop SSD to cloud network drive is misleading. EC2 provides the *d VMs that have SSDs with high IOPS at much lower cost than network SSDs. They are ephemeral, but so is laptop and its SSD - it can loose the data. From AWS docs "If you stop, hibernate, or terminate an instance, data on instance store volumes is lost.".

If I stop, hibernate or power off the laptop, the data is most definitely not lost.

Re: I am building a cloud

#484

Earlier quoted context omitted.

K8s is just a standardized api for running "programs" on hardware, which is a really difficult problem it solves fairly well. Is it complex? Yes, but so is the problem it's trying to solve. Is its complexity still nicer and easier to use than the previous generation of multimachine deployment systems? Also yes.

I wrote a scheduler for VMs a long time ago. k8s is basically just the same thing but for containers. It really confuses me how someone can argue for cloud providers over a decent open solution without realising their argument is simply they don't want to be managing the thing. And that's fine, most teams shouldn't be neck deep in managing a platform. But that doesn't make the solution bad.

K8s isn't even hard! My team of three manages everything on K8s and we spend ~0 minutes per week on it. Write a script to generate some YAML files, stick it in a CI pipeline, and it's basically fire-and-forget.

You're going to want most of what K8s has anyway: blue-green deployments, some way to specify how many replicas you want, health checks, etc.

The initial setup cost is annoying if you've never done it before, but in terms of maintenance it's very very easy.

Re: I am building a cloud

#485

Earlier quoted context omitted.

Docker is great development tooling (still some rough edges, of course). Docker Compose is good for running things on a single server as well. Docker Swarm and Hashicorp Nomad are good for multi-server setups. Kubernetes is... enterprise and I guess there's a scale where it makes sense. K3s and similar sort of fill the gap, but I guess it's a matter of what you know and prefer at that point. Throw on Portainer on a s…

> Docker Swarm IS that a thing still? > Kubernetes is... enterprise I would contest that. Its complex, but not enterprise. Nomad is a great tool for running processes on things. The problem is attaching loadbalancers/reverse proxies to those processes requires engineering. It comes for "free" with k8s with ingress controllers.

> IS that a thing still?

Yeah, using it in production. If you don't need the equivalent of CRDs or other complex stuff like network meshes, it's stable and pretty okay! My ingress is just a regular web server image, for example.

> It comes for "free" with k8s with ingress controllers.

Ingress Controllers will keep working but the API is frozen, I think nowadays you're supposed to use Gateway instead: https://gateway-api.sigs.k8s.io/

Re: I am building a cloud

#486

Earlier quoted context omitted.

I founded a hosting company 25 years ago when User-Mode Linux was the hot new virtualisation tech. We aspired to just replicate the dedicated server experience because that was obviously how you deploy services with the most flexibility, and UML made it so cheap! Through the 2010s I (extremely wrongly) assumed that being metered on each little part of their stack was not something most developers would choose, for th…

> I find it hard to believe that the knowledge to manage a bunch of dedicated servers is that arcane that people wouldn't choose it for this kind of gigantic saving. Managing servers is fine. Managing servers well is hard for the average person. Many hand-rolled hosting setups I've encountered includes fun gems such as: - undocumented config drift. - one unit of availability (downtime required for offline upgrades, r…

For the record, I have seen every one of those in cloud based hosting multiple times. None of those issues require special work any more than they do than in traditional hosting.

Re: I am building a cloud

#489

Earlier quoted context omitted.

I wrote a scheduler for VMs a long time ago. k8s is basically just the same thing but for containers. It really confuses me how someone can argue for cloud providers over a decent open solution without realising their argument is simply they don't want to be managing the thing. And that's fine, most teams shouldn't be neck deep in managing a platform. But that doesn't make the solution bad.

K8s isn't even hard! My team of three manages everything on K8s and we spend ~0 minutes per week on it. Write a script to generate some YAML files, stick it in a CI pipeline, and it's basically fire-and-forget. You're going to want most of what K8s has anyway: blue-green deployments, some way to specify how many replicas you want, health checks, etc. The initial setup cost is annoying if you've never done it before,…

Are you using a service like GKE, or running your own cluster? I've set up clusters "from scratch" in dev environments to get familiar with it.

Re: I am building a cloud

#490
post #34

With LLMs there is no real dev velocity penalty of using high perf. langs like say Rust. A pair of 192 Core AMD EPYC boxes will have enough headroom for 99.9% of projects.

That’ll be true for the 0.1% of project that were limited by the speed of their programming language. For the other 99.9% of projects their vibe coded rust can fly and their database, network, or raw computation will still be the bottleneck. (Percentages cited above are tongue-in-cheek, actual numbers are probably different)

sqlite when used properly can be pushed pretty far. Few biz apps are raw compute limited
Post reply on HN