4 ms·

I'm curious what HN would recommend as alternatives, especially for small/early teams that are outgrowing single-machine setups. It seems to me that there's so

I'm curious what HN would recommend as alternatives, especially for small/early teams that are outgrowing single-machine setups. It seems to me that there's something of a gap between "for single machine setups" (eg docker-compose) and "for 500-engineer teams" (eg kubernetes).

eitland 7y ago
Often you don't need docker-compose either as long as you aren't deploying things that have weird dependencies. Single monolithic application? Can run on a VM. Multiple smaller applications written in Java, C# or Go? Can probably run side by side on a VM.
- skrebbel 7y ago
  Fwiw docker compose is great for running stuff side by side on a VM :-)
michaldudek 7y ago
I’ve been using Rancher for years. Version 2 is all about K8s, but version 1 is super simple to set up and manage with a nice and clean GUI and pretty much no new concepts. Unfortunately version 1 is abandoned now (I think) but it’s stable and I haven’t had any problems with it. Give it a go.
eysi 7y ago
Full-disclosure: I co-founded a company that's building a developer tool for K8s (and distributed systems in general). But we've had a lot of success with running on GKE. The tool that we're making takes away the complexity of building, testing and deploying the stack, and GKE takes care of running it. In fact we use GKE for both our development and staging/prod environments. There are a lot of great tools out there that vastly improve the K8s developer experience[1] and the cloud providers take away of the pain of operating it. And with tools like Terraform and Pulumi you can codify the whole setup. Here's an example of how you can quite easily get started on GKE: https://medium.com/garden-io/gke-and-cloud-sql-a-complete-workflow-with-garden-and-terraform-1cad091e2be2 https://medium.com/garden-io/gke-and-cloud-sql-a-complete-wo... Here's a video of the same workflow: https://www.youtube.com/watch?v=iHyeD97GrE4 https://www.youtube.com/watch?v=iHyeD97GrE4. [1] https://github.com/GoogleContainerTools/skaffold https://github.com/GoogleContainerTools/skaffold https://github.com/garden-io/garden https://github.com/garden-io/garden https://github.com/windmilleng/tilt https://github.com/windmilleng/tilt
ecmascript 7y ago
I work in a small team, we just install and configure everything without Docker, Kubernetes or anything else. Just install it like I would with any other software and then run it after configuration. When it's time to deploy we have a bash script that bundles the app and pushes it onto the server. Almost too simple to work, but it does ;)
whatsmyusername 7y ago
ECS works great and ties into IAM/VPC/etc. Also you're not paying $80 per control plane, they're free.
mrweasel 7y ago
I would recommend two machines and a loadbalancer. Most often the thing that doesn't scale isn't the applications you're able to run in Kubernetes, at least not at first. Most customers I've dealt with who have scaling issue need take a look at their database before Kubernetes. Kubernetes is awesome of many reasons, but it's a big step from a single server setup to full Kubernetes and there are plenty of options in between. We're able to scale large national infrastructure projects using VMs and loadbalancers, but we also deploy run stuff on Kubernetes. The thing is: when stuff breaks, you'll prefer that it's not the Kubernetes stuff. If you run the infrastructure your self, you should be VERY sure that you know how it works, because debugging it is extremely complex.
jve 7y ago
Docker swarm?
- skrebbel 7y ago
  Does anyone actually use it in anger though? I've not followed it well, but it seems to me like it's Docker Inc's failed attempt to compete with K8s, which doesn't bode well for its future.
  - jve 7y ago
    Anyway, it fills the gap between single node docker-compose and k8s. Because you can use docker-compose against swarm instance (so your app is running across multiple hosts) Swarm is so simple. Few commands and you can start scaling, routing, load balancing, desired state reconciliation https://docs.docker.com/compose/production/#running-compose-on-a-swarm-cluster https://docs.docker.com/compose/production/#running-compose-... Yeah, there is a concern about the docker swarm future: https://github.com/docker/swarm/issues/2965 https://github.com/docker/swarm/issues/2965 But mirantis just last week announced they will support and INVEST in docker swarm: https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-develop-docker-swarm/ https://www.mirantis.com/blog/mirantis-will-continue-to-supp...
  - the_angry_angel 7y ago
    Yup. It’s good enough if you’re already invested in docker for dev and good enough if you’ve out grown a single machine. But not big enough for more than 10 nodes and user roles. From an ops point of view it’s simple to deploy and I’m yet to hit any really sharp edges. However the lack of cronjobs and init containers is an annoyance, but you can work around them. Mirantis’ recent announcement of further dev on Swarm after the initial announcement of only 2 years of support has not helped. I had been looking at moving to k8s. I’m now undecided if we should just continue with the plan to dump Swarm or keep it.

eitland 7y ago

Often you don't need docker-compose either as long as you aren't deploying things that have weird dependencies. Single monolithic application? Can run on a VM. Multiple smaller applications written in Java, C# or Go? Can probably run side by side on a VM.

skrebbel 7y ago
Fwiw docker compose is great for running stuff side by side on a VM :-)

michaldudek 7y ago

I’ve been using Rancher for years. Version 2 is all about K8s, but version 1 is super simple to set up and manage with a nice and clean GUI and pretty much no new concepts. Unfortunately version 1 is abandoned now (I think) but it’s stable and I haven’t had any problems with it. Give it a go.

eysi 7y ago

Full-disclosure: I co-founded a company that's building a developer tool for K8s (and distributed systems in general). But we've had a lot of success with running on GKE. The tool that we're making takes away the complexity of building, testing and deploying the stack, and GKE takes care of running it. In fact we use GKE for both our development and staging/prod environments. There are a lot of great tools out there that vastly improve the K8s developer experience[1] and the cloud providers take away of the pain of operating it. And with tools like Terraform and Pulumi you can codify the whole setup. Here's an example of how you can quite easily get started on GKE: https://medium.com/garden-io/gke-and-cloud-sql-a-complete-workflow-with-garden-and-terraform-1cad091e2be2 https://medium.com/garden-io/gke-and-cloud-sql-a-complete-wo... Here's a video of the same workflow: https://www.youtube.com/watch?v=iHyeD97GrE4 https://www.youtube.com/watch?v=iHyeD97GrE4. [1] https://github.com/GoogleContainerTools/skaffold https://github.com/GoogleContainerTools/skaffold https://github.com/garden-io/garden https://github.com/garden-io/garden https://github.com/windmilleng/tilt https://github.com/windmilleng/tilt

ecmascript 7y ago

I work in a small team, we just install and configure everything without Docker, Kubernetes or anything else. Just install it like I would with any other software and then run it after configuration. When it's time to deploy we have a bash script that bundles the app and pushes it onto the server. Almost too simple to work, but it does ;)

whatsmyusername 7y ago

ECS works great and ties into IAM/VPC/etc. Also you're not paying $80 per control plane, they're free.

mrweasel 7y ago

I would recommend two machines and a loadbalancer. Most often the thing that doesn't scale isn't the applications you're able to run in Kubernetes, at least not at first. Most customers I've dealt with who have scaling issue need take a look at their database before Kubernetes. Kubernetes is awesome of many reasons, but it's a big step from a single server setup to full Kubernetes and there are plenty of options in between. We're able to scale large national infrastructure projects using VMs and loadbalancers, but we also deploy run stuff on Kubernetes. The thing is: when stuff breaks, you'll prefer that it's not the Kubernetes stuff. If you run the infrastructure your self, you should be VERY sure that you know how it works, because debugging it is extremely complex.

jve 7y ago

Docker swarm?

skrebbel 7y ago
Does anyone actually use it in anger though? I've not followed it well, but it seems to me like it's Docker Inc's failed attempt to compete with K8s, which doesn't bode well for its future.
- jve 7y ago
  Anyway, it fills the gap between single node docker-compose and k8s. Because you can use docker-compose against swarm instance (so your app is running across multiple hosts) Swarm is so simple. Few commands and you can start scaling, routing, load balancing, desired state reconciliation https://docs.docker.com/compose/production/#running-compose-on-a-swarm-cluster https://docs.docker.com/compose/production/#running-compose-... Yeah, there is a concern about the docker swarm future: https://github.com/docker/swarm/issues/2965 https://github.com/docker/swarm/issues/2965 But mirantis just last week announced they will support and INVEST in docker swarm: https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-develop-docker-swarm/ https://www.mirantis.com/blog/mirantis-will-continue-to-supp...
- the_angry_angel 7y ago
  Yup. It’s good enough if you’re already invested in docker for dev and good enough if you’ve out grown a single machine. But not big enough for more than 10 nodes and user roles. From an ops point of view it’s simple to deploy and I’m yet to hit any really sharp edges. However the lack of cronjobs and init containers is an annoyance, but you can work around them. Mirantis’ recent announcement of further dev on Swarm after the initial announcement of only 2 years of support has not helped. I had been looking at moving to k8s. I’m now undecided if we should just continue with the plan to dump Swarm or keep it.