4 ms·

Any sufficiently complicated Docker Swarm, Heroku, Elastic Beanstalk, Nomad or other program contains an ad hoc, informally-specified, bug-ridden,

• ori_b 3y ago
  Unfortunately, the above statement also applies to kubernetes.
  • amazingman 3y ago
    A pithy response to be sure, but is it true? Every Kubernetes object type exists within a well-specified hierarchy, has a well-specified specification, an API version, and documentation. Most of the object families' evolution are managed by a formal SIG. Not sure how any of that qualifies as ad-hoc or informal.
    • ori_b 3y ago
      "It's not a mess! it was designed by committee!" I'm not sure what to say here. The kubernetes docs and code speak for themselves. If you actually think that it's clean, simple, well designed, and easy to operate, with smooth interop between the parts, I can't change your mind. But in practice, I have found it very unpleasant. It seems this is common, and the usual suggestion is to pay someone else to operate it.
      • amazingman 3y ago
        First you were complaining that it was ad hoc and informal. Now you seem to be complaining that it's too formal and designed by committee. Also I never said Kubernetes was well-designed, easy, or simple.
        • ori_b 3y ago
          You say that as though bureaucracy is equivalent to formalism. It's not.
  • mardifoufs 3y ago
    Kubernetes is anything but adhoc. That's the best thing, but can also be the most annoying, part about it
• wg0 3y ago
  Most smaller teams do not need a full fledge kubernetes anyways. There's no one size fits all approach. There are trade offs. The Kubernetes tractor needs lots of oiling and what not for all the bells and whistles. Trade offs is the keyword here.
• ChoHag 3y ago
  [dead]