Hacker News Reader

Comment by alexellisuk | Hacker News Reader

I normally used minikube for openfaas development - I appreciate the efforts of the project, it's an invalueable tool. The DfM integration works very well for local development and I've got some screenshots below:

https://twitter.com/alexellisuk/status/949595379326210048

Make sure you do a context-switch for kubectl too.

I see some people talking about Swarm vs Kubernetes. Swarm has always maintained a less modular approach which made it simpler to work with - it's obviously not going anywhere since there are customers relying on it in production.

Out of the two it's the only one that can actually fit into and run on a Raspberry Pi Zero because K8s has such high base requirements at idle in comparison. For a better comparison see my blog post - https://blog.alexellis.io/you-need-to-know-kubernetes-and-sw...

View on HN

I find that Swarm is the only thing that fits my use case of just shipping. There's so much complexity and overhead with kubernetes and often I just want something that works so I can ship it. You just can't beat Swarm for building an insta-cluster that works well and quickly gets you where you want to be. I'm sure kubernetes is great if you have forty datacenters around the globe, but I don't, and neither does anybody I'm building services for.

Have you ever tried docker-compose?

While the two solutions are obviously with different goals in mind, one being to fully run the kubernetes setup locally, and the other one to run a few docker containers who talk to one another, if it's for the purpose of running a simple-ish dev environment, in my experience, docker-compose is much faster and simpler than minikube.

docker-compose trades a better initial UX for far less flexibility and, funnily enough, higher practical complexity in the long run. It's great if you want to get from zero to MVP with as little thinking about what your infrastructure needs will be as possible. It's pretty awful, however, when you want to truly productionalize what you've done and you find out that in order to do so you'll have to use the newest Compose format, and your docker-compose.yml (and possibly additional supporting Compose) files are not at all easier to read or simpler to write than e.g. k8s objects in YAML.

If you want a single file configuration on k8s, take a look at kedge.org

It's basically an extended version of native k8s yaml with some smart defaults and grouping resources similar to compose.

One could also just use one file with multiple YAML objects delimited by “\n—-\n”. The Kedge stuff looks moderately interesting, and I definitely would have found it useful a year ago. Now, though, I seem to have developed a begrudging admiration for the “native” YAML format. Maybe it’s Stockholm Syndrome, but once I finally began to understand Kubernetes I began to find the verbose YAML format to be a benefit rather than a barrier.

Thank you for your blog, it's a great source of knowledge for docker, kubernetes, and swarm, also love the openfaas

Reply on news.ycombinator.com