4 ms·

I use K8s because if I don’t like what my deployment costs or how my cluster is supported, I can easily pick it up and take it to another provider or even host

I use K8s because if I don’t like what my deployment costs or how my cluster is supported, I can easily pick it up and take it to another provider or even host it myself (though I don’t really want to self-host).

chrisandchris 3y ago
I can do the same with my Ansible and docker-compose scripts. Moving to another provider feels like the selling point of ORMs (moving to a different db engine), whereas most often it will never happen. It's fine that you use k8s and it looks like it's the perfect fit for your case, but tech often thinks "my solution" equals "everyones solution".
- pseudocomposer 3y ago
  Very much agreed on us not all needing the same solution. I’d argue Ansible makes more sense for apps written in scripting languages (particularly Python, obviously), while Kubernetes makes more sense for deploying statically-typed/compiled images where devs shouldn’t really need to deal with the whole Python ecosystem in addition to their compilers, linkers, etc. But of course there’s plenty of room for crossover! To your point about this being like ORMs, though: I would argue building apps to deploy with Kubernetes or Ansible is less like using an ORM, and more like building them to compile for any OS rather than depending on Windows/Linux/macOS libraries. DB engines generally have much more similar costs than server hosting companies do (you could pay 2x as much to host an app on one vs the other depending on what you need), so it makes less sense to switch. (Also, back in the days when ORMs were created, Oracle was much more dominant than today so DB cost differentials were a bigger issue, but that’s not really today’s market. These days many engines just offer wire compatibility with Postgres/MySQL libraries anyway, so that aspect of ORMs is really not the selling point anymore, it’s the mapping of DB type systems to language type systems.)

chrisandchris 3y ago

I can do the same with my Ansible and docker-compose scripts. Moving to another provider feels like the selling point of ORMs (moving to a different db engine), whereas most often it will never happen. It's fine that you use k8s and it looks like it's the perfect fit for your case, but tech often thinks "my solution" equals "everyones solution".

pseudocomposer 3y ago
Very much agreed on us not all needing the same solution. I’d argue Ansible makes more sense for apps written in scripting languages (particularly Python, obviously), while Kubernetes makes more sense for deploying statically-typed/compiled images where devs shouldn’t really need to deal with the whole Python ecosystem in addition to their compilers, linkers, etc. But of course there’s plenty of room for crossover! To your point about this being like ORMs, though: I would argue building apps to deploy with Kubernetes or Ansible is less like using an ORM, and more like building them to compile for any OS rather than depending on Windows/Linux/macOS libraries. DB engines generally have much more similar costs than server hosting companies do (you could pay 2x as much to host an app on one vs the other depending on what you need), so it makes less sense to switch. (Also, back in the days when ORMs were created, Oracle was much more dominant than today so DB cost differentials were a bigger issue, but that’s not really today’s market. These days many engines just offer wire compatibility with Postgres/MySQL libraries anyway, so that aspect of ORMs is really not the selling point anymore, it’s the mapping of DB type systems to language type systems.)