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…
I Didn't Need Kubernetes, and You Probably Don't Either
91–100 of 436 posts
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#92Earlier 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…
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
#93I’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…
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
#94Re: I Didn't Need Kubernetes, and You Probably Don't Either
#95Cloud 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
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
#96Interesting 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?
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
#97I’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…
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
#98People 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…
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#99Interesting 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…
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#100Earlier 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?
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.