bvandewalle

I think you hit the nail on the head.

Elected officials unfortunately don't have that much incentive to hire the "cheapest" company as the debt will be incurred over the next 100 years while they will be long gone.

They probably hire the company that they feel will give them the least amount of trouble, which is the easiest to navigate or that will do something for them in exchange. It's the "not my money" issue at play.

if it is an instance on the cloud, GCP and AWS let you define ServiceAccounts that get populated on the Instance at boot time.

you should only let the instance access the secret it requires.

It makes sense at scale. If you are a company of two there are probably better solutions.

At scale, you can very granularly define policies for each secret. When a secret is accessed, it is done so through a user or application identity. Each access is also logged.

If you use Vault, you should use it as an RBAC system as well.

That means that each application got a ServiceAccount (SA) and each user got a username/password. Based on your identity, you get access to specific secrets from Vault.

My issue with serverless though is that you need to refactor your code to make it work specifically for it. If you don't start to think serverless on day one it gets more and more difficult to convert to it down the road.

I'm using Kubernetes extensively in my day to day work and once you get it up and running and learn the different abstraction, it becomes a single API to manage your containers, storage and network ingress needs. Making it easy to take a container and getting it up and running in the cloud with an IP address and a DNS configured in a couple API calls (or defined as YAMLs).

That being said, I will also be the first one to recognize that PLENTY of workloads are not made to run on Kubernetes. Sometimes it is way more efficient to spawn an EC2/GCE instance and run a single docker container on it. It really depends on your use-case.

If I had to run a relatively simple app in prod I would never use Kubernetes to start with. Kubernetes starts to pay itself off once you have a critical mass of services on it.

It feels like this became the life-cycle of Internet.

The same thing happened with decentralized websites and blogs.then everyone got attracted by the managed platforms and now the web is more centralized than ever.

you make the right point. A lot of people see this as youtube censorship, but the podcast was also available in its purest form: through a RSS decentralized feed.

Now it moves to a walled garden with content unavailable to the outside world.

I said this in another post about Grubhub but similarly to this article I really don't get it. Those apps are all 25%+ expensive than ordering take out directly with the restaurant, they screw the restaurants and all those delivery companies lose millions.

Did everyone really become THAT lazy that driving 10 minutes to get your meal is that much trouble?

I don't get those delivery companies (Doordash, Grubhub, etc).

Even with a first-timer promotion, a meal would end up being close to 25% more expensive than ordering directly with the restaurant.

I'm happy to order directly with a local restaurant on the phone, drive 10 minutes (especially now with no traffic) and get my food on my terms. I end up paying way less and the restaurant keeps the full dollar amount. It's a no-brainer win-win situation. I wish more people would order directly with restaurants.

This must be one of the most misunderstood pieces of popular science.

The Coriolis effect is WAY too weak to affect the direction the water is flowing. Typically the way the water moves initially and the shape of the container will have an outsized impact in the final direction.

If you are an engineer those type of stories should make you rethink your usage of Google Chrome. Chrome having so many users empower them to implement those type of nonsensical policies.

As said in other comments it is trivially easy to switch to Firefox (or any other browser you feel that fits your needs better).