4 ms·

What are the benefits of k8s over docker-compose for small/medium business?

by alexalx666 4y ago

maccard 4y ago
All of the cloud providers offer k8s as a service, for one.
- alexalx666 4y ago
  I should specify I was thinking about VPS. Coming from AWS to Linode VPS with Caddy + Docker felt great, Im wondering at what point (N requests per second ?) it becomes tech dept
  - maccard 4y ago
    Yeah that's definitely something that needs to be specified. > Coming from AWS to Linode VPS with Caddy + Docker felt great I guess that depends what you were using with AWS, but Fargate + k8s is a pretty amazing workflow. > Im wondering at what point (N requests per second ?) it becomes tech dept I make these calls for our org, and I wouldn't call it tech debt based on the performance or scale, but because of maintenance. As an example, if you needed to hire a new person/replacement person for your team, would it be easier to find someone who can maintain k8s or docker compose? The other area it shines for is the ecosystem. If you need to add monitoring to your app (e.g. with Prometheus), adding it to a k8s cluster is `helm install prometheus`
    - alexalx666 4y ago
      thanks for detailed response! how big is your org? My concern is that there is a cost to magic of adding deps like that. Complexity goes up and it is harder to understand what went wrong and where are the performance bottlenecks. I guess my question is at what org scale the tradeoffs are right
      - maccard 4y ago
        > how big is your org? My last team was the same, there was ~100 developers on the main app, ~50 on the ancillary services, and a ballpark of ~10 on the "platform". I was just a team member on that team. Current org is 15 devs, 30 people total. > My concern is that there is a cost to magic of adding deps like that. Of course there is, there's such thing as a free lunch. It's up to you to decide which is right for your team/org. The cost of doing it manually is developer time, tech debt and the bus factor. The cost of using helm is introducing an abstraction. Profesionally, the bus factor and developer time of home rolling a solution make relying on existing solutions a very appealing proposition. Having to maintain a set of half baked shell scripts is exactly what tools exist to solve, and I've had more issues with deployments where someone has bunged together a bash script that makes varios assumptions about tooling, versions, installation paths, working directories, path formats, etc. than I have with problems related to our actual deployment infrastructure. > I guess my question is at what org scale the tradeoffs are right The cost of switching is huge, and likely not worth it unless you have genuine problems that would be solved by moving. For a greenfield project, frankly I'd think you're wrong to use docker-compose on any new project. Either you're managing the underlying infrastructure (ec2/vps style) or you're not (fargate/DO App Platform style), and in either case docker compose requires roughly the same amount of investment for a smaller return on a less actively developed product objectively solves less problems and requires more work to integrate. [0] https://github.com/marketplace/actions/deploy-to-kubernetes-cluster https://github.com/marketplace/actions/deploy-to-kubernetes-...
        alexalx666 4y ago
        thanks for your insights! I had an impression that k8s is more for enterprise stuff, I will definatly give it a try!
p_l 4y ago
While the specifications are more complex, I find much more sensible in management than docker-compose, and allowing easier expansion (not scaling the service, expansion of underlying hardware) which means keeping costs lower can be easier.
- alexalx666 4y ago
  Could you specify what you mean by "management"
  - p_l 4y ago
    One of the systems I set up recently I decided to go the docker-compose way. Quite quickly I found out that either the tool doesn't support (or at least isn't exactly interested in supporting) multiple compose files, or I am too stupid to find out the right combo of options, which resulted in a growing yaml file as the setup of dockerized components rose on that specific server. Whatever claims about user friendliness, I didn't figure a stable way to do deploy separate docker-compose.yml's from same user at the same time.
    - lukaszkorecki 4y ago
      Not using Compose in production, but our development setup is split across multiple files - you can include them by passing -f flag to Docker Compose (I wrote a small wrapper script that does that automatically)

What are the benefits of k8s over docker-compose for small/medium business?

maccard 4y ago

All of the cloud providers offer k8s as a service, for one.

alexalx666 4y ago
I should specify I was thinking about VPS. Coming from AWS to Linode VPS with Caddy + Docker felt great, Im wondering at what point (N requests per second ?) it becomes tech dept
- maccard 4y ago
  Yeah that's definitely something that needs to be specified. > Coming from AWS to Linode VPS with Caddy + Docker felt great I guess that depends what you were using with AWS, but Fargate + k8s is a pretty amazing workflow. > Im wondering at what point (N requests per second ?) it becomes tech dept I make these calls for our org, and I wouldn't call it tech debt based on the performance or scale, but because of maintenance. As an example, if you needed to hire a new person/replacement person for your team, would it be easier to find someone who can maintain k8s or docker compose? The other area it shines for is the ecosystem. If you need to add monitoring to your app (e.g. with Prometheus), adding it to a k8s cluster is `helm install prometheus`
  - alexalx666 4y ago
    thanks for detailed response! how big is your org? My concern is that there is a cost to magic of adding deps like that. Complexity goes up and it is harder to understand what went wrong and where are the performance bottlenecks. I guess my question is at what org scale the tradeoffs are right
    - maccard 4y ago
      > how big is your org? My last team was the same, there was ~100 developers on the main app, ~50 on the ancillary services, and a ballpark of ~10 on the "platform". I was just a team member on that team. Current org is 15 devs, 30 people total. > My concern is that there is a cost to magic of adding deps like that. Of course there is, there's such thing as a free lunch. It's up to you to decide which is right for your team/org. The cost of doing it manually is developer time, tech debt and the bus factor. The cost of using helm is introducing an abstraction. Profesionally, the bus factor and developer time of home rolling a solution make relying on existing solutions a very appealing proposition. Having to maintain a set of half baked shell scripts is exactly what tools exist to solve, and I've had more issues with deployments where someone has bunged together a bash script that makes varios assumptions about tooling, versions, installation paths, working directories, path formats, etc. than I have with problems related to our actual deployment infrastructure. > I guess my question is at what org scale the tradeoffs are right The cost of switching is huge, and likely not worth it unless you have genuine problems that would be solved by moving. For a greenfield project, frankly I'd think you're wrong to use docker-compose on any new project. Either you're managing the underlying infrastructure (ec2/vps style) or you're not (fargate/DO App Platform style), and in either case docker compose requires roughly the same amount of investment for a smaller return on a less actively developed product objectively solves less problems and requires more work to integrate. [0] https://github.com/marketplace/actions/deploy-to-kubernetes-cluster https://github.com/marketplace/actions/deploy-to-kubernetes-...
      - alexalx666 4y ago
        thanks for your insights! I had an impression that k8s is more for enterprise stuff, I will definatly give it a try!

p_l 4y ago

While the specifications are more complex, I find much more sensible in management than docker-compose, and allowing easier expansion (not scaling the service, expansion of underlying hardware) which means keeping costs lower can be easier.

alexalx666 4y ago
Could you specify what you mean by "management"
- p_l 4y ago
  One of the systems I set up recently I decided to go the docker-compose way. Quite quickly I found out that either the tool doesn't support (or at least isn't exactly interested in supporting) multiple compose files, or I am too stupid to find out the right combo of options, which resulted in a growing yaml file as the setup of dockerized components rose on that specific server. Whatever claims about user friendliness, I didn't figure a stable way to do deploy separate docker-compose.yml's from same user at the same time.
  - lukaszkorecki 4y ago
    Not using Compose in production, but our development setup is split across multiple files - you can include them by passing -f flag to Docker Compose (I wrote a small wrapper script that does that automatically)