Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I am building a cloud

crawshaw.io

Post reply on HN
Print view View original

361–370 of 589 posts

Re: I am building a cloud

#361

Post by chrneu »

radlad wrote: post #338
aliasxneo wrote: post #335

There's a common conversation that goes on around AI: some people swear its a complete waste of time and total boondoggle, some that its a good tool when used correctly, and others that its the future and nothing else matters. I see the same thing happen with Kubernetes. I've run clusters from various sizes for about half a decade now. I've never once had an incident that wasn't caused by the product itself. I recall…

The complaints I see about Kubernetes are typically more about one of two things: (a) this looks complex to learn, and I don't have a need for it - existing deployment patterns solve my use case, or (b) Kubernetes is much less inefficient than running software on bare-metal (energy or cost.) Usually they go hand in hand.

Everything is about trading convenience for knowledge/know how.

It's up to the individual to choose how much knowledge they want to trade away for convenience. All the containers are just forms of that trade.

Re: I am building a cloud

#362

Post by sahil-shubham »

otterley wrote: post #356
sahil-shubham wrote: post #131

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.

Thank you for the feedback! I appreciate it, looking forward to you trying it out and logging any issues.

I am aware of the documentation, it’s what I have been focusing on before I can post on HN. I want to make it a delight to read for other people!

As for the design decisions, I have tried keeping all the plans I made in the repo too. I wouldn’t have been able to make bhatti in a month without LLMs.

Re: I am building a cloud

#363

Post by dobreandl »

TheTaytay wrote: post #300
dobreandl wrote: post #273

Earlier quoted context omitted.

We've reduced our costs on Hetzner to about 10% on what we've paid on Heroku, for 10x performance. Kamal really kicks ass, and you can have a pretty complicated infrastructure up in no time. We're using terraform, ansible + kamal for deploys, no issues whatsoever.

Can you elaborate a bit on what terraform and mandible are doing for you in your setup?

We've configured our Hetzner servers with terraform, so we can easily spin up a new one in case we notice that we need another slave to handle extra work (1-2 mins). Ansible is responsible for configuring the server, installing all the required packages and software (not all our infrastructure is deployed with Kamal, for instance we have clickhouse instances, DBs, redis etc and normal app slaves). TLDR; it helps us have a new instance up an runing in minutes, or recreating our infrastructure for a new client environment

Re: I am building a cloud

#364

Post by kelvinjps10 »

gregdelhon wrote: post #185

You should do it in Europe, so much demand for European clouds and very weak offerings.

hezner, OVH? in terms of price and just having a vps that works european clouds are better than the american ones, for me is easier to understand a vps that is just *Linux* that whatever AWS or GCP are doing.

Re: I am building a cloud

#365

Post by j45 »

dajonker wrote: post #74

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

There exists a sweet spot between docker swarm and docker, not quite portainer, but a bit more.

The tools in this space can really help get a few containers in dev/staging/production much more manageable.

Re: I am building a cloud

#366

Post by furyofantares »

hbhhh wrote: post #334

HeavyBit is absolutely gross. I've heard lots of horrible things about them from multiple founders. One of my friends was told to come to a sex party that was all male and he is straight. It soured his relationship with the firm so much he ended up winding down the business.

Does that any anything to do with exe.dev?

Re: I am building a cloud

#367

Post by bedobi »

dajonker wrote: post #74

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

At a previous job, our build pipeline

* Built the app (into a self contained .jar, it was a JVM shop)

* Put the app into a Ubuntu Docker image. This step was arguably unnecessary, but the same way Maven is used to isolate JVM dependencies ("it works on my machine"), the purpose of the Docker image was to isolate dependencies on the OS environment.

* Put the Docker image onto an AWS .ami that only had Docker on it, and the sole purpose of which was to run the Docker image.

* Combined the AWS .ami with an appropriately sized EC2.

* Spun up the EC2s and flipped the AWS ELBs to point to the new ones, blue green style.

The beauty of this was the stupidly simple process and complete isolation of all the apps. No cluster that ran multiple diverse CPU and memory requirement apps simultaneously. No K8s complexity. Still had all the horizontal scaling benefits etc.

Re: I am building a cloud

#368

Post by messh »

There are plenty of alternatives out there. I built https://shellbox.dev, which gives you instant vms via ssh where unlike exe you pay only for what you use-- scale to zero. It is also regular linux, supporting vscode and zed remote, Nested virtualization, etc.

If you're looking to invest im fine with only $5M :)

Re: I am building a cloud

#369

Post by sahil-shubham »

codethief wrote: post #319
sahil-shubham wrote: post #200

Earlier quoted context omitted.

Not sure what you mean. I use the above linked personal project, bhatti, which internally uses Firecracker microVMs.

Ah, for some reason I didn't make the connection between your VM setup and your agent sandbox setup and thought those were two separate things. Sorry about that!

No worries! I too have been using machines/sandboxes/VMs/microVMs very interchangeably these days. Former is understood by a broader group, but latter is more precise. Trying to find a balance.

Re: I am building a cloud

#370

Post by throwaway894345 »

dajonker wrote: post #74

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

This feels like the microservices versus monolith problem. You can use cloud services or not, and that's orthogonal to running your app in Kubernetes or in a VM.

Similarly, I suspect (based on your "hardening" grievance) that a lot of your tedium is just that cloud APIs generally push you toward least-privileges with IAM, which is tedious but more secure. And if you implement a comparably secure system on your single VM (isolating different processes and ensuring they each have minimal permissions, firewall rules, etc) then you will probably have strictly more incidents and debugging effort. But you could go the other way and make a god role for all of your services to share and you will spend much less time debugging or dealing with incidents.

Even with a single VM, you could throw k3s on it and get many of the benefits of Kubernetes (a single, unified, standardized, extensible control plane that lots of software already supports) rather than having to memorize dozens of different CLI utilities, their configuration file formats, their path preferences, their logging locations, etc. And as a nice bonus, you have a pretty easy path toward high availability if you decide you ever want your software to run when Google decides to upgrade the underlying hardware.

Post reply on HN