161–170 of 233 posts
Earlier quoted context omitted.
What a world we live in with people thinking that the problems of a 2 (founder) engineers startup deserve k8s complexity... Even with LLMs, they are going to rack up tech debt if their focus is - as it should in as mall startup - the final product and not the tech stack itself.
> Even with LLMs, they are going to rack up tech debt And if they don’t?
Earlier quoted context omitted.
Don't. Get a chatgpt subscription and spin up a minikube cluster and launch some stuff and play around. K8s is incredibly deep and complex but with AI it's finally easy to just hello world it.
This is absolutely terrible advice. You should never ever use LLMs to work on something you don't understand already, because you have no way to catch the machine when it screws up (and it will screw up). Just like with every other form of automation before LLMs, a smart person only automates things he already knows how to do himself.
We all have different learning styles. I learn through play when it comes to LLMs.
> The CTOs I talked to aren't making a dumb choice. They're solving real problems. Unrelated to the content of the article, this sentence structure is a dead giveaway of LLM writing.
I'd expect to see a huge increase in "solving real problems" over the last months.
Earlier quoted context omitted.
as I got into SWE 4 yrs ago, this was a big part of my job as a SRE/SDET and my next job came b/c of that SRE exp which was never used, so just became an SDET. Now am laid off, and hard to find a job...
I'm sorry to read that. Unfortunately it's an industry wide problem, and it touches many areas and levels of expertise. Some believed that AI can drop costs and compressed job spaces. It starts to bounce off but it's not back to - what I could fall - normal baseline.
And it did! For companies, not for you.
I made this decision at a startup (albeit when the eng team was ~30 people, and we had a monolith with ~10 supporting services). I wouldn’t do it again, even for the reasons stated in the article. The uniformity is nice, we were moving from apps running directly ec2 instances provisioned with ansible. Each time we spun up a new service it was a process to get the ec2 instances provisioned just so. But k8s is such a p…
I really wish there was an 80% kubernetes. I think you could get there with some changes: 1. No overlay networks. 1 IP per machine. pods use dynamically allocated ports, and the kubelet enforces pods listen only on their assigned ports using seccomp. 2. No kube-proxy or equivalent Layer-4 "load-balancer". It's not good, but it's often used. You should use some kind of Layer-7 load balancing instead. Also you need to…
The reason this is accelerating recently is agents are really good at spinning up k8s clusters. They've made devops work super super simple. Basically all the annoying stuff you know you should do but it's way too much hassle - using let's encrypt to create unique certs for every app in your cluster to enable zero trust, configuring permissions and security profiles for everything etc etc (never mind just standing th…
The setup may be simple, but what about the maintenance?
Earlier quoted context omitted.
Pretty sure if there was a simple alternative, people would hate it. Everyone initially wants thing A. But then they want to customize it to do all permutations and combinations n of A, B, C. They want it to be extensible. They want redundancy. They want orchestration. They want integration. It’s why practically every config file format eventually becomes its own scripting language. Even HTML started off simple — now…
+1 on the problem of moving complexity from programming languages to configuration. One of the main problems here is that programming languages typically have lots of tools to help validate correctness, whereas configuration tools are typically either much less mature or woefully underused. There is nothing more frustrating in something failing due to a misconfiguration - but you've no idea what the correct value sho…
> You have an error in your config on line 1. Good luck.
Earlier quoted context omitted.
The setup may be simple, but what about the maintenance?
And the troubleshooting? Given the number of moving parts, I would be terrified to have to look under the hood of what Talos deployed for me.
I made this decision at a startup (albeit when the eng team was ~30 people, and we had a monolith with ~10 supporting services). I wouldn’t do it again, even for the reasons stated in the article. The uniformity is nice, we were moving from apps running directly ec2 instances provisioned with ansible. Each time we spun up a new service it was a process to get the ec2 instances provisioned just so. But k8s is such a p…
Pretty sure if there was a simple alternative, people would hate it. Everyone initially wants thing A. But then they want to customize it to do all permutations and combinations n of A, B, C. They want it to be extensible. They want redundancy. They want orchestration. They want integration. It’s why practically every config file format eventually becomes its own scripting language. Even HTML started off simple — now…
>Everyone initially wants thing A. But then they want to customize it to do all permutations and combinations n of A, B, C.
Oh, I wouldn't be so sure of that. Think about Eclipse vs IntelliJ. 10 years ago Eclipse had all the features, and IntelliJ didn't so it was fast. Most developers don't use all the features, so most developers were very happy to move to IntelliJ, even if it was not free. Then IntelliJ spent the next decade building lots of features it didn't have. Now everyone wants off of IntelliJ, because it's no longer fast. Now it's got a lot of "useless" features like Eclipse too.
So I’m personally a huge fan of k8s and while I agree it may be „complicated”, it’s because deploying applications is complicated. (I want to point out that there is no requirement no set up cert manager, ArgoCD, external secrets, etc. - and many people who’d consider a VPS would happily slap a .env with an unencrypted secret then ssh to update, but when they choose Kubernetes they take the long route of doing proper…
> many people who’d consider a VPS would happily slap a .env with an unencrypted secret then ssh to update I just want to point out that you can totally still do this with Kubernetes. Of course it's not correct, but you can save that unencrypted secret in a .env file right into your container while you're building it - no need to use Kubernetes's support for supplying environment variables from the manifest. And of c…