Hacker News Reader

It's a bit more than that; there's a reason the next job cares that Docker, React, or Kubernetes are on your résumé.

If you use Docker, you get to claim that you're familiar with a framework atop a lower-level abstraction, and the lower-level abstraction is flexible to the point of incomprehensibility; few people enjoy maintaining someone else's bespoke shell script environment, and there's not much of a forcing function to cause standards to exist in that abstraction layer for doing a specific task (creating and managing deployable artifacts).

React vs. JS and Kubernetes vs. "Our previous sysadmin's solution built with hair-pulling and rage before they quit to embrace the life of the humble riverboat captain" follow the same pattern. The frameworks and toolchains listed are standards that allow someone who has solved that common business use-case at one organization to solve that use-case at another org with minimal spin-up time (vs. the time to learn bespoke solutions to do the same thing). Many people having the same problem domain to solve is how standards come to exist.

Do you actually think Kubernetes infrastructure is built without hair-pulling and rage?

If so, I've got some stories for you.

Well it's contained the hair-pulling and rage to just the kubernetes administrators instead of the whole organization. :P

No, the rage extends to the developers too. Writing all of the yaml for a full service requires a fair bit of understanding of what's going on in k8s. And helm templating.

It's hair-pulling and rage that results in forward progress on a fungible toolchain (as opposed to hair-pulling and rage that results in a bespoke one-company ecosystem where you leave behind more than half the useful experience you gained when you transfer to a company based upon ecosystem fundamentals utterly different from the ones bought with the blood, sweat, and tears of solving the problem at the first place).

Using managed kubernetes solutions alleviates most of the hair pulling.

Speaking as someone using EKS: No, no it doesn't. The only thing we really handed over to someone else was the challenge of running a control plane. We still have to roll our own node images (for compliance reasons, the default images are insufficiently secure), still have to work directly with AWS to get larger etcd clusters, still have to manage the cluster itself...

The trouble has barely been below the threshold of pain to just run our own control plane.

Out of curiosity, have you considered using ECS instead? If not, why not?

(Disclaimer: I work for AWS as a specialist solutions architect.)

Not that person, but I do a lot of docker at a big enterprise. Sell me.

Drop me a line - eff eye ess see emm eye at amazon dot com :)

Absolutely no it does not. I work with GKE and EKS almost exclusively and it compounds the headaches most of the time.

There is varying support for Kubernetes resources in both and all kinds of vendor-specific ways you need to do things to keep you locked in.

Every single managed Kubernetes solution available is a unique, special snowflake. Most folks in-house ones are the same. Saying that Kubernetes isn't some bespoke solution is a myth.

Kubernetes is a collection of haphazardly-assembled components in varying states of maturity and that landscape changes dramatically with minor release versions (GKE's Stable release branch is still 1.13, for example). YMMV.

Give specific problems you see and I will give you a reasoned reply. I will not engage with hyperbole devoid of facts.

It's help I don't need and didn't ask for. I'm managing several million dollars worth of infrastructure in both.

I gave enough detail that anyone familiar enough with both platforms should know some of the issues I'm talking about already.

You did not.

> There is varying support for Kubernetes resources

I dunno, EKS not having built-in support for Ingress objects is a pretty large and obvious elephant in the room.

I'm not playing this game. I've stated my experiences and suggested the level of interaction I've had with the platforms in dollar figures enough to be comfortable with what I'm saying here.

> I dunno, EKS not having built-in support for Ingress objects is a pretty large and obvious elephant in the room.

Which is actually not a big deal. K8s ingress objects are not very flexible, and most users in my experience tend to use customized solutions (e.g. ambassador) where you use a Network Load Balancer. Ingress objects are fully supported in GKE.

> I'm not playing this game. I've stated my experiences and suggested the level of interaction I've had with the platforms in dollar figures enough to be comfortable with what I'm saying here.

You started playing this "game" by dropping numbers on how many $$s you've managed and asking that other believe you because of that. I was simply asking you to provide specific instances of the pain you're stating you see. The one instance you've provided isn't really that big of a deal.

yeah but for fighting with all the details once upfront you get an infinitely replicable environment.

not just scalability but you can have as much test environments, all identical, spinning up with an apply. and the next guy in line can do it too! possibly with a convenient front-end and little understanding, so you can spend your skills elsewhere

not for everyone, sure, but then which tool is?

I had that with terraform before Kubernetes anyway.

...aren't them from the same age?

Two different paths that can get you to the same place (but usually don't and surely Kubernetes is the cheaper option month-to-month).

they're bot 2014ish, but hacker news and facts aren't a good match, better a long tirade and snarky comments against the grain, I guess.

One was usable in production long before the other. Years even.

Maybe I'm particularly unfortunate, but that wasn't my experience at all. It's either bash scripts that make you want to pull your hair out, or yaml files that make you want to pull your hair out.

The same people who wrote these bash scripts are writing yaml files, and with k8s there are infinitely more interesting ways to bork your jobs.

The problem is, as so often, the system.

If HR goes as low-level in hiring as "React Developer" then people have to play this game.

If HR would hire on something more substantial, it wouldn't matter if you did Linode or AWS, React or Angular, Docker or Bash scripts.

HR having any role more substantial than confirming that an applicant can legally work in the US and isn't lying on their resume is the problem.

In other words, only the parts that they are trained and qualified to do, yes. The parts that a developer team lead or team manager would not be good at. Makes sense.

Hiring people is difficult, exhausting, time-consuming, and largely a crap shoot, since hiring consists of deducing a person's technical abilities with around 1-2 hours of interaction in a very limited scope.

If we could find a better way, we'd be using it. But, as it stands, recruiters and HR have only a few minutes per potential candidate to determine whether or not they meet the hiring manager's criteria. It's unreasonable to expect HR/recruiters to keep abreast of an ever expanding list of technologies and their analogs because that's not their core competency. Unless they are repeatedly told that GCP experience is worth like 70% of AWS experience (replace the values and technologies as you see fit), they aren't going to know that.

The solution seems pretty simple to me: get rid of the HR and recruiters, at least as having much power in deciding who to interview. That's the hiring manager's job. He knows what kind of person he's looking for, so let him make decisions. Why would you let some non-technical person decide who's qualified to be interviews? It makes no sense. At best, have the hiring manager give some very basic things to look for on resumes to the HR person, so they can screen out the people who are obvious wastes of time.

>If we could find a better way, we'd be using it.

It seems to me that the reason it's so bad is because, at many companies, HR people refuse to admit that they're incompetent at hiring technical people, and insist on inserting themselves into the process to a degree which is highly counterproductive. The only thing HR should be doing is helping hiring managers find the people they need, and otherwise staying out of the way. The bulk of the HR person's time should be on other tasks: personnel issues with existing employees, helping new employees get situated, maybe interpersonal issues, etc. The hiring manager can afford to spend an hour a day looking through resumes and giving good ones back to HR to recruit.

This is assuming technical hiring manager, which may often not be so. Also, a team often wants new hires with all the latest buzzword experience as they are too swamped themselves.

Maybe have experienced different approaches, but where I've worked, the hiring manager told HR what skillset they needed and HR would fire over resumes for the team to look at and decide who to bring in. Our team decided 100% who to hire and not.

So, basically what you're talking about already happens at every company I've been involved in hiring at. HR posts the job posting from the manager, forwards resumes that look good. The do perform the initial non-technical interview, but teams handle technical interviews as they see fit. HR is only involved to present the offer.

Because of that, I took the parent comment to say that HR should be better at resume fishing. Meaning, they should understand technological equivalencies better, like MySQL and Oracle are somewhat equivalent or related skills but Bash and Elasticsearch are not. This is what recruiters are supposed to do; obviously most are bad at it, but his is largely because few SWE/SysAdmins/DevOps are going to pivot into recruitment.

It would be cool if the industry let us play "Confident Applicant's Gambit": I will agree to work for you, dubious but reputable employer, for six weeks to prove my mettle.

At the end of the six weeks, we part ways unless I have clearly demonstrated I am in fact, the genuine article, at which point you owe me back pay, and commence my salary which is about 140% of what you would normally pay someone. Quite a bargain for you.

The intention of this being, the employer is not at risk for slave labor, but the applicant is clearly wasting their time if they know they are not genuinely solving a problem the employer has for the given salary.

Just hire temps and maybe extend contract. Already overdone and creates helluva toxic and abusive env.

Unfortunately temp-or-contract-to-hire is automatically the bottom 1/3 of available people. A CHRO thought this was a brilliant solution to the six-month searches those silly people in IT kept complaining about.

Been there, done that, it doesn’t work in practice. We had to unwind nearly all of them after a few weeks, and all the on boarding wasted copious amounts of time for existing staff.

In Germany we have a probation period of 6 months in which both partys can resign at any time, no questions asked.

More concise than other responses:

HR isn't qualified to hire for technical positions, then, and team members should evaluate other potential team members.

I commented elsewhere, but this is how it works at every job I've ever had and interviewed for. And I'm not some "SV ninja coder" either, I'm just a regular Joe working regular jobs. Hiring manager tells HR to post a job, they send over the resumes that they get, and schedule interviews with anyone who looks good.

With my last three jobs, the involvement with HR was limited to initial phone screen, asking about salary and legal status, then onto the hiring manager for the rest.

>> resume building

Exactly. Every developer is always running a build-resume thread in his mind at the background, which drives choices many a times.

But why does it happen?

May be, there's no way for the developer to claim the value driven, and thus these skills end up being the proxy to be showcased!

If a developer's resume mentioned "got a 40% reduction in total operating cost of the supply-management-pipeline by enabling automated operations and reduced errors by 20% over a year, and helped drive sales up by about 30% over two years", this would NEVER get picked up by a recruiter - who would just be skimming the resumes for specific keywords. Worse, it could be an automated tool scanning the resume.

Also, in the general scheme of things, developers are kept off the real value outcomes for a reason - to prevent them from understanding their true value. Cause, it is good for business! :P

All of these combine to cause developers from not understanding the quantum of value being driven by their efforts, and thus to compensate for the lack of this important info - and to compensate for the shortcomings of the industry standard "job-description" templates that bother only about skills-and-number-of-years (as opposed to value-outcomes-driven-over-unit-time) make it harder for developers to really understand (and then showcase these in their resumes).

Also, an old classic on these lines - http://www.bruceblinn.com/parable.html - The parable of two programmers.

"I don't want to seem like a hack, so I'll do enterprisey things, so that nobody can call me a dumb guy" is another thing running in the background.

I’m actually looking for a job and this has come up more than once.

I agree with you for the most part.

Docker isn’t all that difficult to use and I don’t even see why they bother asking. I just laugh and tell them, yeah, I know docker, along with being quite proficient in Linux in general and other deployment technologies. I don’t see the point of asking developers if they know docker. If you can learn to code, you can learn the basics of docker in 15 minutes.

React and frameworks are more specific and I can see why asking about those for developer roles is more appropriate.

AWS is so damn big at this point that I don’t know what they are really asking by just saying “AWS”. Sure, I know about the core AWS stuff, but I’m not proficient in really specific AWS CloudFormation templates or AWS IAM policies and stuff. And I’m not sure most developers outside of devops should be responsible for such a thing. For day-to-day software engineering, I shouldn’t need to touch the servers - that should be handled by a CI process and/or devops persons.

> and the basic reason is that both devs and managers want to pretend they are working at FAANG, so that someday they will work there.

Strongly disagree. The reason they prefer Docker is that nobody wants to read your bash script. They want a standardized set of tools they can familiarize themselves with using curated examples and a large community.

https://rdd.io/