Live data from Hacker News

I am building a cloud

crawshaw.io

441–450 of 589 posts

Re: I am building a cloud

#441
post #246
post #157

Earlier quoted context omitted.

DevOps here. The trouble is that we are literally expected to do this everywhere we go. I've personally advocated for approaches which use say, a pair of dedicated servers, or VMs as in GPs example. If you want it outside of AWS/GCP/Azure, you're regarded as a crazy person. If you don't adopt "best practices" (as defined by vendors) then management are scared. Management very often trust the sales and marketing depar…

The following happened to a friend. Around the time of the pandemic, a company wanted to make some Javascript code do a kind of transformation over large number of web-pages (a billion or so, fetched as WARC files from the web archive). Their engineers suggested setting up SmartOS VMs and deploying Manta (which would have allowed the use of the Javascript code in a totally unmodified way -- map-reduce from the comman…

> Personally, I believe that the tech industry sustains itself via technical debt, much like the real economy sustains itself on real debt. In some sense, everyone is trying to gaslight everyone else into incurring as much technical debt as possible, so that a way to service the debt can be sold.

This feels like a reminder that everything "Cloud" is still basically the same as IBM's ancient business model. We've always just been renting time on someone else's computers, and those someone else people are always trying to rent more time. The landlords shift, but the game stays the same.

Re: I am building a cloud

#442

> 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 don't get it, I think that k8s is the best software written since win95. It redefines computing in the same way IMHO. I have some experience in working with k8s on prod and I loved every moment of it. I'm definitely missing something.

> the best software written since win95

This feels like what us Brits would call "damning with faint praise".

Windows 95 was terrible. Really bad. If you really mean to say that Kubernetes is revolutionary and well-engineered, Windows 2000 would be a much better example.

Re: I am building a cloud

#443
post #414

Earlier quoted context omitted.

Even if using just one VM, I'll probably slap k3s on it and manage my application using manifests. It's just so much easier than dealing with puppet or chef or vanilla cloud-init. Docker compose works too, but at that point it's just easier to stick with k3s and then I can have nice things like background jobs, a straightforward path to HA, access to an ecosystem of existing software, and a nicer CLI.

Thats what I don't get when people bring up this idea k8s is complicated. All of those other tools are complicated and fragile

I think the things that trip people up are:

1. People expect k8s to be an opinionated platform and it's very happy to let you make a mess

2. People think k8s is supposed to be a cross platform portability layer and ... it maybe can be if you're very careful, but it's mostly not that

3. People compare k8s/cloud/etc to some monolithic application with admin permissions to everything and they compare that to the "difficulty" of dealing with RBAC/IAM/networking/secrets management

4. People don't realize how much more complicated vanilla Linux tooling and how much more accidental complexity is involved

Re: I am building a cloud

#444
post #338

Earlier quoted context omitted.

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.

> (b) Kubernetes is much less inefficient than running software on bare-metal (energy or cost.) You surely meant "much less efficient than"

I did, thanks for the correction.

There also seems to be confusion about what I meant by "bare-metal." I wasn't intending to refer to the server ownership model, but rather the deployment model where you deploy software directly onto an operating system.

Re: I am building a cloud

#445
post #340

Earlier quoted context omitted.

The funniest thing is that kubernetes was designed for bare metal running, not cloud...

Yeah if someone says that k8s is costing them energy they are either using it very, very incorrectly, or they just don't know what they are talking about.

Running a Kubernetes deployment requires running many additional orchestration services that bare-metal deployments (whether running on-prem or in the cloud) do not.

Re: I am building a cloud

#446
post #343

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…

Funnily enough the post isn't shitting on k8s, it's shitting on cloud and that k8s (lipstick) can't fix the pig (cloud)

That part was really surprising to me because for the kind of compute lake he’s talking about building, k8s seems like a pretty good fit for the layer that sits just above it.

We run k8s with several VMs in a couple different cloud providers. I’d love it if I could forget about the VMs entirely.

Is there a simpler thing than k8s that gets you all that? Probably. But if you don’t use k8s, aren’t you doomed to reimplement half of it?

Like these things:

- Service discovery or ingress/routing (“what port was the auth service deployed on again?”)

- Declarative configuration across the board, including for scale-out

- Each service gets its own service account for interacting with external systems

- Blue/green deployments, readiness checks, health checks

- Strong auditing of what was deployed and mutated, when, and by whom

Re: I am building a cloud

#447
post #338

Earlier quoted context omitted.

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.

Which is an interesting perspective, considering I've led a platform based on Kubernetes running on company-owned bare-metal. I was actually hired because developers were basically revolting at leaving the cloud because of all the "niceties" they add (in exchange for that hefty cloud tax) which essentially go away on bare-metal. The existing DevOps team was baffled why the developers didn't like when they were handed…

For many shops, even Docker Compose is not necessary. It is still possible to deploy software directly on a VM/LXC container.

I agree that Kubernetes can help simplify the deployment model for large organizations with a mature DevOps team. It is also a model that many organizations share, and so you can hire for talent already familiar with it. But it's not the only viable deployment model, and it's very possible to build a deployment system that behaves similarly without bringing in Kubernetes. Yes, including automatic preview deployments. This doesn't mean I'm provided a VM and told to figure it out. There are still paved-path deployment patterns.

As a developer, I do need to understand the environment my code runs in, whether it is bare-metal, Kubernetes, Docker Swarm, or a single-node Docker host. It impacts how config is deployed and how services communicate with each other. The fact that developers wrote Dockerfiles is proof that they needed to understand the environment. This is purely a tradeoff (abstracting one system, but now you need to learn a new one.)

Re: I am building a cloud

#449
post #368

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 :)

Neat service. Website doesn't provide enough information for me to trust any workloads to it. Not clear where the underlying infrastructure is, what security guarantees I get, etc.

Thanks for the feedback. Ill improve it. In the meanwhile, there are more technical details on this blog post: https://shellbox.dev/blog/race-to-the-bottom.html
Post reply on HN