Hacker News Reader

Comment by outside1234 | Hacker News Reader

I think actually the middle way is the best. This is when you have a central platform that is operated by a Platform Team that App Teams can use to deploy their workloads -- but that the App Teams are expected to observe and monitor their own app to make sure it is healthy.

This way each individual App Team doesn't have to become a PhD at Kubernetes and the Platform Team (aka "Ops") doesn't have to become a PhD at 50 different apps.

View on HN

My fear with this is always that the platform team stops building a platform that is particularly useful. "The Platform" becomes the important thing to them instead of the product it delivers. It's also a good way for the platform team to get viewed as a cost center.

All valid points.

I agree. Provide a managed pattern that’s good enough for most things. An “on-road” way to deploy and operate. The devs don’t need to worry about designing and janitoring anything but their application.

Of course… the “platform” can and probably will become crap over the long run. Or it’s too doctrinaire and opinionated inflexible and new people don’t like it. Then you end up with alternative platforms popping up over the years, and now there’s multiple ops teams working in different silos (legacy and new etc) and eternal migrations. The circle of life!

Yeah, it's kinda inevitable that "the platform" will need rebuilding again and again, because who want to touch that N-1 version that's all yucky and icky.

Reply on news.ycombinator.com