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

211–220 of 237 posts

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

#211

Post by jstimpfle »

Klathmon wrote: post #210
jstimpfle wrote: post #209

Earlier quoted context omitted.

No strawmans in the slightest. Exactly the same kind of very real (and not really solveable) "problems". It's beyond me how far removed from reality these arguments are. You have insanely long paths, and that's still miles away from a reasonable limit (256 bytes), and they could easily be fixed (which would be a win on all non-technical fronts as well), but still you're complaining for no good reason. You clearly lac…

But this is solvable! You are the one claiming it's too complex then refusing to use the well tested solutions... >You have insanely long paths, and that's still miles away from a reasonable limit (256 bytes) but still complaining. Because that's just the path to a folder, that still doesn't contain any data! unpack an archive from a server in one, and suddenly poorly written software is blowing up because someone us…

> I'd love to see how you determined that from a few comments about file paths...

It's easy to see from the discussion. If you had ever thought about designing a filesystem or binary network protocol or kernel filesystem API or a C software architecture, you would not be so invested and instead turn to real problems.

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

#212

Post by [deleted] »

sethammons wrote: post #207
bpicolo wrote: post #200

Earlier quoted context omitted.

It's impossible with first party tools, but I've had a great experience with Glide. That said, go drives me up a wall. Using interface{} to muck with JSON and typecast every step of the way is just my nightmare. It's inelegant in every way

Type cast every step of the way? Methinks you are either doing something wrong or dealing with unstructured json.

[deleted]

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

#213

Post by peterwwillis »

jacques_chester wrote: post #192
kev009 wrote: post #142

Earlier quoted context omitted.

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…

I agree that Google is coming from behind in enterprise sales. AWS have the long headstart and Microsoft have an existing, massive sales org. Cloud computing fits almost none of their DNA. It requires intensive sales rather than automation. It's a volume business with thin margins (rather than a network-effect business with fat margins). But it's also a business in which they have the best technology out of the three…

The difference is, Google is the only company that is both trying to sell cloud services, and giving their product away to their competitors.

The company I work for uses multiple cloud providers, but does not use GCE. They don't even think about it. I think the reason is a lack of confidence, along with other business and technical reasons. Google just isn't a serious company when it comes to supporting large businesses. Like it or not, that old adage about never getting fired for buying IBM is still true.

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

#214

Post by justicezyx »

etaioinshrdlu wrote: post #179
justicezyx wrote: post #94

Earlier quoted context omitted.

K8s is different though. It's an incarnation of a highly-effective & efficient infrastructure paradigm, verified in over a decade long serving of entire google's compute tasks. It's not really new. Disclaimer: I work in Google's compute infrastructure team.

There is clearly a lot of unfinished tooling and features, as evidenced by the extremely high commit rate. Compare that to an old piece of infrastructure like "mount" or "chroot". Is it too much to ask for base infrastructure to be boring? Granted, I have nothing against the Kubernetes project and it might be fantastic. I don't think it's wise to encourage people to use/learn it at this point, at least for production…

Everything is anything to certain degree.

As a core compute system, k8s is more sufficient to be a candidate for everyone to learn than any thing in the same category on earth.

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

#216

Post by lev99 »

bpicolo wrote: post #201
gouggoug wrote: post #40

Earlier quoted context omitted.

I don't think your comment applies at all to Kubernetes. K8s truly simplifies dev-ops and even the smallest team and website can greatly benefit from it. I speak from 7 years of experience managing my company's infrastructure's website: Before kubernetes, I ran my company's stack on very cheap bare metal from OVH. It was great while it lasted, but as the company grew and my team grew, it's become harder and harder to…

> even the smallest team and website can greatly benefit from it I don't think that's true. You have to be at least large enough to justify reasonable investment in microservices.

True, but the investment pays off at about the 4th executable running.

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

#217

Post by hueving »

crb wrote: post #88
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 people that work on upstream k8s in Google (Tim et al) have a pretty limited overlap with the Google Cloud people that run GKE. I happen to be in the building so I sat in on an engineering review for a proposed new GKE feature today. Tim was there, as was Brian Grant, and pretty much everyone else you've heard of (in the room or on the VC). There were also a good number of PMs, SREs, and the leads/engineers wor…

Engineering review is not the same thing as reviewing and writing code. I've seen countless projects with sound designs riddled with implementation bugs due to people not fully understanding the intent of certain systems.

Sitting in a room during a high level engineering review falls squarely under "limited overlap".

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

#218

Post by bpicolo »

sethammons wrote: post #207
bpicolo wrote: post #200

Earlier quoted context omitted.

It's impossible with first party tools, but I've had a great experience with Glide. That said, go drives me up a wall. Using interface{} to muck with JSON and typecast every step of the way is just my nightmare. It's inelegant in every way

Type cast every step of the way? Methinks you are either doing something wrong or dealing with unstructured json.

The pain of dealing with unstructured json/mapping types is exactly what I'm referring to. :)

That said, I don't think the language as a whole lends itself towards elegance - that's pretty much the opposite of their goals. I don't agree that their model for simplicity is the only (or best) model for simplicity is all.

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

#219

Post by hueving »

tyler_larson wrote: post #149
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 man…

>They invented SRE.

Let's not get dramatic and drink too much of the kool-aid. SREs existed well before Google albeit under a different name.

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

#220

Post by StillBored »

dozzie wrote: post #187
sedachv wrote: post #115

Earlier quoted context omitted.

> until you eventually hire a sadist/devops guy. I try to drop in and follow the devops scene from time to time; after all, a lot of my work ends up getting handled by this stuff, and sometimes you need to fix things yourself. From my point of view, listening to a devops talk is listening to a long monologue consisting of a chain of mostly food-related, seemingly unconnected English words ("Chef Cucumber Puppet Jenki…

> From an outsider's perspective it feels that, aside from Nix, there has not been any theoretic or standards progress in this field since Mark Burgess' time. Because there wasn't much progress indeed. IT operations is a field advanced by programmers, and most programmers have very little experience with (or even interest in) system administration, so the progress of the field is mainly governed by clueless outsiders…

The thing that kills me is the preconcevied we have to use $TOOL behaviors. Lets use docker as a deployment tool, where we are putting one container on each VM... Combined with the complete ignorance of packaging. 99% of the problems I hear people trying to solve with docker would be better solved with a 'postinstall' hook in a package called 'my_configuration' (it helps you with configuration versioning and in place upgrades!!!!). Combined with the complete lack of understanding what something like kickstart/autoYast can do.

It seems that in a huge number of cases, its possible to trim out the vast majority of the layers of deployment/etc crap with just a bit of KISS and using tools which are already installed...

Post reply on HN