Live data from Hacker News

I Didn't Need Kubernetes, and You Probably Don't Either

benhouston3d.com

91–100 of 436 posts

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#91
post #81

Cloud Run is fine if you're a small startup and you're thinking about your monthly bill in three-figure or even four-figure terms. Like most serverless solutions, it does not permit you to control egress traffic. There are no firewall controls exposed to you, so you can't configure something along the lines of "I know my service needs to connect to a database, that's permitted, all other egress attempts are forbidden…

Cloud Run has had network egress control for a while: https://cloud.google.com/run/docs/configuring/vpc-direct-vpc

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#92
post #89
post #61

Earlier quoted context omitted.

Even for on-prem scenario, I'd rather maintain a K8S control plane and let developer teams manage their own apps deployment in their own little namespace, than provisioning a bunch of new VMs each time a team need some services deployed.

Even as a K8s hater, this is a pretty salient point. If you are serious about minimizing ops work, you can make sure people are deploying things in very simple ways, and in that world you are looking at _very easy_ deployment strategies relative to having to wire up VMs over and over again. Just feels like lots of devs will take whatever random configs they find online and throw them over the fence, so now you just h…

> Just feels like lots of devs will take whatever random configs they find online

Well it usually isn't a mystery. Requiring a developer team to learn k8s likely with no resources, time, or help is not a recipe for success. You might have minimised someone else's ops work, but at what cost?

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#93
post #90

I’ve come to the conclusion that I hate “cloud shit”, and a small part of me is convinced that literally no one actually likes it, and everyone is playing a joke on me. I have set up about a dozen rack mount servers in my life, installing basically every flavor of Unix and Linux and message busses under the sun in the process, but I still get confused by all the Kubectl commands and GCP integration with it. I might j…

I have same thoughts.

the only form of kubernetes I would be willing to try is the one with kata-containers for having all the security of virual machines.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#95
post #81

Cloud Run is fine if you're a small startup and you're thinking about your monthly bill in three-figure or even four-figure terms. Like most serverless solutions, it does not permit you to control egress traffic. There are no firewall controls exposed to you, so you can't configure something along the lines of "I know my service needs to connect to a database, that's permitted, all other egress attempts are forbidden…

Cloud Run has had network egress control for a while: https://cloud.google.com/run/docs/configuring/vpc-direct-vpc

Nice, I didn't know about this, it wasn't available last time I checked.

With that said... there are so many limitations on that list, that seriously, I can't imagine it would really be so much easier than Kubernetes.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#96
post #3

Interesting that the mania for over-investment in devops is beginning to abate. Here on Hacker News I was a steady critic of both Docker and Kubernetes, going to at least 2017, but most of these posts were unpopular. I have to go back to 2019 to find one that sparked a conversation: https://news.ycombinator.com/item?id=20371961 The stuff I posted about Kubernetes did not draw a conversation, but I was simply document…

Start-ups that don't need to scale will quickly go away, because how else are you going to make a profit? How have you been going since 2005 and still not understand the economics of software?

Just to make it clear: There are a million use cases that don't involve scaling fast.

For example B2B businesses where you have very few but extremely high value customers for specialized use cases.

Another one is building bully hardware. Your software infrastructure does not need to grow any faster than your shop floor is building it.

Whether you want to call that a "startup" is up for debate (and mostly semanticist if you ask me) but at one point they were all a zero employee company and needed to survive their first 5 years.

In general you won't find their products on the app store.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#97
post #90

I’ve come to the conclusion that I hate “cloud shit”, and a small part of me is convinced that literally no one actually likes it, and everyone is playing a joke on me. I have set up about a dozen rack mount servers in my life, installing basically every flavor of Unix and Linux and message busses under the sun in the process, but I still get confused by all the Kubectl commands and GCP integration with it. I might j…

Or if you got a static ip and fast up speed, then just port forward 80, 443 and start hosting your self. Even an old Intel Mac Book pro from 2000's with 4 GB of RAM may not be that hot running MacOS, but install Debian with no X. It is running smooth as a whistle, while running several conduit matrix, haraka, zone-mta, ice cast, nginx with no issues.

WebRTC/TUN/STUN becomes an issue with the nginx config. May consider looking at pingora. The whole rust -> binary + toml file is super nice to run from system admin perspective.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#98

People talk about Kubernetes as container orchestration, but I think that's kind of backwards. Kubernetes is a tool for creating computer clusters. Hence the name "Borg" (Kubernetes's grandpa) referring to assimilating heterogeneous hardware into a collective entity. Containers are an implementation detail. Do you need a computer cluster? If so k8s is pretty great. If you don't care about redundancy and can get all t…

What is the container orchestration tool of choice beyond docker swarm, then?

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#99
post #3

Interesting that the mania for over-investment in devops is beginning to abate. Here on Hacker News I was a steady critic of both Docker and Kubernetes, going to at least 2017, but most of these posts were unpopular. I have to go back to 2019 to find one that sparked a conversation: https://news.ycombinator.com/item?id=20371961 The stuff I posted about Kubernetes did not draw a conversation, but I was simply document…

ZIRP is over.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#100
post #89

Earlier quoted context omitted.

Even as a K8s hater, this is a pretty salient point. If you are serious about minimizing ops work, you can make sure people are deploying things in very simple ways, and in that world you are looking at _very easy_ deployment strategies relative to having to wire up VMs over and over again. Just feels like lots of devs will take whatever random configs they find online and throw them over the fence, so now you just h…

> Just feels like lots of devs will take whatever random configs they find online Well it usually isn't a mystery. Requiring a developer team to learn k8s likely with no resources, time, or help is not a recipe for success. You might have minimised someone else's ops work, but at what cost?

I am partly sympathetic to that (and am a person who does this) but I think too many devs are very nihilistic and use this as an excuse to stop thinking. Everyone in a company is busy doing stuff!

There's a lot of nuance here. I think ops teams are comfortable with what I consider "config spaghetti". Some companies are incentivised to ship stuff that's hard to configure manually. And a lot of other dynamics are involved.

But at the end of the day if a dev copy-pastes some config into a file, taking a quick look over and asking yourself "how much of this can I actually remove?" is a valuable skill.

Really you want the ops team to be absorbing this as well, but this is where constant atomization of teams makes things worse! Extra coordination costs + a loss of a holistic view of the system means that the iteration cycles become too high.

But there are plenty of things where (especially if you are the one integrating something!) you should be able to look over a thing and see, like, an if statement that will always be false for your case and just remove it. So many modern ops tools are garbage and don't accept the idea of running something on your machine, but an if statement is an if statement is an if statement.

Post reply on HN