Live data from Hacker News

I am building a cloud

crawshaw.io

501–510 of 589 posts

Re: I am building a cloud

#501

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

Missing some hn snobbery

Re: I am building a cloud

#502

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.

Docker swarm is getting development again (caught something on their slack a few weeks back).

I'd also contest the k8s is enterprise. Unless by enterprise you just mean over engineered in which case I agree.

Re: I am building a cloud

#503
post #442

Earlier quoted context omitted.

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.

it sold like 7 mil copies in a month. yes 98 was much more polished overall but 95 revolutionized personal computing as it was much more accessible than NeXT stuff

Re: I am building a cloud

#504

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

So build resiliency into your application layer.

Re: I am building a cloud

#505

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

microVM's are going to make all of these redundant

Re: I am building a cloud

#506

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

Kubernetes offers powerful low-level primitives that can support virtually any deployment architecture. However, working with these primitives directly requires significant YAML wrangling. It makes sense to build specialized solutions on top of Kubernetes that simplify common deployment patterns. Knative is one such solution. Any solution that tries to expose all underlying primitives will inevitably become as complex as Kubernetes itself.

I have been building https://github.com/openrundev/openrun, which provides a declarative solution to deploy internal web apps for teams (with SAML/OAuth and RBAC). OpenRun runs on a single-machine with Docker or it can deploy apps to Kubernetes.

Re: I am building a cloud

#507
I love this and agree with it almost in entirety. One thing that would be good to retain is 'regions' e.g 3 DCs under 10KM apart linked with free/very low cost internal network. It is cheap to build in colo these days with the advent of campus XCs and ever lowering cost of DF, optics and 400G/800G switches.

Re: I am building a cloud

#508

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

The problem is not Kubernetes but how it's treated. From its inception I've been seeing two anti-patterns: treating it as a platform (and being frustrated for Kubernetes not meeting expectations) and treating it as a product or part of a product (investing heavily into its customization and making it a dependency). Neither is practical unless you are building a platform and it is your product. Otherwise it should be viewed as an OS and treated as a commodity. You create a single big VM with MicroK8s per project (zero-ops vanilla Kubernetes) and make no dependency on how exactly Kubernetes is setup. This way you can run the same setup locally and in a data center. If ever needed your app could be moved to any cloud as long as that cloud meets basic prerequisites (like presence of persistent storage or load balancer). The best part is Kubernetes (unlike traditional OS) is API driven and your apps could be nicely packaged and managed using Terraform/OpenTofu or similar tooling.

Re: I am building a cloud

#509
post #311

Earlier quoted context omitted.

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…

People have it backwards. If you have an app and you want to run a single app yeah silly to look for K8s. If you have a beefy server or two you want to utilize fully and put as many apps on it without clashing dependencies you want to use K8s or docker or other containers. Where K8s enables you to go further.

Why would you want to use K8s for one or two beefy servers? It's designed for solving a different problem at a large scale.

Re: I am building a cloud

#510
I relate to the points about obscure platform limits, and leaky abstractions, but when I look at the exe.dev platform, it might be the most obscure PaaS I've seen, and has it's own strange abstractions.

The shell command to start a new vm, has a --prompt flag to get an LLM to configure the VM for you.

VM's have no public ipv4 IP, and the ipv6 IP doesn't seem to allow incoming connections.

The only supported inbound connections are via their HTTP proxy.

There is no private networking.

At first I interpreted the complaint about cloud providers not offering nested-virtualization, as something he intends to address by offering it as a feature, but no, instead he means that exe.dev's VM abstraction eschews the need for it.

Post reply on HN