<story><title>Show HN: Magic Sandbox – learn Kubernetes on real infrastructure</title><url>https://magicsandbox.com</url></story><parent_chain><item><author>tootie</author><text>This is a really cool platform, but it kinda exposes the extremely high barrier of entry to getting running with k8s. It&amp;#x27;s a very powerful and useful platform, but it doesn&amp;#x27;t seem to strike the right balance with it&amp;#x27;s abstractions to actually make intuitive sense to developers.</text></item></parent_chain><comment><author>djsumdog</author><text>This is the problem I have with almost all container orchestration systems (DC&amp;#x2F;OS, K8s, etc.) None of them can go from 1 node running all your apps to 100, in an easy straight forward manner. I wrote about this not too long ago:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;penguindreams.org&amp;#x2F;blog&amp;#x2F;my-love-hate-relationship-with-docker-and-container-orchestration-systems&amp;#x2F;#zero-to-a-hundred&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;penguindreams.org&amp;#x2F;blog&amp;#x2F;my-love-hate-relationship-wit...&lt;/a&gt;&lt;p&gt;I&amp;#x27;ve also worked at both Kubernetes shops and DCOS&amp;#x2F;marathon shops and I honestly don&amp;#x27;t understand why people are choosing K8s. I&amp;#x27;m sure a lot of it is the marketing and the power of Google behind it, but our DC&amp;#x2F;OS cluster had hundreds of nodes and could scale applications really well. Plus I found the marathon json files way less confusing. (Plus if you really want, you can use k8s to schedule containers on DC&amp;#x2F;OS, alongside marathon).&lt;p&gt;That being said, that DCOS platform team was 11 people and they had tons of custom scripts, wiki pages, labels and specific networking ingress&amp;#x2F;egress points that all worked together. (You could even use a label to specify if you wanted to run containers on the local VMWare cluster or in AWS; with nodes that auto-scaled out into AWS in high load).&lt;p&gt;I&amp;#x27;ve met people at smaller startups who&amp;#x27;ve gone the Nomad route instead, which seems a lot more sane in many ways, but still requires pretty careful planning and setup for large deploys.</text></comment>
<story><title>Show HN: Magic Sandbox – learn Kubernetes on real infrastructure</title><url>https://magicsandbox.com</url></story><parent_chain><item><author>tootie</author><text>This is a really cool platform, but it kinda exposes the extremely high barrier of entry to getting running with k8s. It&amp;#x27;s a very powerful and useful platform, but it doesn&amp;#x27;t seem to strike the right balance with it&amp;#x27;s abstractions to actually make intuitive sense to developers.</text></item></parent_chain><comment><author>striking</author><text>That&amp;#x27;s because, for the vast majority of developers, there&amp;#x27;s no point in using k8s.&lt;p&gt;It&amp;#x27;s really only necessary when you have a big app (or a few instances of a few big apps) that will have lots of containers and lots of management required.&lt;p&gt;Please. Don&amp;#x27;t use k8s as a golden hammer. Docker alone (or with docker-compose) will be just fine for most people, especially when paired with a basic CI pipeline like Drone or Jenkins.&lt;p&gt;(If you&amp;#x27;re reading this, thinking &amp;quot;but it makes installing and managing services I depend on easier!&amp;quot; it doesn&amp;#x27;t obviate you of that responsibility entirely, not in production. You still have to make sure those services deploy properly, you still have to manage them to some degree... for some time, it was considered inadvisable to run your DB in-cluster because of how many ways it could fail.)</text></comment>