I am curious - there are markets where usage of managed platforms like AWS is restricted due to data protection laws (no data center on a country's soil) or what if a large client wants an on-premises installation (we have plenty of such clients) - what's the alternative to k8s if you want your solution to be "portable" across providers? From what I understand, our DevOps team leveraged k8s to streamline it using a standardized way to define resources and to scale them, but I'm not an ops guy so maybe I'm missing something.
Kubernetes is a red flag signalling premature optimisation
101–110 of 558 posts
Re: Kubernetes is a red flag signalling premature optimisation
#102Earlier quoted context omitted.
I think the argument was/is not "its a problem we cannot have javascript" but "if we can have javascript everywhere, we only need to hire javascript devs and only need to care about javascript tooling", which is a fair point. That does ignore the fact that an experienced frontend JS dev is not necessarily also a good productive backend JS dev, but at least they know the language basics, can use the same IDE, etc. If…
And isn’t Wasm supposed to (some day) free us from the need to pick JS for the front end?
Unfortunately, that doesn't seem the way WASM is going. It's been 5 years and we still can't access the DOM without going through JS.
Re: Kubernetes is a red flag signalling premature optimisation
#103How does everyone think about Kubernetes on-prem ? Where the requirement is to run an application/services hands-off without any platform team to maintain it etc ? Is Kubernetes also the right platform for that sort of environment ?
Re: Kubernetes is a red flag signalling premature optimisation
#104Earlier quoted context omitted.
The impression I've gotten from some of my co-workers is that in bootcamps and college they only learned one language, remember the time and effort that went into that, and assume learning another language will take the same time and effort. Because they haven't really put effort into a second one, they don't yet realize just how much conceptually transfers between the languages.
While concepts transfer over between languages the language is only 10% of it. The rest of it is the standard library, ecosystem, buildsystem and all kinds of intricacies you have to know about and what not which is specific to the language (ecosystem).
This is an underestimation of how hard it is to learn to program.
Someone learning a first language isn't just learning a new language: they're learning how to program. It's a new profession, a new hobby, a new superpower.
The rest of the stuff (standard library, ecosystem, buildsystem and all kinds of intricacies) is just a mix of trivia and bureaucratic garbage you gotta fill your brain with but will all be replaced in 10 years anyway. Sure it takes time but it's nowhere near as important as actually knowing how to program.
Even changing paradigms (imperative to functional) isn't as hard as learning the first language.
Re: Kubernetes is a red flag signalling premature optimisation
#105At this point I'm pretty much convinced these repeated "Kubernetes is bad for startups" rants are some kind of FUD campaign (probably grass roots from people who've missed the containerisation and declarative infra train). Kubernetes is actually pretty great for the vast majority of use-cases. Sure if you don't have experience with kubernetes leave learning it until after you've hit product-market fit. But rejecting…
could you elaborate on the "ideal" argocd workflow?
let's say devs push to gitlab, which starts a pipeline, tests run, container images get built, then in the last step in the gitops repo a version bump happens and then argocd will pick it up automatically?
(and if one wants to be able to rollback then that's the same workflow just instead of version "bump" the pipeline tags images with the commit hash and at the last step sets the version to the right tag?)
are there any gotchas, best practices? :)
thanks!
Re: Kubernetes is a red flag signalling premature optimisation
#106Doesn't look like the author knows what he is talking about. His point about early stage startup should not use K8S is fine. But the next advice about not using a different language for frontend and backend is wrong. I think the most appropriate advice is to choose a stack which the founding team is most familiar with. If that means RoR then RoR is fine. If it means PHP then PHP is fine too. Another option is to use…
I don't think their advice about not using it in a startup is correct either. You just need to somewhat know what you're doing.
I know of such a case, where a single engineer could leverage the helm chart open source community, and set up a scalable infrastructure, with prometheus, grafana, worker nodes that can scale independently of web service, a CI/CD pipeline that can spin up complete stacks with TLS automated through nginx and cert-manager, do full integration tests, etc.
I found that to be quite impressive, for one person, one year, and would probably be completely impossible if it wasn't for k8s.
Re: Kubernetes is a red flag signalling premature optimisation
#107having repeatable infrastructure from day 1 is great. kubernetes is the simplest way to have that. it's not the only way, but it's provider agnostic, has a lot of well maintained and understood tooling around, and splits clearly artifacts from deployment (i.e. no scripts configuring stuff after startup, everything is packaged and frozen when you build and upload the container image)
> Solve problems as they arise, not in advance.
while this does make sense for supporting varying requirements the lean way, it fails to address the increased costs that rearchitecting a solution mid-lifecycle incurs.
> Do more with less.
goddamn slogan driven blogging. what is the proposed solution? doesn't say. are we supposed to log in every prod/test/dev machine and maintain the deps by hand with yum/apt? write our own chef/puppet scripts? how is that better than docker images running kubernetes? The comparison between solutions is the interesting part.
op never say. guess "works on his pc" is enough for him, we can only assume he envision a battery of mac laptops serving pages from a basement, with devs cautiously tipotoing around network cables to deliver patches via external usb drives
Re: Kubernetes is a red flag signalling premature optimisation
#108My rule to use Kubernetes is only if my containers exceed the extra containers I need to make Kubernetes work, including but not limited to:
- kube-state-metrics
- Coredns
- Prometheus
- Alert manager
- Node Exporter
- Spot instance termination handler
- Karpenter/cluster-autoscaler
- Event Exporter
- Kubernetes Dashboard
- Ingress
- Cert-Manager
- Custom CNI?
- Istio (not always)
- ArgoCD (not always)
Re: Kubernetes is a red flag signalling premature optimisation
#109Earlier quoted context omitted.
A managed cluster is not as much managed as you would think. Still have to configure and install a lot of things yourself.
Of course, managed means you don't take care of say, creating your own X.509 CA and issuing certificates, tending to their expiry, installing Tiller, setting up pod networking etc. etc. All of these much more annoying and harder than `helm update --install`ing some charts to your own cluster.
To be fair installing tiller hasn't been a thing for years. And pretty much everyone using cert-manager and lets encrypt which makes the whole X.509 story pretty much a no brainer.
Re: Kubernetes is a red flag signalling premature optimisation
#110At this point I'm pretty much convinced these repeated "Kubernetes is bad for startups" rants are some kind of FUD campaign (probably grass roots from people who've missed the containerisation and declarative infra train). Kubernetes is actually pretty great for the vast majority of use-cases. Sure if you don't have experience with kubernetes leave learning it until after you've hit product-market fit. But rejecting…
"Containerization and declarative infra" are only a small fraction of what could be done with real network distributed OS's as early as the 1980s and 1990s, and with far lower levels of overall complexity. That "train" has left the station a long time ago, it's going full speed and there are no brakes on it either. Of course you can keep chugging along with clunky K8s and call that a "good default choice". But that's just being complacent about what real progress looks like.