<story><title>Is K8s Too Complicated? ￼</title><url>http://jmoiron.net/blog/is-k8s-too-complicated/</url></story><parent_chain><item><author>majewsky</author><text>&amp;gt; Kubernetes isn&amp;#x27;t giving you anything you couldn&amp;#x27;t have already built with configuration management.&lt;p&gt;Configuration management does not give you loadbalancing. Configuration management does not give you rolling upgrades.&lt;p&gt;I mean, sure, you can do this stuff with CM as well, but with k8s, there&amp;#x27;s nothing to build. It&amp;#x27;s already there</text></item><item><author>ownagefool</author><text>I&amp;#x27;d say it&amp;#x27;s actually just a convention vs configuration argument.&lt;p&gt;Kubernetes isn&amp;#x27;t giving you anything you couldn&amp;#x27;t have already built with configuration management.  It just happens to a standard written by a bunch of people with a background in the problem domain.&lt;p&gt;Personally, I think the abstractions are thoughtful and the system isn&amp;#x27;t really inherently more complicated than what you&amp;#x27;ll eventually build anyways, but as the article said, we all have a bias towards that crap we ourselves invented, because we already know how that works, and we find learning something like kubernetes a chore.&lt;p&gt;That said, I wouldn&amp;#x27;t say it&amp;#x27;s about how many servers you manage.  If you have a single monolith, written and ran by a single team, it doesn&amp;#x27;t neccessairly get more complex as you throw more servers at it.  But when you have several teams, writing and hosting several systems, it&amp;#x27;s nicer to have a convention framework instead of an undocumented snowflake platform.&lt;p&gt;I have to agre on your final point though.  If you find running kubernetes complicated, go to GKE and treat it like you do your IaaS provider, which is more complicated but isn&amp;#x27;t something you typically deal with.</text></item><item><author>hacknat</author><text>Right tool for the right job. Is K8s too complicated? For some use cases it is.&lt;p&gt;They probably should do a better job of discouraging certain use cases, but calling their elevator pitch “bullshit” is hyperbolic.&lt;p&gt;There are exceptions to every rule, but a good rule of thumb is cluster size. If you’re managing less than 25 servers than K8s is &lt;i&gt;probably&lt;/i&gt; over kill. As you start to creep north of 40 servers K8s really starts to shine. The other place K8s really shines is dynamic load. I manage anywhere from 600-1000 16Gb VMs, I can’t imagine doing it without K8s.&lt;p&gt;If cluster size isn’t a good rule of thumb then application architectur probably is. If no one person in you company has a complete mental model of the application architecture or it is impossible because it is so complex, again container orchestration might be a good way to go.&lt;p&gt;Final point:
If you’re struggling with K8s swallow your pride and buy a managed solution, then learn as you go.</text></item></parent_chain><comment><author>devonkim</author><text>And there’s two sides to the equation - even if you have a world class orchestration platform if your application architecture is extremely stateful and can’t tolerate certain services being down the platform can not help. Most places I’ve observed (large and small) simply do not write software in a manner that can be containerized effectively. The abstractions and patterns developers have as a default in most languages tends toward system designs (emergent) where people as a rule write and cache files locally, datastores are expected to stay up forever and never change hostnames, and that service discovery is “too complicated” to ever use.</text></comment>
<story><title>Is K8s Too Complicated? ￼</title><url>http://jmoiron.net/blog/is-k8s-too-complicated/</url></story><parent_chain><item><author>majewsky</author><text>&amp;gt; Kubernetes isn&amp;#x27;t giving you anything you couldn&amp;#x27;t have already built with configuration management.&lt;p&gt;Configuration management does not give you loadbalancing. Configuration management does not give you rolling upgrades.&lt;p&gt;I mean, sure, you can do this stuff with CM as well, but with k8s, there&amp;#x27;s nothing to build. It&amp;#x27;s already there</text></item><item><author>ownagefool</author><text>I&amp;#x27;d say it&amp;#x27;s actually just a convention vs configuration argument.&lt;p&gt;Kubernetes isn&amp;#x27;t giving you anything you couldn&amp;#x27;t have already built with configuration management.  It just happens to a standard written by a bunch of people with a background in the problem domain.&lt;p&gt;Personally, I think the abstractions are thoughtful and the system isn&amp;#x27;t really inherently more complicated than what you&amp;#x27;ll eventually build anyways, but as the article said, we all have a bias towards that crap we ourselves invented, because we already know how that works, and we find learning something like kubernetes a chore.&lt;p&gt;That said, I wouldn&amp;#x27;t say it&amp;#x27;s about how many servers you manage.  If you have a single monolith, written and ran by a single team, it doesn&amp;#x27;t neccessairly get more complex as you throw more servers at it.  But when you have several teams, writing and hosting several systems, it&amp;#x27;s nicer to have a convention framework instead of an undocumented snowflake platform.&lt;p&gt;I have to agre on your final point though.  If you find running kubernetes complicated, go to GKE and treat it like you do your IaaS provider, which is more complicated but isn&amp;#x27;t something you typically deal with.</text></item><item><author>hacknat</author><text>Right tool for the right job. Is K8s too complicated? For some use cases it is.&lt;p&gt;They probably should do a better job of discouraging certain use cases, but calling their elevator pitch “bullshit” is hyperbolic.&lt;p&gt;There are exceptions to every rule, but a good rule of thumb is cluster size. If you’re managing less than 25 servers than K8s is &lt;i&gt;probably&lt;/i&gt; over kill. As you start to creep north of 40 servers K8s really starts to shine. The other place K8s really shines is dynamic load. I manage anywhere from 600-1000 16Gb VMs, I can’t imagine doing it without K8s.&lt;p&gt;If cluster size isn’t a good rule of thumb then application architectur probably is. If no one person in you company has a complete mental model of the application architecture or it is impossible because it is so complex, again container orchestration might be a good way to go.&lt;p&gt;Final point:
If you’re struggling with K8s swallow your pride and buy a managed solution, then learn as you go.</text></item></parent_chain><comment><author>SEJeff</author><text>Configuration management absolutely can do this. Note that I&amp;#x27;m a builder of kubernetes clusters (on-premise) but also have contributed 400+ patches to the salt configuration management tool.&lt;p&gt;Salt has an &amp;quot;orchestrate layer&amp;quot;[1] which allows running states on sets of minions. One of those layers can be to configure a service, and another can be to update the load balancers when said service is healthchecking green. Saying these things simply can&amp;#x27;t be done with configuration management is utterly false. Kubernetes just makes it easier and more approachable for those less skilled in under the covers systems and infrastructure stuff. Kubernetes is a tool that allows you to build things quickly, but it isn&amp;#x27;t for everyone.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.saltstack.com&amp;#x2F;en&amp;#x2F;2017.7&amp;#x2F;topics&amp;#x2F;orchestrate&amp;#x2F;orchestrate_runner.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.saltstack.com&amp;#x2F;en&amp;#x2F;2017.7&amp;#x2F;topics&amp;#x2F;orchestrate&amp;#x2F;orch...&lt;/a&gt;</text></comment>