rdli

Some more details are covered in Bob Iger’s book The Ride of a Lifetime. It’s obviously about burnishing his legacy but if you’re a fan of Disney or the challenges of being a CEO at scale, it’s pretty good.

I originally watched this on Amazon Prime, but didn’t realize it was now for free on YouTube, which is why I submitted. I suppose I could have put “AlphaGo Documentary on YouTube” or some such ...

(original poster)

This study is based on 2020 data, pre Delta.

Are you pinning your hopes that a false positive like this will be appropriately caught because of an army of faceless, low wage workers who stare at CSAM cases all day will immediately flag?

I worry less about my kids (because I take precautions, similar to you), but I worry about kids whose parents are not as sophisticated.

And this is why I don’t think it’s as black & white. An absolutist, deontological view of the right to privacy is something I absolutely empathize with (although the fourth amendment does not enshrine this anywhere for companies; the bill of rights applies to government action.). I’m just saying there is a utilitarian argument as well for doing something like this.

And the dialogue between technologists who understand what technology can/can’t do vs those who advocate for exploited children —- is what is needed.

You must not have children.

Pretty thoughtful take IMO. It is complicated and there isn’t a clear answer.

I liked Alex’s suggestion though: when it’s a highly complex issue, the best solutions happen when you can bring together the right experts in their field together, and collaborate, and I think it’s a very fair critique of Apple. It’s hard for me to imagine a situation where showing up at the conference, sharing a preview of what they were thinking, and then hearing the feedback would not have been beneficial.

(Speaking as a reasonably happy Apple user, I wish openness for some of these things was a little bit more of their DNA. When you’re as big as Apple, people need to just recognize that the standards are different. It may not be fair. But it’s just the way the world works.)

Excited to share this; we've been working on this for awhile now. I'm happiest about how the developer UI turned out -- you just add k8s annotations to your existing service, and we pick it up. So really the Service Catalog is a visualization of your data. I never really liked systems that lock you into "their" way of doing things, but since we only support Kubernetes, we just try to be as idiomatic as possible.

Assuming you’re a company (as opposed to an individual), if you want a PAAS, there are a few different options that in my view are sustainable which I think is the key criteria for adopting something for your platform.

- Heroku. Sure it’s a bit expensive but it’s still super easy if you’re a dev. - OpenShift. If you’re a really big enterprise, OpenShift is a reasonable choice for PAAS. But only if you’re huge. - Kubernetes. Yes, it’s complicated. Yes, it has a steep learning curve. But it’s open source, has a huge and growing ecosystem, and it has less lock in than any other PAAS-like thing that I can think of.

The main downside of Kubernetes beyond its complexity is that you still have to build abstractions on top of it for your developers. But that world is improving regularly.

This was an odd page to read. On one hand, it assumes some level of sophistication (what’s a 409A?). On the other, it leaves out some really big things that you care about with early exercise (e.g., QSBS).

Regarding the thread on liquidation preference, I don’t think any amount of liquidation preference is on standard VC terms in this market.

I think you’re saying there are good cultures and bad cultures, which is a statement I find impossible to disagree with.

Exactly. Great cultures are different and not everyone is a great fit for every culture. That’s OK!

There are people who are very happy at a well-run BigCo, with a well-defined cadence for making decisions. Others chafe at that level of process, and instead thrive at an entrepreneurial startup. (This of course is a gross generalization.)

A culture that has generic values is in some ways meaningless.

Masamoto VG chef’s knife

We ended up buying an organic mattress online (e.g., Avocado, My Green Mattress). It’s made a huge difference.

I generally agree, and would add though that the Service API work that is forming the basis of ingress v2 will help a lot here as well.

(I do think that xDS is a non trivial interface to learn and standardize on though and is probably overkill for most.)

Have you tried Ambassador? Built on Envoy Proxy. We have submitted as well to the CNCF as an official project too. (Disclosure: I work on Ambassador).

Really great post. I'm glad the post in particular mentioned community, because I think in the end this is the huge advantage Envoy has over NGINX. NGINX, could, in theory, resolve all technical issues raised in the post. But the fundamental tension between the open source and commercial versions cannot be resolved.

(Disclosure: We use Envoy as part of Ambassador, and so of course we're big fans!)

It's a bad outage, it seems. 16+ hours now, and counting, and they don't seem to have a root cause or a hot standby.

We just cut over all of our stuff (Ambassador API Gateway) to Docker Hub. Lots of the Kubernetes ecosystem is on Quay. I wonder how this affecting others. Our users are definitely affected, as well as our development team.

Every executive in a company at a minimum should have a general understanding of other functions. If the CTO knows what selling looks like, then the CTO can better assist the sales team. Likewise, if the sales team understands how software engineering works (at a very high level), they'll generally understand that "getting a very complicated feature RIGHT NOW for one deal" is ... not realistic.

etc.

Istio does have an ingress gateway. Again, if you’re doing basic routing it’s more-or-less the same as any other ingress (that’s what a standard is for). That being said — Istio is focused more on traffic inside the data center (“east-west”) vs getting data into the data center (“north-south”). And these really are distinct problems, e.g., you don’t need to worry about stuff like PROXY protocol, redirect-to-HTTPS, openID Connect, etc inside the data center. But you definitely need to worry about this at the edge.

Thanks! Always nice to hear :).

Maybe https://blog.getambassador.io/kubernetes-ingress-nodeport-lo...

Ingress controllers are quite confusing. Here's the general summary:

- General best practice for Kubernetes clusters is to have a proxy that routes external traffic to internal services

- This is because Kubernetes provides its own internal network space so each of your internal services aren't directly exposed externally (although you can do this if you like)

- Kubernetes has a spec for how this is done, the "ingress" spec

- An ingress controller implements the ingress spec

- The ingress spec is pretty limited in functionality (basic routing, no support for timeouts, as an example)

So if you just need to do basic routing, any ingress controller is going to do the same thing, more or less.

If you want to do more than that (which is very likely), then you'll want to compare the ingress controllers beyond basic ingress. That's where NGINX vs Envoy Proxy vs Traefik etc come into play as your core data plane proxy, and then how much stuff comes on top of it.

Hope that helps.

(Disclosure: I work on Ambassador, one of the Envoy-based ingress controllers)

Edited: formatting

I would suggest you first think about what you want (financial, recognition, etc.) and then have a conversation with the company about it. As you point out, the company has an incentive to keep you happy! So, start with a discussion here.

I personally believe that going to a lawyer at this stage is 1) expensive and 2) unnecessarily confrontational. I understand the argument about understanding your legal options, but at the point where you start to rely on the law, you're entering a contentious negotiation which can be unpleasant and expensive for everyone.

So I'd just say "Hey, Employer, I've put in a lot of my personal time into this project. So I think it's fair that if you want it that I should be recognized in a concrete tangible way since clearly you want it because it adds more value to the business."

And I think depending on the kind of company you work for, I'd ask for additional equity in the company (since you'd be making the company more valuable) plus additional cash (because you were working on this project night-and-day) and some sort of recognition would all be reasonable asks.

Envoy, the L7 proxy on which Ambassador is based, is written in C++.

Thanks! Drop me a line (email in my profile) and would love to chat.

I updated the article to clarify that there were 8 configuration options at the time of testing (we started this effort awhile ago) and now there are 25.

We'd definitely like to rerun the tests with the official controller to use the Runtime API.

This is a good point. I think an interesting test would be to add multiple services, and see if scaling up/down a single service affects latency to other services.

I suspect it's because of reloads:

https://kubernetes.github.io/ingress-nginx/how-it-works/#whe...

The NGINX ingress controller goes to some lengths to avoid reloads because it recognizes the hit from reloads. In Ambassador-land, we use Envoy's xDS APIs to avoid this problem. Not clear what the HAProxy ingress controller does.

(one of the authors here)

Thanks for the feedback.

So regarding your hypothesis on the spikes being sent to pods that no longer exist/are starting: 1) it is the responsibility of the ingress controller on K8S to properly handle that situation 2) it would be highly unlikely for people to implement their own custom ingress controller around a given proxy (it's actually somewhat complicated) and 3) the pod theory wouldn't address the latency spikes seen on reconfiguration.

But you're right that there probably should be some explanation around why we think this is happening (I just didn't want to speculate too much; I suspect that the issue is with the hitless reloads implementation in the proxies which is tricky to do well).

The spikes aren't single requests (at 1000 RPS, the spikes are well over a second long and you see hundreds of requests that spike). As for the reason, we suspect that the different config reload mechanisms in the respective proxies is what triggers the spikes.

(disclaimer: one of the authors)