3 ms·
I agree. I don't understand why you would use k8s on AWS. It's an abstraction on top of an abstraction doing nothing but adding complexity. If your k8s pods hav
by d0gsg0w00f 5y ago
I agree. I don't understand why you would use k8s on AWS. It's an abstraction on top of an abstraction doing nothing but adding complexity. If your k8s pods have to interact with S3 buckets, IAM profiles, and load balancers anyway then you can't ignore the platform. It's just somebody chasing the cloud agnosticism fallacy or doing resume driven development.
- kgeist 5y agoWe have to support cloud providers in other countries due to local data protection laws (not every country has an AWS data center); doesn't it make sense to make your infrastructure management more-less uniform no matter where it's hosted? In some countries, providers may have only a single availability zone (in reality), or they can get very unstable from time to time (everything is down and god knows for how long), so it's natural for us in such countries to migrate our whole production between completely different providers several times a year. As an ordinary engineer whose job sometimes involves investigating problems in production or configuring something here and there (I'm not a full-time DevOps or SRE myself), I don't have to learn the details of whatever is the current cloud provider this week in the affected country N, I access the production system through a familiar interface which looks more-less same everywhere (k8s), including our test environments, too. Am I missing something? I am pretty curious what "cloud agnosticism fallacy" means. How would you do it differently?
- d0gsg0w00f 5y agoIn your case it makes sense because you don't run primarily on AWS. I work with people who only host in AWS and still use k8s + other native AWS constructs.