Thanks, I'll be staying the hell away from this...
The Cult of Kubernetes
161–170 of 338 posts
Re: The Cult of Kubernetes
#162I think devs often make bad decision makers because in some sense tech is often an addiction rather than a pragmatic choice. The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. I try hard to correct for this bias but sometimes struggle with exactly the same thing. There's just something about wanting to…
> The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. To balance this with a counter example from the quieter group of people not "hot for the latest tech": I'm a "dev" and i've never had this problem, however I work for a small company, where everything I make and deploy I also have to maintain in some…
You are in a an excellent position, but beyond a certain size things become difficult to manage in this way.
Re: The Cult of Kubernetes
#163the difference between K8S and something like Swarm - viz far simpler (and nicer for 80% of the deployment usecases out there) is the way that the community was built up.
I really wish Docker had done a better job with engaging the community.
Re: The Cult of Kubernetes
#164Earlier quoted context omitted.
They are probably scared that when they need to change jobs, the next company will require "5 years of Kubernetes experience". So they convince everyone at their current company to jump into a complexity clusterfuck to see how it works "in production" and can put it on their resume. This is how the entire IT industry works today. I am fucking appalled writing config files is a noteworthy skill is 2019. So should you.
K8S is hardly just "writing config files" is it? You've still got to understand a ton of moving parts underneath before you're able to.
K8s is writing config files just like Python is writing Python Syntax.
If you don't understand the underlying mechanism, either with Python or K8s yaml files, you're going to have a very bad time.
Somewhat ironic side note - Asking folks to write K8s config files is exposing too much complexity for some developers I work with. And I kind of get it. Properly setting up a service with changing environment variables, secrets, ingress, API Roles, AWS IAM roles, and horizontal autoscaling can get a bit nuts.
Re: The Cult of Kubernetes
#165I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writ…
Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit.
I do not agree with your assessment of Kubernetes. It is not equivalent to something like WildFly or TomEE. Kubernetes runs/manages application servers (and not just java once), along with a whole host of other things devops things at Scale... Kubernetes is great for setting up a blog, and the 11 other applications the author is trying to run.
Re: The Cult of Kubernetes
#166Kubernetes is for when you need to run thousands of containers on a large cluster and you want to be able to do it both locally (on-prem) and in the cloud. It's for cases where you already have operations staff who can manage it on-prem for you. It's for cases where you have a dozen teams and you want any developer from any team to be able to spin up a fresh instance of software from any other team for dev, testing, etc., all on one pool of shared hardware. It's not for your blog, and it's not for your startup of 10 people where you can just use purely managed services on AWS or Google Cloud.
(That said, there's obviously nothing wrong with using a personal blog as a playground to learn new technologies.)
Re: The Cult of Kubernetes
#167Earlier quoted context omitted.
Where would you draw the dividing line between where you think it does make sense to use something like Kubernetes and where it doesn't?
There isn’t a dividing line per se; every operating model is going to have different breakpoints. In general though, I would consider Kubernetes an “enterprise technology”. If you’re a startup you’re going to be better off paying AWS/Heroku for one of their more managed services than hiring someone to build / manage a Kubernetes cluster.
A note on this - AWS (or any other host's) managed k8s will not reduce the need to understand what's going on under the hood. It's still k8s, you're just not running the daemons to make it work (which is, arguably, the easy part).
Re: The Cult of Kubernetes
#168Earlier quoted context omitted.
Where would you draw the dividing line between where you think it does make sense to use something like Kubernetes and where it doesn't?
You've signed an > 99.9% availability SLA with a customer and a service like Elastic Beanstalk or Heroku isn't sufficient for your needs.
Technically, the cloud in general probably isn't for you, since none of them guarantee more than 3x9's on any of their services.
Re: The Cult of Kubernetes
#169Kubernetes Failure Stories
https://github.com/hjacobs/kubernetes-failure-stories
Re: The Cult of Kubernetes
#170After years of ignoring it, I'm no longer able to fight the cloud urge. What's the best way to learn k8s in 2019?
The other suggestions are great; it boils down to run kubernetes and use it. I like minikube for my local system, but it won't help learn how to run Kubernetes itself.