14 ms·
I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever
- yarapavan 2y agohttps://archive.ph/2024.11.26-114301/https://blog.stackademic.com/i-stopped-using-kubernetes-our-devops-team-is-happier-than-ever-a5519f916ec0 https://archive.ph/2024.11.26-114301/https://blog.stackademi...
- millerm 2y agoThank you. I abhor Medium. I need to read this clusterf** though, as I read some comments and I have to witness this ineptitude myself.
- risson 2y agoSo they made bad architecture decisions, blamed it on Kubernetes for some reason, and then decided to rebuild everything from scratch. Solid. The takeaway being what? Don't make bad decisions?
- danjl 2y agoThe third version works
- nfnfyeaaah 2y ago[dead]
- whynotmaybe 2y agoMy personal takeaway, when it fails and you can't blame anyone for any reason, blame a tool. You'll get the whole team helping you when replacing the tool and setting up a better solution. If you blame anyone, people will start to be extra cautious and won't take any initiative. But don't overuse it, if you always blame the tool, you'll end up like my ex colleague "Steve" where every failure was Microsoft's fault.
- mst 2y agoI've always been fond of blaming myself and asking everybody else to help make sure I don't cock it up a second time - when it works out I get lots of help, lots of useful feedback, and everybody else feels good about putting the effort in. This does require management who won't punish you for recording it as your fault, though. I've been fairly lucky in that regard.
- Aperocky 2y agoYour ex-colleague may not be factually correct, but I agree with him in spirit.
- whynotmaybe 2y agoIf you use powershell, what's your reaction when you delete some stuff by using the "-Force" parameter and that it's deleted ? Steve usually said that Microsoft should ask for a confirmation before deleting anything, even with the "-Force" parameter. It was Microsoft's fault when the whole test environment, that he spent two days setting up, was deleted with the "-Force" parameter. He said something along the lines of "Microsoft shouldn't let me do this".
- StressedDev 2y agoI think the takeaway was Kubernetes did not work for their team. Kubernetes was probably not the root problem but it sounds like they simplified their infrastructure greatly by standardizing on a small set of technologies. Kubernetes is not an easy to use technology and sometimes its documentation is lacking. My gut feeling is Kubernetes is great if you have team members who are willing to learn how to use it, and you have a LOT of different containers to run. It probably is not the best solution for small to medium sized teams because of its complexity and cost.
- ali_piccioni 2y agoIt highlights a classic management failure that I see again and again and again: Executing a project without identifying the prerequisite domain expertise and ensuring you have the right people.
- namaria 2y agoWell understanding the problem and finding competent people is hard, riding on tool marketing and hiring bootcampers to do as you say is easy.
- supersixirene 2y ago[dead]
- deleted 2y ago[deleted]
- qrios 2y agohttps://news.ycombinator.com/item?id=42234097 https://news.ycombinator.com/item?id=42234097
- mdaniel 2y agoBe forewarned that one is flagged, so contributing comments to it may be a losing proposition I thought for sure you were going to link to https://news.ycombinator.com/item?id=42226005 https://news.ycombinator.com/item?id=42226005 (Dear friend, you have built a Kubernetes; Nov 24, 2024; 267 comments)
- Havoc 2y agoHow do you end up with 200 yaml file “basic deployments” without anyone looking up from their keyboard and muttering “guys what are we doing”? Honestly they could have picked any stack as next one because the key win here was starting from scratch
- torton 2y ago“We want to use one standard Helm chart for all applications but then we need it to support all possible variations and use cases across the whole company”
- Havoc 2y agoCan’t fix organisational problems with yaml ;)
- fireflash38 2y agoBut can you fix them with templated yaml?
- Havoc 2y agoOnly if you sprinkle some office politics on top of the template
- marcosdumay 2y agoJust go fully functional document generation languages, make your world there, and forget about the organizational problems.
- StressedDev 2y agoThis is not that surprising. First, it depends on how big the YAML files were and what was in them. If you have 200 services, I could easily see 200 YAML files. Second, there are non-service reasons to have YAML files. You might have custom roles, ingresses, volumes, etc. If you do not use something like Helm, you might also have 1 YAML file per environment (not the best idea but it happens). My suspicion is the original environment (47 Kubernetes clusters, 200 YAML files, unreliable deployments, using 3 clouds, etc.) was not planned out. You probably had multiple teams provisioning infrastructure, half completed projects, and even dead clusters (clusters which were used once but were not destroyed when they were no longer used). I give the DevOps team in the article a lot of credit for increasing reliability, reducing costs, and increasing efficiency. They did good work.
- nisa 2y agoI've read this article now multiple times and I'm still not sure if this is just good satire or if it's real and they can burn money like crazy or some subtle ad for aws managed cloud services :)
- bdangubic 2y agoI would be sooooooo embarrassed to write this article and publish it
- catdog 2y agoThose kind of articles often read like an ad for managed cloud services. "We got rid of that complicated, complicated Kubernetes beast by cobbling together 20 bespoke managed services from provider X which is somehow so much easier".
- scirob 2y agoagree, feels like content marketing by AWS
- andrewstuart 2y agoWhen they pulled apart all those kubernetes clusters they probably found a single fat computer would run their entire workload. “Hey, look under all that DevOps cloud infrastructure! There’s some business logic! It’s been squashed flat by the weight of all the containers and orchestration and serverless functions and observability and IAM.”
- StressedDev 2y agoI don't think this is a fair comment. This happens sometimes but usually people go with Kubernetes because they really do need its power and scalability. Also, any technology can be misused and abused. It's not the technology's fault. It's the people who misuse the technology's fault (). () Even here, a lot of it comes from ignorance and human nature. 99.9% of people do not set out to fail. They usually do the best they can and sometimes they make mistakes.
- andrewstuart 2y agoThe pointy is most organisations reach for container orchestration before they attempt to build fast software on a single machine.
- rvense 2y agoMy company has more microservices than paying customers.
- FridgeSeal 2y agoGiven that seemingly half the devs and orgs are antithetical to writing performant software, or optimising anything I somewhat doubt that’s going to happen anytime soon. As much as I’d like that to happen. Performance isn’t the only reason to use container orchestration tools: they’re handy for just application lifecycle management.
- jumpoddly 2y ago> 2 team members quit citing burnout And I would have gotten away with it too if only someone would rid me of that turbulent meddling cluster orchestration tooling!
- TheSwordsman 2y agoYeah, I'd bet their burnout risks aren't going to go away by just replacing k8s with ECS. I also hope they have a good support contract with AWS, otherwise they are going to be in for a fun surprise when ECS has some weird behavior or bug.
- m1keil 2y agoHow to save 1M off your cloud infra? Start from a 2M bill. That's how I see most of these projects. You create a massively expensive infra because webscale, then 3 years down the road you (or someone else) gets to rebuild it 10x cheaper. You get to write two blog posts, one for using $tech and one for migrating off $tech. A line in the cv and a promotion. But kudos for them for managing to stop the snowball and actually reverting course. Most places wouldn't dare because of sunken costs.
- saylisteins 2y agoI don't think that's necessarily a problem. When starting a new product time to market as well as identifying the user needs feature wise is way more important than being able to scale "Infinitely". It makes sense to use whatever $tech helps you get an MVP out asap and iterate on it. once you're sure you found gold, then it makes sense to optimize for scale. The only thing I guess one has to worry about when developing something like that, is to make sure good scalability is possible with some tinkering and efforts and not totally impossible.
- m1keil 2y agoI agree with you. I'm not advocating for hyper cost optimization at an early stage startup. You probably don't need k8s to get your mvp out of the door either.
- _bare_metal 2y agoTo expand on this, I run BareMetalSavings.com[0] and the most common cause of people staying with the cloud is it's very hard for them to maintain their own K8S cluster(s), which they want to keep because they're great for any non-ops developer. So those savings are possible only if your devs are willing to leave the lock in of comfort [0]: https://BareMetalSavings.com https://BareMetalSavings.com
- marcinzm 2y agoCloud isn't about comfort lock in but dev efficiency.
- geuis 2y agoOh boy. Please, please stop using Medium for anything. I have lost count of how many potentially interesting or informative articles are published behind the Medium sign-in wall. At least for me, if you aren't publishing blog articles in public then what's the point of me trying to read them.
- whereismyacc 2y agoI believe the blog poster has an option to toggle this. Maybe the default behaves like this?
- negatic 2y agoword
- throwaway2037 2y ago> "Create an account to read the full story." Why is this required?
- wetpaws 2y ago[dead]
- klysm 2y agoMoney
- throwaway92t2 2y agoThey are also misleading the users with that message. I signed up, but now I got a message that I have to upgrade to a paid account... If they had told me that from the start, I would not bother with creating an account at all. The message implies that a free account would be enough
- suzzer99 2y agoYeah that's a BS dark pattern that drops my opinion of the site to zero.
- figassis 2y agoWhy exactly did they have 47 clusters? One thing I noticed (maybe because I’m not at that scale) is that companies are running 1+ clusters per application. Isn’t the point of kubernetes that you can run your entire infra in a single cluster, and at most you’d need a second cluster for redundancy, and you can spread nodes across regions and AZs and even clouds? I think the bottleneck is networking and how much crosstalk your control nodes can take, but that’s your architecture team’s job?
- tonfreed 2y agoI work for a large corp and we have three for apps (dev, integrated testing, prod) plus I think two or three more for the platform team that I don't interact with. 47 seems horrendously excessive
- m00x 2y agoYeah, it's not very smart. I'm at a company with a $50B+ MC and we run prod on a cluster, staging on another one, then it's tooling clusters like dev spaces, ML, etc. I think in total we have 6 of 7 for ~1000 devs and thousands of nodes. It makes sense that getting off k8s helped them if they were using it incorrectly.
- pm90 2y agoThere are genuine reasons for running multiple clusters. It helps to sometimes keep stateful (databases generally) workloads on one cluster, have another for stateless workloads etc. Sometimes customers demand complete isolation so they get their own cluster (although somehow its ok that the nodes are still VMs that are probably running on shared nodes… these requirements can be arbitrary sometimes).
- m00x 2y agoI feel like OP would've been much better off if they just reworked their cluster into something sensible instead of abandoning K8s completely. I've worked on both ECS and K8s, and K8s is much better. All of the problems they listed were poor design decisions, not k8s limitations. - 47 Clusters: This is insane. They ack it in the post, but they could've reworked this. - Multi-cloud: It's now not possible with ECS, but they could've limited complexity with just single-cloud k8s.
- paulddraper 2y ago47 clusters is major "we didn't know what we were doing"
- grepfru_it 2y agoAt my last gig we were in the process of sunsetting 200+ clusters. We allowed app teams to request and provision their own cluster. That 3 year experiment ended with a migration down to 24ish clusters (~2 clusters per datacenter)
- supersixirene 2y ago[dead]
- rootlocus 2y ago> As the number of microservices grew, each service often got its own dedicated cluster
- nasmorn 2y agoHow is K8S better for simple workloads? ECS works fine and has way fewer knobs to turn.
- teekert 2y agoI can’t post a translated Dutch website on HN without it being shadow blocked, yet one can post stuff like this. Still love HN of course!
- dddw 2y ago432 error: kaaskop not allowed
- b99andla 2y agoMedium, so cant read.
- huksley 2y ago47 clusters? Is that per developer? You could manage small, disposable VPS for every developer/environment, etc and only have Kubernetes cluster for a production environment...
- scirob 2y agoThe price comparison doesn't make sense if they used to have a multi cloud system and now its just AWS. Makes me fear this is just content paid by AWS. Actually getting multi cloud to work is a huge achievment and I would be super interested to hear of another tech standard that would make that easier. also : post paywall mirror https://archive.is/x9tB6 https://archive.is/x9tB6
- Jean-Papoulos 2y ago>$25,000/month just for control planes To get to this point, someone must have fucked up way earlier by not knowing what they were doing. Don't do k8s kids !
- mrkeen 2y ago> DevOps Team Is Happier Than Ever Or course they are. The original value proposition of cloud providers managing your infra (and moreso with k8s) was that you could fire your ops team (now called "DevOps" because the whole idea didn't pan out) and the developers could manage their services directly. In any case, your DevOps team has job security now.
- adamtulinius 2y agoIt doesn't take any more competent people to self-host a modern stack, than it does to babysit how a company uses something like Azure. The original value proposition is false, and more and more are realising this.
- karmarepellent 2y agoI think the value proposition holds when you are just getting started with your company and you happen to employ people that know their way around the hyperscaler cloud ecosystems. But I agree that moving your own infra or outsourcing operations when you have managed to do it on your own for a while is most likely misguided. Speaking from experience it introduces costs that cannot possibly be calculdated before the fact and thus always end up more complicated and costlier than the suits imagined. In the past, when similar decicions were made, I always thought to myself: You could have just hired one more person bringing their own, fresh perspective on what we are doing in order to improve our ops game.
- wyclif 2y agoOh, I've seen this before and it's true in an anecdotal sense for me. One reason why is that they always think of hiring an additional developer as a cost, never savings.
- flumpcakes 2y agoHammer meet nail. I currently work in a more traditional "ops" team with our cloud infrastructure dictated by development (through contract hires at first, and now a new internal DevOps team). It's mind boggling how poorly they run things. It goes so deep it's almost issues at product design stage. There's now a big project to move the responsibility back into our team because it's not fit for purpose. I think an operations background gives you a strong ability to smell nonsense and insecurity. The DevOps team seems to be people who want to be 'developers' rather than people who care about 'ops'. Yaml slinging without thinking about what the yaml actually means.
- amne 2y agoDon't bother reading. This is just another garbage in garbage out kind of article written by something that ends in gpt. Information density approaches zero in this one.
- throwaway984393 2y ago[dead]
- timhigins 2y agoIf you have 200 YAML files for a single service and 46 clusters I think you're using k8s wrong. And 5 + 3 different monitoring and logging tools could be a symptom of chaos in the organization. k8s, and the go runtime and network stack have been heavily optimized by armies of engineers at Google and big tech, so I am very suspicious of these claims without evidence. Show me the resource usage from k8s component overhead, and the 15 minute to 3 minute deploys and then I'll believe you. And the 200 file YAML or Helm charts so I can understand why in gods name you're doing it that way. This post just needs a lot more details. What are the typical services/workloads running on k8s? What's the end user application? I taught myself k8s in the first month of my first job, and it felt like having super powers. The core concepts are very beautiful, like processes on Linux or JSON APIs over HTTP. And its not too hard to build a CustomResourceDefinition or dive into the various high performance disk and network IO components if you need to. I do hate Helm to some degree but there are alternatives like Kustomize, Jsonnet/Tanka, or Cue https://github.com/cue-labs/cue-by-example/tree/main/003_kubernetes_tutorial#controlling-kubernetes-with-cue https://github.com/cue-labs/cue-by-example/tree/main/003_kub.... You can even manage k8s resources via Terraform or Pulumi
- deleted 2y ago[deleted]
- namaria 2y ago> I do hate Helm to some degree I feel you. I learned K8s with an employer where some well intentioned but misguided back end developers decided that their YAML deployments should ALL be templated and moved into Helm charts. It was bittersweet to say the least, learning all the power of K8s but having to argue and feel like an alien for saying that templating everything was definitely not going to make everything easier on the long term. Then again they had like 6 developers and 30 services deployed and wanted to go "micro front end" on top of it. So they clearly had misunderstood the whole thing. CTO had a whole spiel on how "microservices" were a silver bullet and all. I didn't last long there but they paid me to learn some amazing stuff. Which, in retrospect, they also taught me a bunch of lessons on how not to do things.
- brainzap 2y ago
- deskr 2y agoSo many astonishing things were done ... > As the number of microservices grew, each service often got its own dedicated cluster. Wow. Just wow.
- jerf 2y agoThat's not a microservice; that's a macroservice.
- misswaterfairy 2y agoDistributed cloud-native monolith?
- miyuru 2y agois this article written by AI? other posts are non related and at the end promotes a tool that writes AI powered blog posts.
- ExoticPearTree 2y agoIs there a non-paid version of this? The title is a little clickbait, but reading the comments here seems like this is a story that jumped on the k8s bandwagon, made a lot of terrible decisions along the way and now they're blaming k8s for everything.
- jacek 2y agohttp://archive.today/FGqCu http://archive.today/FGqCu
- edude03 2y agoLike most tech stories this had pretty much nothing to do the tool itself but with the people/organization. The entire article can be summarized with this one quote > In short, organizational decisions and an overly cautious approach to resource isolation led to an unsustainable number of clusters. And while I emphasize with how they could end up in this situation, it feels like a lot of words were spent blaming the tool choice vs being a cautionary tail about for example planning and communication.
- mst 2y agoThe article reads to me as pretty explicitly saying that the only real takeaway wrt k8s itself is "it was the wrong choice for us and then we compounded that wrong choice by making more wrong choices in how we implemented it."
- edude03 2y agoMaybe I'm reading it with rose coloured glasses - but I feel like the only thing kubernetes "did wrong" is allowing them to host multiple control planes. Yes, you need 3+ CP instances for HA, but the expectation is you'd have 3 CP instances for X (say 10) workers for Y (say 100) apps. Their implied ratio was insane in comparison. Since you can't run the Fargate control plane that indirectly solved that problem for them
- marcinzm 2y agoIn my experience organizations that end up this way have a very much non blame-free culture. Can be driven by founders that lack technical skills and management experience but have a type-A personality. As a result no one wants to point out a bad decision because the person who made it will get reprimanded heavily. So they go down a path that is clearly wrong until they find a way to blame something external to reset. Usually that's someone who recently left the company or some tool choice.
- rob_c 2y agoHow did your managers ever _ever_ sign off on something that cost an extra $0.5M? Either your pre profit or some other bogus entity, or your company streamlined moving to k8s and then further streamlined by cutting away things you don't need. I'm frankly just alarmed at the thought of wasting that much revenue, I could bring up a fleet of in house racks for that money!
- woile 2y agoWhat else is out there? I'm running docker swarm and it's extremely hard to make it work with ipv6. I'm running my software on a 1GB RAM cloud instance and I pay 4EUR/month, and k8s requires at least 1GB of RAM. As of now, it seems like my only alternative is to run k8s on a 2GB of RAM system, so I'm considering moving to Hetzner just to run k3s or k0s.
- justinclift 2y agoAre you not using docker swarm behind a reverse proxy? ie nginx has the public facing ipv4 & ipv6 address(es), with docker swarm behind that communicating to the nginx proxies over ipv4
- woile 2y agoI have traefik as part of the docker-compose file. Installing nginx on the host seems less reproducible, though it could fix my problem. I guess I would choose something as caddy (I'm not that happy with traefik)
- justinclift 2y agoI've not used Caddy before personally, but if it does reverse proxying then it'd probably work fine rather than Nginx. :)
- rane 2y agoI run k3s on a single hetzner ARM64 VPS and it works pretty well for personal projects. 2 vcpu and 4GB ram for 4€/mo.
- cies 2y agoI've looked into K8s some years back and found so many new concepts that I thought: is our team big enough for so much "new". Then I read someone saying that K8s should never be used for teams <20 FTE and will require 3 people to learn it for redundancy (in case used to self-host a SaaS product). This seemed really good advice. Our team is smaller than 20FTE, so we use AWS/Fargate now. Works like a charm.
- nrvn 2y agoKubernetes is not a one size fits all solution but even the bullet points in the article raise a number of questions. I have been working with Kubernetes since 2016 and keep being pragmatic on tech stuff. Currently support 20+ clusters with a team of 5 people across 2 clouds plus on-prem. If Kubernetes is fine for this company/project/business use case/architecture we'll use it. Otherwise we'll consider whatever fits best for the specific target requirements. Smelly points from the article: - "147 false positive alerts" - alert and monitoring hygiene helps. Anything will have a low signal-to-noise ratio if not properly taken care of. Been there, done that. - "$25,000/month just for control planes / 47 clusters across 3 cloud providers" - multiple questions here. Why so many clusters? Were they provider-managed(EKS, GKE, AKS, etc.) or self-managed? $500 per control plane per month is too much. Cost breakdown would be great. - "23 emergency deployments / 4 major outages" - what was the nature of emergency and outages? Post mortem RCA summary? lessons learnt?.. - "40% of our nodes running Kubernetes components" - a potential indicator of a huge number of small worker nodes. Cluster autoscaler been used? descheduler been used? what were those components? - "3x redundancy for high availability" - depends on your SLO, risk appetite and budget. it is fine to have 2x with 3 redundancy zones and stay lean on resource and budget usage, and it is not mandatory for *everything* to be highly available 24/7/365. - "60% of DevOps time spent on maintenance" - https://sre.google/workbook/eliminating-toil/ https://sre.google/workbook/eliminating-toil/ - "30% increase in on-call incidents" - Postmortems, RCA, lessons learnt? on-call incidents do not increase just because of the specific tool or technology being used. - "200+ YAML files for basic deployments" - There are multiple ways to organise and optimise configuration management. How was it done in the first place? - "5 different monitoring tools / 3 separate logging solutions" - should be at most one for each case. 3 different cloud providers? So come up with a cloud-agnostic solution. - "Constant version compatibility issues" - if due diligence is not properly done. Also, Kubernetes API is fairly stable(existing APIs preserve backwards compatibility) and predictable in terms of deprecating existing APIs. That being said, glad to know the team has benefited from ditching Kubernetes. Just keep in mind that this "you don't need ${TECHNOLOGY_NAME} and here is why" is oftentimes an emotional generalisation of someone's particular experience and cannot be applied as the universal rule.
- ihaku 2y ago[dead]
- xenospn 2y agoI’ve been building software for 25 years across startups and giant megacorps alike, and I still don’t know what Kubernetes is.
- executesorder66 2y agoAnd if in the next 25 years you figure out how to use a search engine, you might find out! :p
- xenospn 2y agoMaybe one day I’ll have a reason to!
- smitelli 2y agoKubernetes, in a nutshell, is a dozen `while true` loops all fighting with each other.
- paxys 2y agoAre the people who decided to spin up a separate kubernetes cluster for each microservice still employed at your organization? If so, I don't have high hopes for your new solution either.
- threePointFive 2y agoDoes anyone have access to the full article? I'm curious what their alternative was. Terraform? Directly using cloud apis? VMs and Ansible?
- phendrenad2 2y ago> We selected tools that matched specific workloads: > Stateless services → Moved to AWS ECS/Fargate. > Stateful services → Deployed on EC2 instances with Docker, reducing the need for complex orchestration. > Batch jobs → Handled with AWS Batch. > Event-driven workflows → Shifted to AWS Lambda.
- marcosdumay 2y agoSo... They outsourced their OPS?
- phendrenad2 2y agoToo bad the author and company are anonymous. I'd like to confirm my assumption that the author has zero business using k8s at all. Infrastructure is a lost art. Nobody knows what they're doing. We've entered an evolutionary spandrel where "more tools = better" meaning the candidate for an IT role who swears by 10 k8s tools is always better than the one who can fix your infra, but will also remove k8s because it's not helping you at all.
- rdsubhas 2y agoI wouldn't trust the management of this team for anything. They appear totally incompetent in both management and basic half-brain analytical skills. Who in the heck creates a cluster per service per cloud provider, duplicate all the supporting services around it, burn money and sanity in a pit, and blame the tool. Literally every single decision they listed was to use any of the given tools in the absolute worst, incompetent way possible. I wouldn't trust them with a Lego toy set with this record. The people who quit didn't quit merely out of burnout. They quit the stupidity of the managers running this s##tshow.
- karmajunkie 2y agothat tends to be the take on most “k8s is too complex” articles, at least the ones i’ve seen. yes, it’s complex, but it’s simpler than running true high availability setups without something like it to standardize the processes and components needed. what i want to see is a before and after postmortem on teams that dropped it and compare their numbers like outages to get at the whole truth of their experience.
- InDubioProRubio 2y agoComplexity is a puzzle and attracts a certain kind of easy bored dev, who also has that rockstar flair, selling it to management - then quitting (cause bored) leaving a group of wizard-prophet-whorshippers to pray to the k8 goddess at the monolith circle at night. And you can not admit as management, that you went all in on a guru and a cult.
- notnmeyer 2y ago…i’m sorry, what? k8s can be as simple or complex as you make it.
- withinboredom 2y agoThen they hire a different cult leader, one that can clean up the mess and simplify it for the cult that was left behind. The old cult will question their every motive, hinder them with questions about how they could ever make it simpler. Eventually, once the last old architecture is turned off; they will see the errors of their ways. This new rock star heads off to the next complicated project. A new leader arrives and says, “we could optimize it by…”
- chris_wot 2y agoWould have loved to know more about this, but I sure as heck am not going to pay to find out.
- bdcravens 2y agoBasically they went AWS-native, with ECS being the biggest part of that. I'm currently trying to move our own stack into a simpler architecture, but I can wholeheartedly recommend ECS as a Kubernetes alternative, giving you 80% of the functionality for 20% of the effort.
- sontek 2y agoI'm interested in reading this but don't want to have to login to medium to do so. Is there an alternate link?
- mdaniel 2y agohttps://scribe.rip/i-stopped-using-kubernetes-our-devops-team-is-happier-than-ever-a5519f916ec0 https://scribe.rip/i-stopped-using-kubernetes-our-devops-tea... works for any Medium backed blog, which is almost always given away by the URL ending in a hex digits slug https://news.ycombinator.com/item?id=28838053 https://news.ycombinator.com/item?id=28838053 is where I learned about that, with the top comment showing a bazillion bookmarklet fixes. I'd bet dollars to donuts someone has made a scribe.rip extension for your browser, too
- millerm 2y agohttps://archive.ph/2024.11.26-114301/https://blog.stackademic.com/i-stopped-using-kubernetes-our-devops-team-is-happier-than-ever-a5519f916ec0#selection-609.75-609.171 https://archive.ph/2024.11.26-114301/https://blog.stackademi...
- mercurialuser 2y agoWe have 3 cluster, prod, dev, test with a few pod each. Each cluster is wasting tons of cpu and i/o bandwidth just to be idle. I was told that it is etcd doing thousands i/o per second and this is normal. For a few monolith
- jimberlage 2y ago> We were managing 47 Kubernetes clusters across three cloud providers. What a doozy of a start to this article. How do you even reach this point?
- Opteryx99 2y ago[flagged]
- dvektor 2y agoI feel like the medium paywall saved me... as soon as I saw "47 clusters across 3 different cloud providers", I begin to think that the tool used here might not actually the real issue.
- zeroc8 2y agoIt's the same story over and over again. Nobody gets fired for choosing AWS or Azure. Clueless managers and resume driven developers, a terrible combination. The good thing is that this leaves a lot of room for improvement for small companies, who can out compete larger ones by just not making those dumb choices.
- alexyz12 2y agobut does improving really help these small companies in the way it matters? If the cost of the infrastructure is apparently not important to the needs of the business..
- ninininino 2y agoA cluster per service sounds a bit like having an aircraft carrier for each aircraft.
- denysvitali 2y agoSkill issue
- bklw 2y agoThe leaps in this writing pain me. There are other aspects, but they’ve been mentioned enough. Vendor lock in does not come about by relying only on one cloud, but by adopting non-standard technology and interfaces. I do agree that running on multiple providers is the best way of checking if there is lock-in. Lowering the level of sharing further by running per-service and per-stage clusters, as mentioned in the piece was likewise at best an uninformed decision. Naturally moving to AWS and letting dedicated teams handle workload orchestration at much higher scale will yield better efficiencies. Ideally without giving up vendor-agnostic deployments by continuing the use of IaC.
- ribadeo 2y agoSensible. Kubernetes is an anti-pattern, along with containerized production applications in general. -replicates OS services poorly -OS is likely running on a hypervisor divvying up hardware resources into VPS's -wastes ram and cpu cycles -forces kubectl onto everything -destroys integrity of kernel networking basic principles -takes advantage of developer ignorance of OS and enhances it I get it, it's a handy hack, for non production services or oneoff installs, but then its basically just a glorified VM