Live data from Hacker News

I am building a cloud

crawshaw.io

391–400 of 589 posts

Re: I am building a cloud

#391
post #251

Earlier quoted context omitted.

Then why can't we put a wrapper onto systemd and make that into a light weight k8s?

Systemd is on the wrong layer here. You need something that can set your machine up, like docker.

Systemd seems to be moving in that direction, the features are coming together to actually enable this.

Though imagining the unholy existence of an init system who's only job is to spin up containers, that can contain other inits, OS images, or whatever ..... turtles all the way down.

Re: I am building a cloud

#392
post #199

Earlier quoted context omitted.

I totally agree, but that's not what happens in reality: the average devops knows k8s and will slap it onto anything they see (if only so they can put in on their resume). The average manager hears about k8s, gets convinced they need and hires beforementioned devops to build it.

> the average devops knows k8s If you'd know Kubernetes, you know not to use it. I say that as someone who used to do consulting for it. The reality is that yet again "making money" completely collides with efficient, quality, sane productive work. For me one of the main reasons to leave that space is that I couldn't really deal with the fact that my work collides with a client's success. That said I have helped to g…

I think one big problem is that using microservice architecture doesn't mean that literally everything has to be a "microservice". if you don't truly need granual scaling (i.e. your "app" doesn't get a bunch of asymmetric loads across different paths), then you can just have more monolithic "microservices" until they need to be split up

imo this should achieve a nice balance?

Re: I am building a cloud

#393

Earlier quoted context omitted.

If you spin up Kubernetes for "a couple of containers to run your web app", I think you're doing something wrong in the first place, also coupled with your comment about adding SDN to Kubernetes. People use Kubernetes for way too small things, and it sounds like you don't have the scale for actually running Kubernetes.

I know that "resume-driven development" exists, where the tradeoffs between approaches aren't about the technical fit of the solution but the career trajectory. I've seen people making plain workstation preparation scripts using Rust, only to have something to flex about in interviews. I'm not surprised even in the slightest that DevOps workers will slap k8s on everything, to show "real industry experience" in a job…

We are building a religion, we are building it bigger We are widening the corridors and adding more lanes We are building a religion, a limited edition We are now accepting coders linking new AI brains

(Apologies to Cake. And coders.)

Re: I am building a cloud

#394

Earlier quoted context omitted.

I thought we collectively learned this with stack overflows engineering blog years ago. Scale vertically until you can't because you're unlikely to hit a limit and if you do you'll have enough money to pay someone else to solve it. Docker is amazing development tooling but it makes for horrible production infrastructure.

This is why there's an endless cycle of shitty SaaS with slow APIs and high downtime. People keep thinking that scale is something you can just add later.

I'd argue on the contrary that it's the last decades' over-engineering bender that's coming home to roost. Now too many things have too many moving parts to keep stable.

Re: I am building a cloud

#395

Earlier quoted context omitted.

Sobering comment for all the little people like myself who dream of owning a business based on a vision of cool tech that just does what it promises (as opposed to all the corporate shovelware out there)

Author here. Almost every VC rejected us when we went to get seed funding for Tailscale, we knew none of them. Friends of friends of acquaintances got us meetings. Fundraising is very possible for you if you are committed to building a business. Most important thing is don't think of fundraising as the goal, it is just a tool for building a business. (And some businesses don't need VC funding to work. Some do.) The b…

How did you eventually get funding after those initial rejections? What changed?

Re: I am building a cloud

#396

Earlier quoted context omitted.

I thought we collectively learned this with stack overflows engineering blog years ago. Scale vertically until you can't because you're unlikely to hit a limit and if you do you'll have enough money to pay someone else to solve it. Docker is amazing development tooling but it makes for horrible production infrastructure.

This is why there's an endless cycle of shitty SaaS with slow APIs and high downtime. People keep thinking that scale is something you can just add later.

What's a more reasonable general approach then?

Let's say you're a team of 1-3 technical people building something as an MVP, but don't necessarily want to throw everything away and rewrite or re-architect if it gets traction.

What are your day 1 decisions that let you scale later without over-engineering early?

I'm not disagreeing with you btw. I genuinely don't know a "right" answer here.

Re: I am building a cloud

#397

Earlier quoted context omitted.

I know that "resume-driven development" exists, where the tradeoffs between approaches aren't about the technical fit of the solution but the career trajectory. I've seen people making plain workstation preparation scripts using Rust, only to have something to flex about in interviews. I'm not surprised even in the slightest that DevOps workers will slap k8s on everything, to show "real industry experience" in a job…

Your first example sound very sensible to me? Using new technology in something small and unimportant like a setup script is a perfect way to experiment and learn. It would be irresponsible to build something important as the first thing you do in a new language.

agreed. I think if we all went with this HN mindset of "html4 and PHP work just fine" we wouldn't have gone anywhere with regards to all the technical advancements we enjoy today in the software space

Re: I am building a cloud

#398
I really like exe.dev's pricing model where I pay a fixed monthly fee for compute and then can split it up into as many VMs as I want. I use exe.dev to run little vibe-coded apps and it's nice to just leave them running without a spend meter ticking up.

We're thinking about switching to this pricing model for our own startup[1] (we run sandboxed coding agents for dev teams). We run on Daytona right now for sandboxes. Sometimes I spin up a sandboxed agent to make changes to an app, and then I leave it running so my teammate can poke around and test the running app in the VM, but each second it's running we (and our users) incur costs.

We can either build a bunch of complicated tech to hibernate running sandboxes (there's a lot of tricky edge cases for detecting when a sandbox is active vs. should be hibernated) or we can just provision fixed blocks of compute. I think I prefer the latter.

[1] https://github.com/gofixpoint/amika

Re: I am building a cloud

#399
Lots of negativity towards k8s in here. It's always funny to me when $WILDLY_POPULAR_TECH gets ripped apart like this, as though no one has ever had a positive experience with it. I've seen similar pile-ons for React, microservices, git, PHP, JavaScript, cloud services, really anything that's been adopted at scale.

Re: I am building a cloud

#400

Earlier quoted context omitted.

Exactly my point. But then developers: "I just want to go to my Heroku days again!" but then with a sufficient big company there are maaany developers doing things their slightly different way, and then other effects start compounding, and then costs go up because 15 different teams are using 27 different solutions and and and... But yeah, let's just spin-up a shadow IT VM with Debian like GP said, it's easy!

> But yeah, let's just spin-up a shadow IT VM with Debian like GP said, it's easy! That’s literally how they sold AWS in the beginning. Cloud won not because of costs or flexibility but because it allowed teams to provision their own machines from their budget instead of going through all the red tape with their IT departments creating… a bunch of shadow IT VMs! Everything old is new again, except it works on an acce…

Indeed. And it stems from the illusion that what works in solo/small teams/scrappy startup works the same when you are bigger, and that a developer can take over all the corollary work to the actual product development.

And yes, a dev that's able to do that properly (stress on properly) is indeed a signal of a better overall developer but they are a minority and anyway as orgs scale up there is just too much of "side salad" that it becomes a separated dish.

Post reply on HN