3 ms·

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 comple

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

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.