This is another case of "I have never encountered and don't deeply understand the problems this tool was built to solve, thus the tool is totally unnecessary and the people who use it are part of a cult". This is the same kind of flawed reasoning you see in the front-end world where a bunch of people complain that they do all their work in jQuery so React must be a cult. Pasting what I wrote in another comment: The g…
The Cult of Kubernetes
251–260 of 338 posts
Re: The Cult of Kubernetes
#252Earlier quoted context omitted.
Oh I get the author’s point, but her use case was “basically a Heroku replacement for easy deployment”. It’s just the wrong use case for Kubernetes and it is well known that deploying to Kubernetes is a bit of a nightmare.
What is the right use case for K8s? And why is "ease of deployment" not something that someone should expect from K8s? I've been sitting on the K8s sidelines for a bit as things iron out, and I've been deploying it on bare metal on a test bed over the last few days with the intention of using it as IaaS for some of my own apps. It seems to be what it's meant to do. Keep my app running on infra following the rules I s…
It is for making things easy to deploy ONTO the K8s cluster, not for making the cluster itself easy to deploy.
The key is only to use it for cases where the deployment of the containers without K8s is more difficult than the deployment of K8s.
Re: The Cult of Kubernetes
#253Earlier quoted context omitted.
It's not difficult if it's your full time job. The learning curve is punishing though if you're trying to learn it from 9-12 AM on Saturday.
So what? It wasn't designed to make it easier for hobbyists to deploy their weekend projects, it's meant to provide ops-engineers with an infrastructure-as-code abstraction for distributed applications.
Everyone here is blaming the truck company instead of the person that bought a flatbed to transport a 2-lb box
Re: The Cult of Kubernetes
#254./deploy_kubernetes.sh The next billion dollar idea.
Re: The Cult of Kubernetes
#255step 1) keeping a service up and running is hard. we have all these issues and it seems like we are struggling to do simple things step 2) only if there was some magic tech that could solve all these issues. and have a cool name. and we could put it on out resumes... drum roll: K8Sssssss step 3) bro. it’s working. i don’t really understand what it’s doing but look at all the containers we are running. and the config.…
You do realize that one of those cloud services you can use is k8s, right? GKE is pretty amazing. They manage the k8s control plane for you, offer worker node scalability and you can use a decent, intent based, automatable API for declarative deployments. No need to mess around with VMs or proprietary lambda/serverless stacks.
Re: The Cult of Kubernetes
#256Earlier quoted context omitted.
Part of the problem is the hiring process (plus attitudes seen on here). Your resume needs to have lots of fashionable buzzwords rather than pragmatic good enough / keep it simple choices. You must keep on learning (lots of things rather than mastering any one thing). I can write a really nice site in standard Django with some JQuery, and it will take me half the time that adding React to it will. But adding React wi…
The real trick is to make your site load so fast people swear it's magic. I use a combination of serving things from ram and https://instant.page to do this with a fairly boring plain old HTML rendering on the server app. I even have a Progressive Web App out of it too.
Re: The Cult of Kubernetes
#257Earlier quoted context omitted.
Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it. Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult…
Or perhaps somebody will evolve Kubernetes itself into becoming simpler? I know that's a pipe dream, but really, why does it have to be? What would have to happen for people to actually work on making existing things simpler and better factored rather than reinventing the wheel? My personal theory is that it's largely because that kind of work simply isn't being valued highly enough. Reinventing the wheel is a much l…
Re: The Cult of Kubernetes
#258Earlier quoted context omitted.
Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it. Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult…
Oh they have and are; but what is the business case open source such a wrapper? Wouldn’t you just host it on your own hardware and basically be another Heroku? This kind of software is complex enough it would take corporate backing (either an industry group or VC backing) so it’s probably not getting built unless there’s a business case. Even Google only released K8s because they thought it would push people towards…
AWS had the most K8S deployments even before they released EKS, according to the CNCF:
https://www.cncf.io/wp-content/uploads/2018/08/cncf_survey_g...
Re: The Cult of Kubernetes
#259Earlier quoted context omitted.
Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it. Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult…
Or perhaps somebody will evolve Kubernetes itself into becoming simpler? I know that's a pipe dream, but really, why does it have to be? What would have to happen for people to actually work on making existing things simpler and better factored rather than reinventing the wheel? My personal theory is that it's largely because that kind of work simply isn't being valued highly enough. Reinventing the wheel is a much l…
Re: The Cult of Kubernetes
#260This is another case of "I have never encountered and don't deeply understand the problems this tool was built to solve, thus the tool is totally unnecessary and the people who use it are part of a cult". This is the same kind of flawed reasoning you see in the front-end world where a bunch of people complain that they do all their work in jQuery so React must be a cult. Pasting what I wrote in another comment: The g…
This is a very true statement. I'm looking at it with a bit of a different view as well: We're currently setup very classically. Ops maintains terraform, VMs, config management. Some developers have taken over some highlevel cluster management via the configuration management. This works very well.
As long as you're pushing 3 applications around. Onboarding an application into a config management solution can easily take 2 - 4 engineering weeks on the ops side. And the work will always be on the ops-side because that's where the required expertise of the configuration management lies, which is a hefty chunk of specialized knowledge. If you're looking at a ramp-up from 3 applications to 5, 8, 20, like in our case, that's ... ugly. In our case, that's actually planned, because we've been bought due to our experience in this context. Yey.
That's a huge investment if you look at time alone, it's like 80 engineering weeks at worst. That's a year of nothing else all of a sudden. A situation like that magnifies the operations team as a bottleneck even worse.
And that's IMO where the orchestration solutions and containers come in. Ops should provide build chains, the orchestration system and the internal consulting to (responsibly) hand off 80% of that work to developers who know their applications.
Orchestration systems like K8, Nomad or Mesos make this much, much easier than classical configuration management solutions. They come with a host of other issues, especially if you have to self-host like we do, no question. Persistence is a bitch, and security the devil. Sure.
But I have an entire engineering year already available to setup the right 20% for my 20 applications, and that will easily scale to another 40 - 100 applications as well with some management and care.
That's why we as the ops-team are actually pushing container orchestrations and possibly self-hosted FaaS at my current place.
Hm, guess that got a bit longer. You hit a nerve somewhat.