This message was deleted.

➕bump for the question to @Paula Kennedy

I’m not the speaker for these talks, but IMO the answer to

Why isn’t platform as the product already the standard and common knowledge

Is that companies don’t want to fund it. They may be happy to pay for building or buying the platform itself, but are more reluctant to pay for the on-going support, evangelism, and all the work required for an org to fully adopt a platform. They don’t want to pay for the equivalent of sales reps and customer solutions engineers to help teams implement and adopt the platform.

For the second question, I’m also not the speaker, but my take…

providing them with a guided, user-friendly platform but also not overloading them

Yep, I think a happy medium is in providing access to k8s (and really, all kinds of internal tooling) through an internal developer portal. k8s is great, but you’re right, it’s a super wide interface and adds to cognitive load of engineers. For engineers that want to dive in to that complexity, go for it. But for everyone else, making the most common use cases for k8s easily discoverable / accessible can help make k8s more approachable and everyone more productive. (some examples of those use cases: UI to see/filter the list of pods and their status, scale up/down the number of pods, request more CPU/mem, etc.)

I am also not the speaker but I think this is too easy an explanation @Dave Thompson. We've been talking about platform as a product for what 3-4 years now? Sure, that isn't enough time for something to become the default - but if what every PAAP evangelist says is true, then platform as a product is a huge velocity driver. And velocity = profit. So there should be at least SOME degree of buy in. But where is it? I think it has to go beyond just not wanting to invest. We all know how much enterprises love to spend on internal trainings and materials....

@Neyan Kevek depends on the size of enterprise 3 to 4 years isn't that long to make a large cultural change in say a large bank with tens of thousands of employees

I think it's the difference between seeing internal folks as customers, partners, or "those darn users who keep annoying us" https://friendgineers.rosenshein.org/posts/2022/07/28/

@Neyan Kevek There is often also a gap where the teams building or supporting “platforms” don’t necessarily have any product experience. Ops/Devops teams that have been tasked with supporting platforms are built around supporting systems rather than customers. They don’t have any infrastructure/process/expertise in place to engage with teams as customers, gather feedback and make product updates, etc.

Hey @Sam Bar thanks for the question and sorry for delayed response … I think it’s probably not the default because it’s just not the natural path through which many platform teams come into being. Platform/infra/DevOps teams can often evolve out of necessity and assembled rather quickly to “sort out all that annoying infrastructure stuff for the devs, and make sure they do things properly”- but at that point (regardless of what the team is called) it’s not really seen as a “product” yet, more as a team which does stuff to help devs and help with specific tasks like compliance etc - and we treat them like a cost centre. it takes quite a mindshift change to recognise your developers as your real customers in this case. as I point out the in talk and @Leon Rosenshein mentions, we also tend to fall into the trap of not treating our “internal customers” the way we would a normal customer, we make assumptions, don’t involve them in decisions and then the whole thing doesn’t quite work out … hope that helps a bit!!

@Nicki Watt thanks for your talk, I especially appreciated the comments around optional vs mandatory and monoplatform vs multi.

Thanks for the question @Sam Bar, and you’re spot on when you say we can’t expect every dev to master Kubernetes. @Kenneth Rose's comments are also great as it is absolutely about providing a balance for those engineers who want to deep dive into fundamentals vs. those who want a higher abstraction. The patterns that we’ve seen emerging are around platform teams providing “golden paths” or abstractions that can remove the complexity for the majority of users who don’t want to get down in the Kubernetes weeds, but also ensuring there is a “break-out” option for devs to dig in if they want to. This might look like a golden path that incorporates several tools together e.g. a dev environment as-a-service, but a separate path for users or teams to request individual lower level components such as a Kubernetes namespace that they can configure to their specific requirements. With this type of approach, the platform team is aiming to meet a high percentage of use cases with the “standard golden path” but also offer those with more niche use cases the opportunity to fine tune certain elements.