Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Cult of Kubernetes

christine.website

Post reply on HN
Print view View original

301–310 of 338 posts

Re: The Cult of Kubernetes

#301

Post by aprdm »

jeremyjh wrote: post #299
aprdm wrote: post #296

My team maintains a platform that runs in datacenters across four continents, a private cloud. 1000s of VMs We use VMware and have its API hooked up to Ansible as well as Consul and monitoring. We then make Ansible playbooks available for devs to create services which takes around 5 minutes to run. Since it has consul and monitoring hooked in we automatically create entries in DNS and can auto scale. We have services…

It sounds like you've written your own Kubernetes. Congratulations, I guess.

We have to support a lot of non docker workflows in this platform. Some of the services are more than 10 years old.

Re: The Cult of Kubernetes

#302

Post by vonmoltke »

asdfman123 wrote: post #218
vonmoltke wrote: post #110

Earlier quoted context omitted.

They also pay a fraction of what the jobs "hip" companies pay, and often come along with developers Being treated as second-class citizens.

Is that true, or are you inadvertently comparing the cost of living between SF and other major cities? Hip technologies are being used in SV, and they have to pay tons of money just to keep the talent pool large and circulating. Older technologies are used in other cities, and there the market forces aren't so crazy. But a good Java dev can make plenty of money in SV, and a Go developer will make a competitive salary…

I am currently working in NYC (living in NJ), with a total comp that is more than 3X what I was making when I left Dallas. Based on the market there, I would still probably be making 40% of what I do now had I stayed, and the company would not have been as good.

For the record, I have been using a JVM language as my primary work language since early 2012.

Re: The Cult of Kubernetes

#303

Post by honkycat »

cweagans wrote: post #292
dkarl wrote: post #288

Earlier quoted context omitted.

I think the crux of the problem is that everyone encounters the problem Kubernetes solves. As the GP states, Kubernetes gives you "infrastructure as code" so that application infrastructure can be managed in a way similar to application source code (e.g. PRs, blame, code reviews, CI, rollbacks etc). This helps ops people because it allows them to think about infrastructure as abstract resources rather than as a colle…

There are lots of tools that give you "infrastructure as code". Why is Kubernetes special?

What is the point of this question? Why are the other tools special?

Re: The Cult of Kubernetes

#304

Post by honkycat »

Kubernetes is seriously not that complicated and after using deployutil on Google cloud and cloudformation on AWS: it is a great abstraction and a massive improvement over dealing with existing cloud deployment solutions.

Re: The Cult of Kubernetes

#305

Post by cutler »

collyw wrote: post #182
cutler wrote: post #114

Earlier quoted context omitted.

Rails with turbolinks or Django/Laravel + pjax is good enough for most purposes. When Kubrrnetes first appeared it was laughable if you used it for anything less than provisioning a massive fleet of servers. Now it's something you sprinkle on your corn flakes.

Yep. We just started implementing it at my place. I had only just started and wanted to say that it seemed like overkill, but it was under way when I started and bringing that up in my first week didn't seem like a good way to start. Top be fair it has reduced our server costs a bit (after maybe 6 months of developer time). I am unconvinced it will be worth the hassle.

Docker + Kubernetes = the death of YAGNI

Re: The Cult of Kubernetes

#306

Post by cweagans »

honkycat wrote: post #303
cweagans wrote: post #292

Earlier quoted context omitted.

There are lots of tools that give you "infrastructure as code". Why is Kubernetes special?

What is the point of this question? Why are the other tools special?

My point is that if "infrastructure as code" is your sole requirement, Kubernetes doesn't seem like the first choice. Adopting Kubernetes is not a small task, but it seems to be the go-to answer for a lot of the HN crowd.

Don't get me wrong: it's a great tool for some things. But IMO, for 80% of projects it's completely overkill.

Re: The Cult of Kubernetes

#307

Post by jacques_chester »

aprdm wrote: post #296

My team maintains a platform that runs in datacenters across four continents, a private cloud. 1000s of VMs We use VMware and have its API hooked up to Ansible as well as Consul and monitoring. We then make Ansible playbooks available for devs to create services which takes around 5 minutes to run. Since it has consul and monitoring hooked in we automatically create entries in DNS and can auto scale. We have services…

> Would love to know what we're missing.

Having an upstream who isn't you.

Re: The Cult of Kubernetes

#308

Post by mirceal »

q3k wrote: post #277
mirceal wrote: post #255

Earlier quoted context omitted.

yes. i realize, but having a 3rd part manage the control plane for you != you managing the control plane. again, this comes down to delegating the work to someone that does this for a living. You could say you're using k8s at that point but you're definitely not operating a k8s cluster

But is anyone arguing that using k8s => you must be running your own control plane? This seems like a straw man. You're not saying 'running your own k8s makes zero sense', you're saying 'k8s makes zero sense'.

maybe. my experience has been that most people that say they use k8s manage the whole thing. people that use k8s on gcp usually mention gcp.

Re: The Cult of Kubernetes

#310

Post by lone_haxx0r »

lukasLansky wrote: post #29

Kubernetes is our one shot at having the universal vendor-neutral cluster interface. The fact that it's time consuming to do simple things directly against it doesn't surprise me in the same way I'm not surprised that writing todo app directly against POSIX abstraction would be time consuming. It's a great way to learn how these interfaces work though.

> todo app directly against POSIX abstraction

So, a text editor?

Post reply on HN