stekern

I think the larger issue is how Kubernetes often is implemented in organizations - as part of internal developer platforms owned by central teams which on purpose or by accident can end up dictating how development teams should work. I think it's easy for such central teams to fall into the trap of trying to build smart, custom abstractions on top of Kubernetes to simplify things, but over time I believe these types of abstractions run a high risk of slowing down the rest of the org (good abstractions are really hard to come by!) and creating fuzzy responsibility boundaries between central and development teams. As an example, this can affect an organizational structure by (re-)introducing functional silos between development and operations. Can a development team really be fully responsible for what they build if they rely on high-level, custom abstractions that only someone else in the org really understands?

Furthermore, if everything in an org is containerized and runs on Kubernetes, it's really easy to have a strong bias towards containerized workloads, which in turn can affect the kind of systems you build and their architecture.

(Author here)

The main focus of the post is to highlight some of the long-term risks and consequences of standardizing around Kubernetes in an org. If you've done a proper evaluation, and still think Kubernetes makes sense for you, then it's probably a sound decision. But I think many skip the evaluation step or do it hastily. The post is more targeted towards organizations with at least a handful of employees. What works for an indy dev does not necessarily scale and work for SMBs or larger orgs - those are very different contexts.

> The article suggests just using EC2 instead of K8s

Not quite. I suggest strongly considering using managed services when it makes sense for your organization. The equivalent of k8s in terms of managed services would be Amazon Elastic Container Service (ECS) as the control plane, perhaps with AWS Fargate as the compute runtime.

(I wouldn't really call EC2 a managed service - it's more in the territory of Infrastructure as a Service)

Not OP, but I'm using NextDNS -- the managed version of a PiHole. I have uBlock Origin and uMatrix in all my desktop browsers, and I'm seeing around 15% blocked queries on NextDNS. Most of the blocked traffic seem to come from my mobile devices.

> Soltani says he rarely recommends steps such as using ad blockers or VPNs for most people. They require too much attention and persistence to deliver on privacy, and even then they are limited in their effectiveness.

Decent article, but a bit light on easy-to-use, practical details. They seem to make the case that ad-blockers are ineffective and too much of a hassle, but that's not my experience at all. I agree that tracking and privacy is a cat-and-mouse game, but I think ad-blocking currently is one of the easiest and most effective ways to block trackers. I installed uBlock Origin on my family's computers a couple of years back, and it has Just Worked™.

The next logical step would probably be PiHole or NextDNS for deeper blocking than some browser ad-blockers, as well as for blocking outside of a browser. I have DoT set up on my router and most off my portable devices, and there haven't been any hiccups yet.

All bets are off once tracking is implemented server-side though. The way GDPR currently has been enforced has led to a lot of bad practices by the tech industry, so we'll probably need new laws that regulate data gathering.