sass_muffin

You can also never guarantee the patched software doesn't include a worse vulnerability, I would submit that patching software without proper time to validate changes is also a security issue.

If you aren't careful, that is how you get this security theater.

Are they going to call it G-Wiz?

I do realize you were intending to give examples of why you don't think annotations aren't very extensible, but it is an odd example as all those things can still be achieved via annotation, since the annotations can accept values loaded from env specific properties.

"Simplicity is the most difficult of all concepts" -Brian Herbert

It is actually the opposite, it is currently considered a good practice to run stateful workloads outside of kubernetes and stateless workloads inside of kubernetes.

I find it funny how sometimes there are two sides to the same coin, and articles like these rarely talk about engineering tradeoffs. Just one solution good, other solution bad. I think it is a mistake for a technical discussion to not talk in terms of tradeoffs.

Obviously it makes sense to not use complex tech when simple tech works, especially at companies with a lower traffic volume. That is just practical engineering.

The inverse, however, can also be true. At super high volumes you run into issues really quickly. Just got off a 3 hour site-wide outage due to the database unable to keep up with the unprecedented queue load, and the db system basically ground to a halt. The proposed solution is actually to move off of a dedicated db queue for SQS.

This was a system running that has run well for about 10 years. Granted there was an unprecedented queue volume for this system, but sometimes a scaling ceiling is hit, and it is hit faster than you might expect from all these comments saying to always use a db always, even with all the proper indexing and optimizations.

Same, we use EKS and a very similar setup, our workload has some pretty high throughput and scaling requirements. Works amazing for our team, wouldn't change it for anything else at this point. Very low maintenance effort since AWS manages the K8s infra.

The Ministry of Truth?

How do you scale across multiple computers reliably?

All technologies have their pros and cons. They have use cases where they make sense and use case where they don't. The job of an engineer to decide which tool fits which use-case. To dismiss a useful technology as "BS", especially one used by companies all over the world for over a decade without any backing data seems a bit disingenuous.

This is the video I recommend to others when working with dynamodb. The video is by Rick Houlihan about dynamodb modeling. In my experience most developers that complain about dynamodb don't fully understand it.

https://www.youtube.com/watch?v=HaEPXoXVf2k

I'm always surprised by all the vitriol on here against kubernetes. My development experience must have been drastically different than the average hacker news startup developer.

It is definitely true you don't need kubernetes for all use cases, but I also sometimes question if people have worked on the sort of large-scale systems where k8s really shines.

My background is at larger enterprise type tech companies, doing high volume service traffic at significant scale, and I've found kubernetes invaluable to managing our services. To the point that if someone suggest we remove it from stack, I would question their experience operating these sorts of systems.

The thing is I don't think it is bold at all. Housing being overvalued seems perfectly obvious consequence of negative or near-zero interest rates. One side effect of those policies is that the mortgage rates were artificially lowered.

A lot of people buying houses unfortunately don't really look at aggregate home ownership cost and focus (incorrectly) on monthly payments. So, because they can afford the monthly payment, they think they can afford the house. This of course works works until the music stops.

Western Europe is also way smaller than the united states, so I'm not sure how apt this comparison is.