4 ms·

I'd say it's actually just a convention vs configuration argument. Kubernetes isn't giving you anything you couldn't have already built with configuration mana

I'd say it's actually just a convention vs configuration argument. Kubernetes isn't giving you anything you couldn'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. Personally, I think the abstractions are thoughtful and the system isn't really inherently more complicated than what you'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. That said, I wouldn't say it's about how many servers you manage. If you have a single monolith, written and ran by a single team, it doesn't neccessairly get more complex as you throw more servers at it. But when you have several teams, writing and hosting several systems, it's nicer to have a convention framework instead of an undocumented snowflake platform. 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't something you typically deal with.

majewsky 8y ago
> Kubernetes isn't giving you anything you couldn't have already built with configuration management. Configuration management does not give you loadbalancing. Configuration management does not give you rolling upgrades. I mean, sure, you can do this stuff with CM as well, but with k8s, there's nothing to build. It's already there
- deleted 8y ago
  [deleted]
- toomuchtodo 8y ago
  You're trading operational complexity in other areas for arguable operational functionality that CM of haproxy (or perhaps Microsoft's load balancer if you need UDP LB services) already provides for, in software that is still under active development and has sharp edges. Your systems should be as simple as possible, but no more simple than that. Kubernetes is not turnkey and requires a significant operational time and resource commitment. Prepare accordingly.
- user5994461 8y ago
  Ansible gives both of that.
- ownagefool 8y ago
  That's the point of convention vs configuration argument but we're on the same side of the argument. :)
- devonkim 8y ago
  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.
- SEJeff 8y ago
  Configuration management absolutely can do this. Note that I'm a builder of kubernetes clusters (on-premise) but also have contributed 400+ patches to the salt configuration management tool. Salt has an "orchestrate layer"[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'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't for everyone. [1] https://docs.saltstack.com/en/2017.7/topics/orchestrate/orchestrate_runner.html https://docs.saltstack.com/en/2017.7/topics/orchestrate/orch...
  - barrkel 8y ago
    It's not about skill and approachability; it's about not having tens of thousands of systems in different companies built out of hacks and science experiments, where experience isn't portable and every system's hacks and idiosyncrasies need to be learned anew. K8s raises the abstraction level on deployment of a multi-node application architecture. Further, as it builds out standard abstractions for external services, it should enable applications to be written agnostic as to the specific cloud provider. That's pretty valuable. It has the potential to reduce AWS's lock-in advantage.
    - SEJeff 8y ago
      Yes, I'm aware and you're preaching to the choir. I'm literally the lead on $employer's k8s deployment. I was just pointing out that things like k8s can absolutely be done reliably with old school bare metal and config management + some orchestration glue. Only it isn't as simple for most and generally is done poorly. I'm a huge fan of k8s.
merb 8y ago
> If you have a single monolith, written and ran by a single team, it doesn't neccessairly get more complex as you throw more servers at it. In which world does our monolith only connect to a database that is hosted on a single node ;) Most often we have at least 3 database nodes 3 x nodes, 3 redis nodes, whatever. even when we run everything on vms instead of bare metal instances (for which k8s even works) we would still need to manage them and create an insane amount of work to manage/keep them running. in the worst case people would ssh into them

majewsky 8y ago

> Kubernetes isn't giving you anything you couldn't have already built with configuration management. Configuration management does not give you loadbalancing. Configuration management does not give you rolling upgrades. I mean, sure, you can do this stuff with CM as well, but with k8s, there's nothing to build. It's already there

deleted 8y ago
[deleted]
toomuchtodo 8y ago
You're trading operational complexity in other areas for arguable operational functionality that CM of haproxy (or perhaps Microsoft's load balancer if you need UDP LB services) already provides for, in software that is still under active development and has sharp edges. Your systems should be as simple as possible, but no more simple than that. Kubernetes is not turnkey and requires a significant operational time and resource commitment. Prepare accordingly.
user5994461 8y ago
Ansible gives both of that.
ownagefool 8y ago
That's the point of convention vs configuration argument but we're on the same side of the argument. :)
devonkim 8y ago
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.
SEJeff 8y ago
Configuration management absolutely can do this. Note that I'm a builder of kubernetes clusters (on-premise) but also have contributed 400+ patches to the salt configuration management tool. Salt has an "orchestrate layer"[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'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't for everyone. [1] https://docs.saltstack.com/en/2017.7/topics/orchestrate/orchestrate_runner.html https://docs.saltstack.com/en/2017.7/topics/orchestrate/orch...
- barrkel 8y ago
  It's not about skill and approachability; it's about not having tens of thousands of systems in different companies built out of hacks and science experiments, where experience isn't portable and every system's hacks and idiosyncrasies need to be learned anew. K8s raises the abstraction level on deployment of a multi-node application architecture. Further, as it builds out standard abstractions for external services, it should enable applications to be written agnostic as to the specific cloud provider. That's pretty valuable. It has the potential to reduce AWS's lock-in advantage.
  - SEJeff 8y ago
    Yes, I'm aware and you're preaching to the choir. I'm literally the lead on $employer's k8s deployment. I was just pointing out that things like k8s can absolutely be done reliably with old school bare metal and config management + some orchestration glue. Only it isn't as simple for most and generally is done poorly. I'm a huge fan of k8s.

merb 8y ago

> If you have a single monolith, written and ran by a single team, it doesn't neccessairly get more complex as you throw more servers at it. In which world does our monolith only connect to a database that is hosted on a single node ;) Most often we have at least 3 database nodes 3 x nodes, 3 redis nodes, whatever. even when we run everything on vms instead of bare metal instances (for which k8s even works) we would still need to manage them and create an insane amount of work to manage/keep them running. in the worst case people would ssh into them