3 ms·

> OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools True but consider this - there used t

> OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools True but consider this - there used to be people whose job it was to do most of that stuff and the app developers did not have to think about it for the most part. Kubernetes/OpenShift just moved all of the complexity on the developer's plate - and the mind numbing stuff that results from that is worthy of few articles. And to say most developers have no way to actually run this at their home and become familiar with the intricacies is even more asinine. This isn't a OpenShift/K8s critique per se but the whole idea that you can somehow make all the complexity disappear by writing more software and more abstractions and then let the developers deal with all things that organizations failed to account for in the need for cheap and fast - it doesn't really work all that well.

acdha 6y ago
> > OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools > True but consider this - there used to be people whose job it was to do most of that stuff and the app developers did not have to think about it for the most part. Kubernetes/OpenShift just moved all of the complexity on the developer's plate - and the mind numbing stuff that results from that is worthy of few articles Ignoring OpenShift, I don't think the comparison is quite that simple because it's leaving out all of the drawbacks from that traditional approach. Instead of writing a few lines of YAML you have to wrangle time and support from central IT, debugging is often a multi-party finger-pointing exercise with access limitations, and because you're talking about separate services and usually hardware changes and updates are hard because they need to be coordinated across multiple applications and teams. That's not saying that there aren't legitimate areas for concern but I've seen fairly large amounts of developer time and downtime go into working around the limitations of that model (“<vendor> isn't compliant with this 15 year old RFC so we need to distribute forks of these 15 common tools for years until we can replace those $$$ appliances”).
- blinkingled 6y ago
  I have thought a lot about this - I have and do work with a ton of apps across number of clients. The stated benefits of K8s/OpenShift are negated by the complexity that it brings for most of those apps - especially when they don't need or use any of the sophisticated features of K8S. If your central IT knows anything about Automation / DevOps you should not be wrangling time with them at all. It is easy peasy to setup Jenkins/Ansible/Tower based self service workflow for automating deployment and other things. Most enterprise apps do not need autoscaling, or weird unsupported OSes and libraries - JVM and CLR solved that problem long time ago. If you did it right horizontal scaling any app server should be a piece of cake if and when that one time you actually need it. If you do need specific OS versions/libs - just use plain old docker - that's much less complicated and at least serves a purpose. The point I am trying to make is - very few classes of apps can benefit from the added complexity of K8S and you should carefully evaluate if your app can benefit from K8S specific features and your Developers/Ops team are ready to deal with the complexity they are signing up for.
  - acdha 6y ago
    Your experience is rather unlike mine — especially the belief that central IT departments are advanced devops practitioners. Similarly, you're talking about a significant amount of work maintaining bespoke infrastructure duplicating what systems like Kubernetes, OpenShift, Nomad, etc. do but taking on the responsibility for integrating and supporting all of those disparate parts yourself, not to mention getting the policy, security, and operational go-ahead to do so. “Easy peasy” does not match my experience with that approach but I'm glad it's working well for you.
    - blinkingled 6y ago
      Compared to maintaining a OCP cluster? Sure it is easy peasy - I can vouch for that having done both.
    - freedomben 6y ago
      I have had a similar experience. It's certainly easily to grok the architecture when it's traditional and simple, but it's significantly more work when every app follows a different pattern (which tends to happen in bespoke infrastructure). I've done both and while I agree with the gp that k8s is overkill for a lot of apps, there's still a lot of value in having patterns and consistency. When you can go from Service A to Service B and know that it's laid out similar, the cognitive overhead of managing several or dozens of services goes way down.

acdha 6y ago

> > OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools > True but consider this - there used to be people whose job it was to do most of that stuff and the app developers did not have to think about it for the most part. Kubernetes/OpenShift just moved all of the complexity on the developer's plate - and the mind numbing stuff that results from that is worthy of few articles Ignoring OpenShift, I don't think the comparison is quite that simple because it's leaving out all of the drawbacks from that traditional approach. Instead of writing a few lines of YAML you have to wrangle time and support from central IT, debugging is often a multi-party finger-pointing exercise with access limitations, and because you're talking about separate services and usually hardware changes and updates are hard because they need to be coordinated across multiple applications and teams. That's not saying that there aren't legitimate areas for concern but I've seen fairly large amounts of developer time and downtime go into working around the limitations of that model (“<vendor> isn't compliant with this 15 year old RFC so we need to distribute forks of these 15 common tools for years until we can replace those $$$ appliances”).

blinkingled 6y ago
I have thought a lot about this - I have and do work with a ton of apps across number of clients. The stated benefits of K8s/OpenShift are negated by the complexity that it brings for most of those apps - especially when they don't need or use any of the sophisticated features of K8S. If your central IT knows anything about Automation / DevOps you should not be wrangling time with them at all. It is easy peasy to setup Jenkins/Ansible/Tower based self service workflow for automating deployment and other things. Most enterprise apps do not need autoscaling, or weird unsupported OSes and libraries - JVM and CLR solved that problem long time ago. If you did it right horizontal scaling any app server should be a piece of cake if and when that one time you actually need it. If you do need specific OS versions/libs - just use plain old docker - that's much less complicated and at least serves a purpose. The point I am trying to make is - very few classes of apps can benefit from the added complexity of K8S and you should carefully evaluate if your app can benefit from K8S specific features and your Developers/Ops team are ready to deal with the complexity they are signing up for.
- acdha 6y ago
  Your experience is rather unlike mine — especially the belief that central IT departments are advanced devops practitioners. Similarly, you're talking about a significant amount of work maintaining bespoke infrastructure duplicating what systems like Kubernetes, OpenShift, Nomad, etc. do but taking on the responsibility for integrating and supporting all of those disparate parts yourself, not to mention getting the policy, security, and operational go-ahead to do so. “Easy peasy” does not match my experience with that approach but I'm glad it's working well for you.
  - blinkingled 6y ago
    Compared to maintaining a OCP cluster? Sure it is easy peasy - I can vouch for that having done both.
  - freedomben 6y ago
    I have had a similar experience. It's certainly easily to grok the architecture when it's traditional and simple, but it's significantly more work when every app follows a different pattern (which tends to happen in bespoke infrastructure). I've done both and while I agree with the gp that k8s is overkill for a lot of apps, there's still a lot of value in having patterns and consistency. When you can go from Service A to Service B and know that it's laid out similar, the cognitive overhead of managing several or dozens of services goes way down.