Wanted to get some thoughts on <https://musings.ma...
# platform-culture
a
Wanted to get some thoughts on https://musings.martyn.berlin/internal-developer-platforms-idps-are-anti-devops I feel he has a point but then abstractions are there when the complexity grows. For me its about making the abstraction/platform observable, then developers can have real insight into how to own and operate their service. I feel I'm preaching to the choir here but wanted opinions on those who have abstracted away platforms, can teams still build it and own it?
h
I agree with his points about devops, but I think he confused things a bit, backstage is a internal developer portal ie: it aggregates info from various tools in a single pane of glass ( you still have direct access to those tools if you wish ), humanitec would most likely be considered a internal developer platform ( And while there might be some abstraction you can still access helm etc. ), I do agree with him on the point if your going to do abstraction but not give access to the underlying bits and bobs thats bad, but from what I have seen most developer platforms have escape hatches for that so to speak to expose the underlying infra. TLDR: He has a point but could have expanded on it a bit better.
b
He might have a point but it's all a bit to general, I'd love to hear more details on several points. I agree with @Hugo Pinheiro as I think he is saying that that tools as Backstage are never meant to be a totalitarian solution for DevOps. It's a part of the solution and delivering integrated paved road / Golden Path solutions does help teams. DevOps is a culture, Platforming is a culture. The whole People, Process, Technology actually puts the whole technology part at the end for a good reason. So I think it's a bit easy to rant on these platform tooling as if they were the only thing an IDP would deliver. I feel everything should be open for developers to join in and make the whole IDP a joint effort.
a
Agree on that point, we have been delivering solutions but involving our users as much as possible so they learn the ins and outs of the platform and how to go deeper if they need and customize it
f
I agree with point 3:
Developers who understand how their application runs in production are better developers
Specifically this sentence:
I'm all for standardisation and speed, but not at the expense of understanding.
Apart from point 1 and 2, the rest of the article seems to be about the balance between abstractions an IdP provides and knowledge it can hide. I think the author misses the whole product approach to an IdP. And IMO, adopting a platform engineering culture does not mean abstracting everything away. ---
[...] can teams still build it and own it?
I believe one of the greatest challenge in introducing this culture is making sure to maintain a good cognitive load/knowledge balance. Making sure everyone maintains a common knowledge of what they build and operate requires deliberate practice and investment: allocated time, training, teaching and support from the platform team(s), etc. So yeah, I think it is achievable and even desirable. And I would go further by stating that it is essential when deploying a Platform engineering culture.