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

191–200 of 237 posts

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

#191

Post by jstimpfle »

spotman wrote: post #189
jstimpfle wrote: post #173

Earlier quoted context omitted.

Well, the framework I was to use last (Qt) had bugs that simply can't be fixed by users (memory leaks, double free leading to segfault when exiting after reloading QML engine) and immature modules (for example translation) and forces complicated types to the user and forces bad architectural decisions to the user and significantly increases compile times... > using a tried and tested framework is likely to give you h…

Writing your own QT sounds like a long road however that would likely not be as fast as making work arounds or providing bug reports or patches.

I would never write my own Qt. Why would I? In this case I was creating a simple dashboard type application, and that can be easily done using fewer dependencies.

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

#192

Post by jacques_chester »

kev009 wrote: post #142
jacques_chester wrote: post #121

Earlier quoted context omitted.

> 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…

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 and the first plausible alternative revenue stream they've ever found. I don't think they are going to stop elbowing their way into this, and neither are Microsoft.

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

#193

Post by jacques_chester »

bonesss wrote: post #152
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…

You've given an insightful assessment of the orchestration space -- a modular DIY treadmill nightmare... Currently it seems Kubernetes is emerging from the fog as a de-facto standard to eliminate all those uncertainty points and provide a common toolset. It's the only orchestration platform that's a turnkey installtion and a turnkey managed service on all 3 major clouds. VMWare is about to open k8s up to the Enterpri…

> btw VMWare employees: your PKS blog and cloud blog say this is happening mid december 2017... status update, maybe?...

I'm at Pivotal, we're working on it with VMware and Google. If you want to kick some of the tires, start playing with CFCR, because that's a major piece of PKS.

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

#194

Post by jacques_chester »

gouggoug wrote: post #124
cookiecaper wrote: post #104

Earlier quoted context omitted.

> I don't think your comment applies at all to Kubernetes. It does. I've deployed and maintained our company's infrastructure on Kubernetes for over a year now. > K8s came as a savior to all my issues: I burned all my old ansible scripts and rewrote all my infrastructure in k8s. This doesn't make any sense. Ansible scripts out changes to make to a system. Kubernetes deals only with opaque images and does not change t…

> Ansible scripts out changes to make to a system. Kubernetes deals only with opaque images and does not change them at all, it simply runs them. You are exactly right. Ansible makes the best effort possible to bring your system to a given state (the state you coded in Ansible). All those tools (puppet/salt/ansible) do this exact same thing, and they all manage to do it more or less well. However, the keyword here is…

> However, the keyword here is "best effort". That is, it is in practice really hard to consistently bring a system from a random state to a given state X, because of the randomness of your starting state.

This is the logic that BOSH follows. Why try to converge to a desired state if you can just recreate it from a known-good state?

Why do you care about grooming individual servers when your goal is a distributed system?

Configuration management tools make the classical sysadmin's life much easier. "I have a small group of giant expensive machines to run". The constant struggle of impinging chaos on the systems that Must Not Stop Ever.

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

#195

Post by Xylakant »

jstimpfle wrote: post #162
onion2k wrote: post #151

Earlier quoted context omitted.

Time spent not doing our own designs (and instead spent memorizing how to use magical frameworks) is time not spent advancing our technical understanding. That's a false dichotomy. The time it takes to "memorize a magical framework" is far less than the time it'd take to learn how to write code to do what the framework does. Consequently you can learn a framework and some other technical understanding in the same tim…

These are still claims without any context. It mostly depends on how experienced the programmer is. And most importantly, note that one never needs all the functionality from a framework. Typically it's only a very small part, and often the existing functionality in the framework does not match the requirements 100%.

Very often the match is good enough that it pays off to slightly align the requirements instead of patching the framework. The amount by of man-hours poured into the very core parts of rails for example, just processing and dispatching requests, safely decoding the input from a webserver to a useful set of parameters, routing the request to the proper handler and rendering and returning the response is huge. Certainly, you could take something slightly more modular, such as padrino, but that’s still a mind-melting amount of code if you look at all the libraries and dependencies.

You could reimplement most of the basics, but that would be month or years of work and probably still buggy as hell. I’ve seen my share of “oh, we’ll just build our own framework” and they all turned out to be much more complex than the initiatiator expected.

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

#196

Post by oblio »

collyw wrote: post #170
oblio wrote: post #141

Earlier quoted context omitted.

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 ;)

Most places only need a fraction of the functionality of Jira.

Most developers underestimate the complexity of any project :)

Especially one that becomes a crucial component of a company's workflow (as is the case for bug trackers in any properly run software company).

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

#197

Post by caniszczyk »

yeukhon wrote: post #102

Kubernetes’ governance is becoming like Openstack and (I know this is controversial), I hate Openstack, especially because it tried so hard to be “AWS” compatible, and APIs are so awkward to use. Cloudfoundry is better in terms of governance and project’s direction. Many of the main developers work full time at Pivtoal. But it is hard to run your own CF without significant investment like access management and “painl…

Kuberentes/CNCF governance is completely different than Openstack. There's a reason every major cloud provider is involved in CNCF versus Openstack. You can see all stats for CNCF projects here, i.e., https://k8s.devstats.cncf.io/dashboard/db/contributing-compa...

CFF was setup in a completely different way, giving Pivotal a lot of control in the beginning by allowing related entities to have votes and than relinquishing that over time. It leads to a more single vendor controlled ecosystem IMHO.

There's pros and cons to both approaches.

Disclosure: I help run CNCF.

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

#198

Post by Klathmon »

jstimpfle wrote: post #180
robocat wrote: post #178

Earlier quoted context omitted.

It is not a crazy feature. It is a necessary feature for many development environments originally written for Unix (e.g. nodejs), because Unix file systems usually don't have such a low character limit. Or maybe Windows has mounted or network sharing, a Unix filesystem... In which case your program better deal with long paths (or just fail?) Really... You are showing exactly why one uses a library so one doesn't need…

> Or maybe Windows has mounted or network sharing, a Unix filesystem... In which case your program better deal with long paths (or just fail?) 260 bytes is long. I've never seen a \\?\ path in the wild, and I don't want to. It's a misdesign (well, I'm sure the designer didn't want to design it...). But I'm repeating myself... I can't practically deal with paths longer than, say, 64 characters (can't read them, let al…

That is such an awful toxic viewpoint to take.

"Fix my paths"!? Fix your software! I work from a network share that is about 70 chars long to get to my one project's folder. The beauty of hierarchical file systems is that I can cognitively ignore all the previous paths and just work from there. However when your software doesn't work because "the solution is a misdesign", it's not my path that is wrong, it's your software that is broken and you that are stubbornly refusing to use solutions to well known problems.

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

#199

Post by notyourday »

robocat wrote: post #116
jstimpfle wrote: post #23

Earlier quoted context omitted.

And it's not only that - Time spent not doing our own designs (and instead spent memorizing how to use magical frameworks) is time not spent advancing our technical understanding. It's a sad state when otherwise very intelligent people think it's bad practice to use plain C and a clean OS API that has been stable for decades (because that was somehow "magic" und impossible to understand and error-prone), and advise y…

Concatenating two paths is difficult if you care about any of the following: security, multiple OS's, Unicode (multiple code units, validity, combining characters), file system restrictions, etc. Your "two decades" maybe holds for Linux, but what about Windows or MacOS???! I have seen too many people use string concatenation. I think an intelligent person would recommend to use the normal library (appropriate for you…

> Your "two decades" maybe holds for Linux, but what about Windows or MacOS???!

Is my target application going to run on Linux? If so, then I do not care about Windows or MacOS, just like I do not care about CBM64 or Amiga.

My goal is not to write an awesome system that wins design awards in handling of obscure edge cases thrown at it in a coffee shop by hipster developers. My goal is to build a system that solves my business problem.

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

#200

Post by bpicolo »

kuschku wrote: post #158
jweir wrote: post #75

Earlier quoted context omitted.

I disagree on Go. Go is well designed and takes upgrading into consideration. Upgrades very rarely break anything. You should just be able to recompile that 1.3 code on 1.8, etc.

On the other hand, dependency management in go in any sane way is such a byzantine task that it takes ages to get working, and even then it still doesn't. Given an empty set of environment variables, setting up a new go project with dependencies and all in a way that people cloning it later on can also use the dependencies in a single command, without vendoring dependencies, without building custom scripts, is imposs…

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

Post reply on HN