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

The full-time job of keeping up with Kubernetes

gravitational.com

Post reply on HN
Print view View original

141–150 of 237 posts

Re: The full-time job of keeping up with Kubernetes

#141

Post by oblio »

flukus wrote: post #66
enraged_camel wrote: post #25

Earlier quoted context omitted.

Sure, NIH syndrome can be rational for technology that is crucial/central to your system. The problem is it is often used to justify re-inventing even mundane stuff. I once worked with a client who wanted to implement their own bug tracking system. The client’s main product was something totally unrelated.

Bug trackers are one of those areas where a lot of companies should build there own. Everyone has there own workflows and information to capture and end up either conforming their process to the bug tracker or spending more time configuring the bug tracker than they would to build a new system from scratch. Those uber configurable systems always suck to use. Ones like JIRA can takes weeks to setup for your org and in…

Making a serious bug tracker is hundreds, more like thousands of man hours. You’re saying that instead of investing 50 hours into configuring Jira properly, it’s better to do that? Even with intern work, it doesn’t make sense, especially since interns will be gone tomorrow ;)

Re: The full-time job of keeping up with Kubernetes

#142

Post by kev009 »

jacques_chester wrote: post #121
cookiecaper wrote: post #106

Earlier quoted context omitted.

100% the case. k8s is not a terrible thing and there are good uses for it, but the vast majority of people who are using it don't understand what it's doing, and don't understand that their application is not equipped to handle that type of execution model. Just yesterday I had someone tell me "Kubernetes was like magic and it made everything easy". This is absolutely not the thing a serious/honest Kubernetes user wo…

> There is a serious, concerted effort by Google to put k8s at the forefront, and they are not playing games with it. Well no, and why would they? Containerisation is one way to crowbar workloads out of VMs and AWS. Since they're coming from behind, their best strategy is to deny everyone else any oxygen by creating an opensource winner. And it worked: Amazon have added EKS to ECS, Azure added AKS to ACI. Google does…

In general they have been pretty aloof at product marketing and development. Microsoft came in with a weaker product early on and has really been cleaning up with Azure going head to head with Amazon and GCE.

G as a whole has always been pretty much the opposite of Apple in terms of fit and finish, and in the past it was no mongo in terms of dev swoon. But I agree with cookiecaper, they have somehow cracked the code for mongo level of installing meme based software architecture on the masses. I would _love_ to understand how that works, for selfish entrepreneurial reasons :)

Re: The full-time job of keeping up with Kubernetes

#143

Post by toast0 »

reacharavindh wrote: post #16
tw1010 wrote: post #2

There aught to be a name to the tendency that as tools get better and better, the more your time goes from having your mind in technical-space to social and news-space. It's like the authority to create goes from the individual first-principles (by necessity) maker, to the control over development being in the hands of an external group, and then all your time is spent keeping up with what they're doing. A similar th…

I was just thinking the other day about "finished software". These days, those Unix philosophy tools of doing one thing well and leaving small solved problems alone are becoming seemingly fewer and fewer.

I don't necessarily mind relying on unfinished software; but it is tiring to rely on something that doesn't appear to be on the path to being finished. Projects with a complicated upgrade cycle and a rapidly moving upgrade treadmill are definitely a no-go.

Re: The full-time job of keeping up with Kubernetes

#144

Post by gatmne »

smarterclayton wrote: post #123
dralley wrote: post #118

Earlier quoted context omitted.

>"There is no such thing as Kubernetes LTS (and that’s fantastic)" OpenShift?

Technically OpenShift isn’t LTS yet, it’s 1 year and 3 year (the latter is special extended support). Right now we’re planning on 1.9 being our first LTS with the longer support commitment (3yr?). Still being sorted out. We won’t be doing the 10 year support like for RHEL 4/5/6 yet.

As a guy who likes the stability traditional vendors provide as apposed to the madness that is chasing hip upstream developers, the mere fact that your working on providing LTS guarantees gives you a significant advantage over your competitors.

Looking forward to what Openshift will bring to the table!

Re: The full-time job of keeping up with Kubernetes

#145

Post by ehsanu1 »

jstimpfle wrote: post #107
paulryanrogers wrote: post #100

Earlier quoted context omitted.

Could you provide an example of solutions without real problems, game engines or otherwise?

Basically anything overengineered? Concrete example: C++ "manager" objects. Why not finally learn how to structure applications and keep allocations and resource use in check? The program will be so much simpler, compile quickly, be easy to understand (execution threads stop jumping around like crazy), and typically have less memory leaks / use-after-free etc. RAII, garbage collectors and other fancy inventions for f…

How does a "global resource manager" work and in what way is it better than RAII and garbage collectors? Googling wasn't helpful.

Re: The full-time job of keeping up with Kubernetes

#146

Post by gatmne »

shaftoe wrote: post #101
maxxxxx wrote: post #67

Earlier quoted context omitted.

I think a major leap is much easier to handle and to plan for.

I completely disagree. The complexity and risk of a change goes up with the square of the size of the change. Having moved from upgrading when forced to (almost) continuous upgrading, the number of moving parts in any given change is small and the frequency means we become skilled at rolling out changes safely.

That's fine and dandy if you can afford to put up the resources to keep your deployment up to date. For more constrained others, an LTS release can be the deference between using the project vs not.

Re: The full-time job of keeping up with Kubernetes

#148

Post by flukus »

oblio wrote: post #141
flukus wrote: post #66

Earlier quoted context omitted.

Bug trackers are one of those areas where a lot of companies should build there own. Everyone has there own workflows and information to capture and end up either conforming their process to the bug tracker or spending more time configuring the bug tracker than they would to build a new system from scratch. Those uber configurable systems always suck to use. Ones like JIRA can takes weeks to setup for your org and in…

Making a serious bug tracker is hundreds, more like thousands of man hours. You’re saying that instead of investing 50 hours into configuring Jira properly, it’s better to do that? Even with intern work, it doesn’t make sense, especially since interns will be gone tomorrow ;)

I think your either over complicating the requirements or under estimating how long it takes to throw together a system with half a dozen tables and a a dozen views/forms. Or underestimating just how far you can get with such a simple system. Then you've got something tailored to your workflow.

> Even with intern work, it doesn’t make sense, especially since interns will be gone tomorrow ;)

But there will be a new batch sooner or later that can extend and update it.

Re: The full-time job of keeping up with Kubernetes

#149

Post by tyler_larson »

hueving wrote: post #5

This reads like a giant ad for GKE. It emphasizes several times to just use GKE for pretty lame reasons (Google has good SREs and Google started the project). The people that work on upstream k8s in Google (Tim et al) have a pretty limited overlap with the Google Cloud people that run GKE. Upstream k8s is a full time job so they are most certainly not spending their time also writing internal GKE code. I don't have a…

The GKE reference is a lot more relevant than you think, it's just a bit deeper below the surface.

Google's relationship with k8s and GKE and in particular their motivation for creating an open-source orchestration service is well documented and frequently retold, but ironically appears to not be well-understood.

With any sufficiently complex compute solution, you're going to need both a platform and some sort of management. Typically vendors sell you their management service (for which you often pay a recurring fee) by locking you into a proprietary platform. What's more, the management service can be dismal but you'll pay anyway because your app is built on their platform. It happens everywhere, the industry is full of examples, and anyone could see that it was going to hit Cloud sooner rather than later. And the result would be ... bad ... for everyone (customers and providers alike) but the dominant platform.

So Google took an exceptionally gutsy gamble. Google excels at platform management. They invented SRE. They posited that in a level playing field, all else being equal, Google would have the best platform management service, and people would pay for it based on its merits alone.

By making k8s open source, they leveled the playing field. It was by far the best tool for the job, and everybody could have it at no cost; neither money nor burden. So there was no business model or justification for building a lock-in sub-par alternative. The platform became a commodity; nobody could own it.

Which is where we are now, and what this article depicts. You still need a management strategy, k8s doesn't change that. But now everyone's management service has to compete on its own merits. Nobody gets to play the lock-in game.

Google's management service is GKE. It's good, but not because Google started Kubernetes. Rather, Google started Kubernetes because Google has the expertise and experience to make GKE good.

Re: The full-time job of keeping up with Kubernetes

#150

Post by simonebrunozzi »

lkrubner wrote: post #3
tw1010 wrote: post #2

There aught to be a name to the tendency that as tools get better and better, the more your time goes from having your mind in technical-space to social and news-space. It's like the authority to create goes from the individual first-principles (by necessity) maker, to the control over development being in the hands of an external group, and then all your time is spent keeping up with what they're doing. A similar th…

I wish I could give you more upvotes. You are describing a somewhat hidden psychology, which I think provides a rational basis for much of "Not Invented Here" psychology. We tend to think that "Not Invented Here" psychology is irrational, but in fact, the loss of control over possibly crucial technology is an important cost, which makes all of us stop and re-consider whether we really want to use some software develo…

I gave him mine on your behalf :)
Post reply on HN