4 ms·

Easier to go from dev to prod ?

by samber 10y ago

andrewstuart2 10y ago
Not really, though. It's super easy to run a local kube instance (now even cross-platform [1]). In fact, it's much easier at the moment to spin up prod environments for Kubernetes, so I'd argue that Kube still wins in the dev->prod arena. [1] https://github.com/micro-kube/micro-kube https://github.com/micro-kube/micro-kube
- olalonde 10y ago
  But you have to learn a bunch of new words (manifests, pods, controllers, etc.) and while spinning up new prod environments is relatively straightforward, maintaining/upgrading one is not. Kubernetes is still a lot more mature though.
- boulos 10y ago
  I think you mean to link to the now official Minikube (https://github.com/kubernetes/minikube https://github.com/kubernetes/minikube). But yes, this is a big win for getting started and local development.
- msl09 10y ago
  For me, simplicity beats completeness any day of the week. With swarm it takes 3 commands to create a swarm of 2 nodes and raise a simple replicated service(not considering installing swarm and ssh'ing into the nodes). Now lets talk about kubernetes: With kubernetes I need to edit several configuration files and run 4 commands to start the master, edit more configuration files in each minion run 4 more commands, btw all that without ingress(which swarm has it built in by default, though I hear that it's also coming for kubernetes). When all that is done I'm finally able to start writing my pods and services(with swarm pods=services so it's less flexible, but easier to wrap your head around). Writing pods is a challenge on it's own the API changed like there was no tomorrow in the past(maybe that will improve in the future) so most configurations you find on the internet are out of date and will simply not run, nearly every field requires a name tag for no obvious reason, exposing services to the rest of your network seems to require a phd in distributed network systems. The documentation is often inconsistent with the current version. The customer/community support is non-existent or abrasive. Actually I think this tweet by Kesley Hightower underlines pretty accurately the team attitude towards criticism on the state of the software: https://twitter.com/kelseyhightower/status/735511037928038401 https://twitter.com/kelseyhightower/status/73551103792803840... Finally I must say that all those problems that I have encountered were with creating a kubernetes cluster in our company infrastructure, I have not encountered most of those problems using gcloud. If you use google's infrastructure kubernetes is just harder than swarm, not unbearably obnoxious. Sadly we don't have the option to rent a cloud service for our company. To sum it up, I think it's great that docker is becoming a competitor to kubernetes their attitude towards quality always impressed me and thus far I'm sold on it, but the best outcome of this is that having docker in the cluster managers competition may help raise the bar for every system.

Easier to go from dev to prod ?

by samber 10y ago

Easier to go from dev to prod ?

Not really, though. It's super easy to run a local kube instance (now even cross-platform [1]). In fact, it's much easier at the moment to spin up prod environments for Kubernetes, so I'd argue that Kube still wins in the dev->prod arena. [1] https://github.com/micro-kube/micro-kube https://github.com/micro-kube/micro-kube

olalonde 10y ago
But you have to learn a bunch of new words (manifests, pods, controllers, etc.) and while spinning up new prod environments is relatively straightforward, maintaining/upgrading one is not. Kubernetes is still a lot more mature though.
boulos 10y ago
I think you mean to link to the now official Minikube (https://github.com/kubernetes/minikube https://github.com/kubernetes/minikube). But yes, this is a big win for getting started and local development.
msl09 10y ago
For me, simplicity beats completeness any day of the week. With swarm it takes 3 commands to create a swarm of 2 nodes and raise a simple replicated service(not considering installing swarm and ssh'ing into the nodes). Now lets talk about kubernetes: With kubernetes I need to edit several configuration files and run 4 commands to start the master, edit more configuration files in each minion run 4 more commands, btw all that without ingress(which swarm has it built in by default, though I hear that it's also coming for kubernetes). When all that is done I'm finally able to start writing my pods and services(with swarm pods=services so it's less flexible, but easier to wrap your head around). Writing pods is a challenge on it's own the API changed like there was no tomorrow in the past(maybe that will improve in the future) so most configurations you find on the internet are out of date and will simply not run, nearly every field requires a name tag for no obvious reason, exposing services to the rest of your network seems to require a phd in distributed network systems. The documentation is often inconsistent with the current version. The customer/community support is non-existent or abrasive. Actually I think this tweet by Kesley Hightower underlines pretty accurately the team attitude towards criticism on the state of the software: https://twitter.com/kelseyhightower/status/735511037928038401 https://twitter.com/kelseyhightower/status/73551103792803840... Finally I must say that all those problems that I have encountered were with creating a kubernetes cluster in our company infrastructure, I have not encountered most of those problems using gcloud. If you use google's infrastructure kubernetes is just harder than swarm, not unbearably obnoxious. Sadly we don't have the option to rent a cloud service for our company. To sum it up, I think it's great that docker is becoming a competitor to kubernetes their attitude towards quality always impressed me and thus far I'm sold on it, but the best outcome of this is that having docker in the cluster managers competition may help raise the bar for every system.