5 ms·

docker-compose only deploys on individual nodes though.

ok123456 4y ago
That's shifting the goal posts. And, that covers 99.9% of cases anyway. If you want to deploy across multiple nodes run docker compose on multiple nodes and expose the nodes to each other over a vlan that is managed as part of your actual infrastructure where it has a chance of being actually documented and put into a configuration management system.
- coding123 4y ago
  It may not be shifting the goal posts much because the typical situations that k8s comes up is when you need multiple nodes, so yeah we're IN the 0.1% of k8s users in here.
- orf 4y ago
  > If you want to deploy across multiple nodes run docker compose on multiple nodes and expose the nodes to each other over a vlan that is managed as part of your actual infrastructure Indeed, and for a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. It doesn’t mean Kubernetes isn’t a useful turnkey solution, especially if it’s managed.
  - ok123456 4y ago
    What's the actual savings if you now just have additional complexity that isn't really managed all that well when you use it as a turn key solution?
    - orf 4y ago
      Because you press 4 buttons on a cloud console, or write a bit of terraform, and you have a consistent management plane for all of this, one that you can plug into any tool the very large ecosystem. Then your entire engineering org just deploys things. Need per-application network security policies? Done. Per app IAM roles? Done. Secrets management? Done. Role based access control? Done. Isolate services to different pools of machines? Done. Per-app live-updating configuration files across your entire fleet? Done. CPU, memory or arbitrary per-app metric based auto scaling? Done. Want to run all this on cheap spot instances? Done. Want path based HTTP routing within your cluster? Done. Want an easy deployment mechanism with versioning and rollbacks? Done. Want simple and consistent service discovery across all your servers? Done. Want to get advanced and build custom resources to manage groups of other resources whilst taking advantage of k8s management plane in a consistent manner that just works with all the other tooling? Done. Want to do all this fairly consistently on any cloud vendor, or even on prem? Done. Want a large pool of candidates familiar with this stack? Done and done. All those lead to non trivial savings, so you can actually focus on your product and not building a crappy version of Kubernetes by stringing together docker compose instances. But yes, if you’ve got a single developer and you’re deploying by ssh-ing into a single machine and running git pull, it’s definitely overkill.
      - ok123456 4y ago
        Then it breaks.
        orf 4y ago
        Like everything does. If you don’t know that yet you’re in the wrong industry. Except this breaks less than a homegrown solution would with 100,000x less effort fix, build or maintain.
        ok123456 4y ago
        If it really were "100000x" less effort to fix, why are more and more resources being allocated to keep it going. It's a full time position keeping all the plates spinning in their air, but now It's even harder to debug and reason about. I guess it allows you to quickly start up a new project with some boilerplate configurations though. I wonder if there's a term for that, where you defer things perceived to be "hard" to save time up front. Sort of like a credit card you spend but with technical decisions ...
        orf 4y ago
        > why are more and more resources being allocated to keep it going What does that even mean? Where? Across the entire industry? In specific companies? Empirically how much “more resources”? Conversely you could ask: if k8s is so terrible and building your own version is so simple, why is the market not doing that? Everywhere I’ve seen that uses k8s does indeed have full time Devops/platform people, but the ratio to the developers they support is far, far lower than homegrown platforms, as is the time to implement new requirements. Usually these homegrown solutions get to a specific point in time where there isn’t the internal knowledge to maintain them, and the effort required grows too large. At which point they stagnate. Building on a stagnant, homegrown platform that you don’t know how to improve is not great.
        oso2k 4y ago
        And then a controller or operator heals it.
    - arinlen 4y ago
      > What's the actual savings if you now just have additional complexity (...) You don't. You get less complexity, actually. Even with Docker, a Docker stack in Docker swarm mode is that simpler and easier to maintain and to monitor and to update and roll back than an unexplainable and impossible to justify docker-compose up. With Kubernetes, it can be even easier than that. Just grab a distro like Ubuntu, instal microk8s and deploy a kustomize script right out of the bat. Are you really running away from complexity or just irrationally hating on a tool just because you're oblivious to what it provides for free?

That's shifting the goal posts. And, that covers 99.9% of cases anyway. If you want to deploy across multiple nodes run docker compose on multiple nodes and expose the nodes to each other over a vlan that is managed as part of your actual infrastructure where it has a chance of being actually documented and put into a configuration management system.

coding123 4y ago
It may not be shifting the goal posts much because the typical situations that k8s comes up is when you need multiple nodes, so yeah we're IN the 0.1% of k8s users in here.
orf 4y ago
> If you want to deploy across multiple nodes run docker compose on multiple nodes and expose the nodes to each other over a vlan that is managed as part of your actual infrastructure Indeed, and for a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. It doesn’t mean Kubernetes isn’t a useful turnkey solution, especially if it’s managed.
- ok123456 4y ago
  What's the actual savings if you now just have additional complexity that isn't really managed all that well when you use it as a turn key solution?
  - orf 4y ago
    Because you press 4 buttons on a cloud console, or write a bit of terraform, and you have a consistent management plane for all of this, one that you can plug into any tool the very large ecosystem. Then your entire engineering org just deploys things. Need per-application network security policies? Done. Per app IAM roles? Done. Secrets management? Done. Role based access control? Done. Isolate services to different pools of machines? Done. Per-app live-updating configuration files across your entire fleet? Done. CPU, memory or arbitrary per-app metric based auto scaling? Done. Want to run all this on cheap spot instances? Done. Want path based HTTP routing within your cluster? Done. Want an easy deployment mechanism with versioning and rollbacks? Done. Want simple and consistent service discovery across all your servers? Done. Want to get advanced and build custom resources to manage groups of other resources whilst taking advantage of k8s management plane in a consistent manner that just works with all the other tooling? Done. Want to do all this fairly consistently on any cloud vendor, or even on prem? Done. Want a large pool of candidates familiar with this stack? Done and done. All those lead to non trivial savings, so you can actually focus on your product and not building a crappy version of Kubernetes by stringing together docker compose instances. But yes, if you’ve got a single developer and you’re deploying by ssh-ing into a single machine and running git pull, it’s definitely overkill.
    - ok123456 4y ago
      Then it breaks.
      - orf 4y ago
        Like everything does. If you don’t know that yet you’re in the wrong industry. Except this breaks less than a homegrown solution would with 100,000x less effort fix, build or maintain.
        ok123456 4y ago
        If it really were "100000x" less effort to fix, why are more and more resources being allocated to keep it going. It's a full time position keeping all the plates spinning in their air, but now It's even harder to debug and reason about. I guess it allows you to quickly start up a new project with some boilerplate configurations though. I wonder if there's a term for that, where you defer things perceived to be "hard" to save time up front. Sort of like a credit card you spend but with technical decisions ...
        orf 4y ago
        > why are more and more resources being allocated to keep it going What does that even mean? Where? Across the entire industry? In specific companies? Empirically how much “more resources”? Conversely you could ask: if k8s is so terrible and building your own version is so simple, why is the market not doing that? Everywhere I’ve seen that uses k8s does indeed have full time Devops/platform people, but the ratio to the developers they support is far, far lower than homegrown platforms, as is the time to implement new requirements. Usually these homegrown solutions get to a specific point in time where there isn’t the internal knowledge to maintain them, and the effort required grows too large. At which point they stagnate. Building on a stagnant, homegrown platform that you don’t know how to improve is not great.
      - oso2k 4y ago
        And then a controller or operator heals it.
  - arinlen 4y ago
    > What's the actual savings if you now just have additional complexity (...) You don't. You get less complexity, actually. Even with Docker, a Docker stack in Docker swarm mode is that simpler and easier to maintain and to monitor and to update and roll back than an unexplainable and impossible to justify docker-compose up. With Kubernetes, it can be even easier than that. Just grab a distro like Ubuntu, instal microk8s and deploy a kustomize script right out of the bat. Are you really running away from complexity or just irrationally hating on a tool just because you're oblivious to what it provides for free?