19 ms·

I would wager that more than half of all Kubernetes deployments are completely unnecessary yak shaves.

by rapind 3y ago

acdha 3y ago
I think there is a solid argument for it as a cloud portability layer – I’m literally in the middle of a GKE->EKS migration where that’s paying off as hoped - but I would fascinated to see the numbers for what percentage of places ever do that or the total cost incurred avoiding services which couldn’t be used interchangeably between providers. I think people want ORM-level portability but it’s more like how you can technically have a Java desktop app support Windows, macOS, and Linux.
- jpgvm 3y ago
  The portability of your stack is one aspect but there are other more important factors: 1. The tools you want to use work with the other k8s components or things commonly available in k8s environments. Say you want a cloud-portable messaging system. You can deploy Apache Pulsar on k8s and if you use the operator, helm charts (eww) or templates it will integrate out of the box with Prometheus, cert-manager, whatever volume provisioner you are using etc. You can't get that level of cloud-agnostic deployability or integration with tools like Terraform/Pulumi because all the underlying infrastructure resources are different on a per-cloud basis. Having such a powerful generic API that properly describes like 99% of workloads is a massive game changer. 2. The skillset is transferable. If you are comparing k8s to something like ECS, Cloud Run or friends you will end up with a bunch of proprietary knowledge that is hard to transfer. Similarily your hires won't come with that knowledge either but in this day and age they probably have robust k8s skills if they are infra folk or are aware of it if above that part of the stack. 3. Flexibility. Perhaps it's greatest strength and greatest weakness is that the set of primitives chosen to be exposed by k8s (with the exception of things like Ingress that needed to get re-done) are by and large skewed towards flexibility. This means doing all manner of 'very difficult things' are now considerably easier. Conversely however this flexibility means you still need to fully describe more common patterns which simpletons mistake for being "over-complicated" when what they really mean is "less easy". Don't fall into the trap of equating "easy" to "simplicity", k8s once understood is by far one of the simplest but as a result is usually more work to get started. Good example is say Arch Linux vs MacOS, the former is simple the latter is easy.
  - acdha 3y ago
    I’d class your first two points as portability but otherwise agree. There are solid business cases for picking Pulsar vs. e.g. AWS SQS/SNS and a lot of that is going to come down to whether you value portability more than the increased operational commitments. I wouldn’t fault anyone for picking either side of that as long as it was a considered call.
    - jpgvm 3y ago
      I guess if you consider k8s to be it's own ecosystem and then frame the first two points as just a consequence of the ecosystem being inherently portable then I guess so? IMO though compatibility and skill transferability (which speaks mostly to adoption rate) are separate things.
      - acdha 3y ago
        Definitely separate things - I just view them as part of the larger question of where you fall on the spectrum of how much you are outsourcing to your cloud provider. Another way of approaching it: would the cost of porting, say, an app which uses Lambda/SQS/SNS to GCP/cloud functions/PubSub be greater or lower than the cost of maintaining your own FaaS & queue/notification service on top of k8s? The answer isn’t fixed and will depend on things like your usage and staffing, and how complex your applications are, so I’d be most curious about how commonly people pick one versus the other and regret it due to some factor they didn’t anticipate.

I would wager that more than half of all Kubernetes deployments are completely unnecessary yak shaves.

by rapind 3y ago

I would wager that more than half of all Kubernetes deployments are completely unnecessary yak shaves.

I think there is a solid argument for it as a cloud portability layer – I’m literally in the middle of a GKE->EKS migration where that’s paying off as hoped - but I would fascinated to see the numbers for what percentage of places ever do that or the total cost incurred avoiding services which couldn’t be used interchangeably between providers. I think people want ORM-level portability but it’s more like how you can technically have a Java desktop app support Windows, macOS, and Linux.

jpgvm 3y ago
The portability of your stack is one aspect but there are other more important factors: 1. The tools you want to use work with the other k8s components or things commonly available in k8s environments. Say you want a cloud-portable messaging system. You can deploy Apache Pulsar on k8s and if you use the operator, helm charts (eww) or templates it will integrate out of the box with Prometheus, cert-manager, whatever volume provisioner you are using etc. You can't get that level of cloud-agnostic deployability or integration with tools like Terraform/Pulumi because all the underlying infrastructure resources are different on a per-cloud basis. Having such a powerful generic API that properly describes like 99% of workloads is a massive game changer. 2. The skillset is transferable. If you are comparing k8s to something like ECS, Cloud Run or friends you will end up with a bunch of proprietary knowledge that is hard to transfer. Similarily your hires won't come with that knowledge either but in this day and age they probably have robust k8s skills if they are infra folk or are aware of it if above that part of the stack. 3. Flexibility. Perhaps it's greatest strength and greatest weakness is that the set of primitives chosen to be exposed by k8s (with the exception of things like Ingress that needed to get re-done) are by and large skewed towards flexibility. This means doing all manner of 'very difficult things' are now considerably easier. Conversely however this flexibility means you still need to fully describe more common patterns which simpletons mistake for being "over-complicated" when what they really mean is "less easy". Don't fall into the trap of equating "easy" to "simplicity", k8s once understood is by far one of the simplest but as a result is usually more work to get started. Good example is say Arch Linux vs MacOS, the former is simple the latter is easy.
- acdha 3y ago
  I’d class your first two points as portability but otherwise agree. There are solid business cases for picking Pulsar vs. e.g. AWS SQS/SNS and a lot of that is going to come down to whether you value portability more than the increased operational commitments. I wouldn’t fault anyone for picking either side of that as long as it was a considered call.
  - jpgvm 3y ago
    I guess if you consider k8s to be it's own ecosystem and then frame the first two points as just a consequence of the ecosystem being inherently portable then I guess so? IMO though compatibility and skill transferability (which speaks mostly to adoption rate) are separate things.
    - acdha 3y ago
      Definitely separate things - I just view them as part of the larger question of where you fall on the spectrum of how much you are outsourcing to your cloud provider. Another way of approaching it: would the cost of porting, say, an app which uses Lambda/SQS/SNS to GCP/cloud functions/PubSub be greater or lower than the cost of maintaining your own FaaS & queue/notification service on top of k8s? The answer isn’t fixed and will depend on things like your usage and staffing, and how complex your applications are, so I’d be most curious about how commonly people pick one versus the other and regret it due to some factor they didn’t anticipate.