cfors

Good points in here. The one thing about Kubernetes that I think teams need to be wary of is that upgrading needs to be treated as a first class citizen. In order to use the awesome tooling that so many people are building in Kubernetes (see basically all of the CNCF projects), the cluster API needs to be kept up to date. Once you start falling behind, you run the risks of being stuck in a version compatibility nightmare.

Other than that, I can't imagine not running non-stateful applications on something other than Kubernetes anymore.

Pipe to jq is the best. Other than that you can always furiously search stack overflow for some arcane sed/awk/grep-fu.

There is also the -w option to format. Sometimes I’ll write a small python script to pipe output into for wrangling data.

I love these sorts of write ups. I wish there was a way to encourage internal transparency like this, as opposed to my least favorite way to be greeted when I let someone know about an issue with their product: "Can you try again?"

Nothing as infuriating as that, it could be a valuable learning lesson for many people just like this!

For sure putting another complex system in front of any sort of traffic routing increases the failure modes, but the article makes a nod towards "signal quality" as the metric for traffic shifting.

> Failure probabilities were obtained by checking the signal quality of every link every 15 minutes. If the signal quality ever dipped below a receiving threshold, they considered that a link failure.

If the signal quality could be a higher level construct (Layer 7 errors), this could route around bad config pushes if they are constrained. I'm not going to pretend that this is definitely feasible, but at least that was my first thought.

Your site is down, FYI.

> Error establishing a database connection

The gist of the article is that setting up software to build/run/deploy is difficult. And it absolutely is.

Nobody wants to play version whack-a-mole trying to set up a project. I am not a Node guy at all, and the other day at work I had to make a few changes to an internal UI, all which required a working npm environment. Sure, no problem. Except that I had to try 3 different versions of node to avoid a cryptic error message, due to I think fsevent (which isn't even required for running the project, just building it) just to get npm install to work.

Docker has great benefits in that it really forces a developer to encapsulate all of its dependencies in one place.

There is definitely a large amount of binary bloat with this, which is unfortunate but I suppose we are back to the static vs dynamic linking argument on that.

What you are describing is a virtualenv and a requirements.txt file. There are tons of other options for Python that do the same thing.

Attacker had access to the account. It is in the complaint posted by user iancarroll.

They should not be letting egress traffic through to a Tor node.

Well, the main cloud Capital One uses is Amazon as far as I know.

If you think about the attack vectors here, it was most definitely the virtual server that got attacked. If it was the cloud provider (Amazon), there are a lot of safeguards that these banks use to make sure that any data that touches the shared server persistent storage is encrypted. And when I say safeguards, I mean automation to make sure that this sort of scenario shouldn't ever happen.

This is a huge blow for the public cloud and financial services companies, unfortunately.

Edit: Seemingly a WAF firewall issue. I wonder what happened. These rules should be applied automatically for Capital One using Cloud Custodian [0], so a config issue definitely occurred somewhere.

Final edit: A leaked account with access to IAM permissions. Good lord was occam's razor correct here.

[0] https://github.com/cloud-custodian/cloud-custodian

> Therefore, they all support putting migrants in cages.

This is incredibly dangerous thinking. I don’t want to get involved in politics but I would hope a discussion on hacker news would hold higher standards than blanket statements like that.

You're right, it absolutely would work! I was just making a point that it might not be worth the effort to learn Kubernetes for that use case.

Yes, Kubernetes is a surefire way to shoot yourself in the foot. To be able to use it effectively, you essentially need a dedicated team that knows the ins and outs of a rather complex API as well as deep networking, Linux and distributed system knowledge.

However this article takes a bunch of pot shots at Kubernetes that I don't necessarily think are correct. First off, not everyone needs Kubernetes [0].

Second, migrating a company with as much software as Google off of Borg is not a trivial process. They even failed before by trying to create its supposed successor, Omega.

Third, the argument about "open-sourceable" is a strawman argument that doesn't make sense.

As for the attack on container security, I don't understand the argument that was necessarily made there but at this point I'm not sure it deserved a rebuttal because all software is inherently insecure.

> You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

- Theo De Raadt (NetBSD founder)

At the end of the day, yes Kubernetes is complicated but it is not for a company running 25 VPS servers. It's for companies to replace legacy, expensive datacenter virtualization they have paid a lot of money in licensing fees for.

[0] https://blog.jessfraz.com/post/you-might-not-need-k8s/

This is actually a much more responsible way to go about it than the event-stream issue, since it is being done in a public forum (Github issues). Event-stream was given away over an Email without an announcement [0].

Of course, the risks are still there for malicious takeover, but I think will be minimized due to the owner's notoriety and the amount of press this has already seen just on GitHub. I am pretty sure the maintainers of Pip will be keeping an eye on this over the next few months in case of intervening.

[0] https://github.com/dominictarr/event-stream/issues/116#issue...

I would love to see that article. That isn't surprising in the slightest to me.

Just a quick nitpick. A bad config more often than not in my experience is opening up a code path that is riddled with bad code, whether it was not vetted with the proper testing or the wrong environment.

But to your point, I think most people would agree that configuration changes are almost never reviewed with the granularity of a code change. Yes, we may do our due diligence with an approved PR and vetting the configuration and testing the change before deploying it. But, reviewing a PR with a bad config change in json or yaml doesn't necessarily tell you about the code paths that it will open up which makes it much harder to reason about the consequences that a potential bad config push would do.

We should always be reflecting about how adding knobs (configuration) to our programs greatly increases the complexity of the service.

Maybe I am caught up in the "not familiar is hard" look of it and will come around. You are most likely correct :)

This will be legal with the proposed `try` statement [0]:

  info := try(try(os.Open(file)).Stat())

I'm worried about nested versions of this and having to unpack them when reading code, which at the current moment has a much easier imperative block structure.

[0] https://github.com/golang/proposal/blob/master/design/32437-...

I wonder what happened with that poor regex expression.

My thoughts are immediately shifting to one of my favorite articles of all time "Regular Expression Matching can be Simple and Fast..." [0]

[0] https://swtch.com/~rsc/regexp/regexp1.html

Not exactly, I'm pretty sure Bill Gates is a nonprofit. However, there's a book called "No Such Thing as a Free Gift" about the social costs of letting our .00001% be the welfare providers for society. Pretty good if you're interested.