Hey platform engineers, I watched <@U02H30PA00P> s...
# generalj
JKleinlercher
02/11/2022, 10:40 PMHey platform engineers, I watched @Kaspar s talk about DevOps benchmarking 2022 and the need and rise of IDPs and internal platform teams. I wonder if really every organisation needs to build their own platform and needs to build a platform team or if companies can just buy powerful platforms with all the principles inluded mentioned in the talk (or just use public PaaS offerings). Totally agree that a managed K8s cluster by itself is far too complex for stream-aligned app teams and cognitive load would be too high. Even cloud services directly from GCP, AWS or Azure are probably sometimes too complex (or just too many possibilities and no golden paths) However, platforms with great CD tools, observability, security, multi-cluster/cloud aware, good abstraction APIs (like KubeVela) and all on top of K8s sounds like a pretty rich platform which could probably be built by PaaS-providers and just used by other companies dev teams?
What is your experience here? Would you still need your own self-made platform and internal platform team? Which features would you need from a PaaS provider? Or do you already use an off-the-shelf PaaS as your IDP?
a
Andrew Fong
02/12/2022, 2:36 PMHow do you think about the “knobs” - in my experience most of the knobs aren’t needed. If there were just simple workflows that worked for “app types” would that be good enough?
s
Suzanne Daniels
02/14/2022, 9:47 AM.
Suzanne Daniels
02/14/2022, 9:59 AMEven if you dedicate yourself to this one cloud provider offering the technology stack you need, it probably won't solve enough of the challenges. I do think it's a sane investment to "move up the stack" towards paas services for most companies, for many reasons.
But it doesn't, in itself, provide the solution to all challenges. I'd even argue it would add challenges but on another level.
Then the second part about IDP's : There's need for findable documentation and to have a certain level of abstraction for developers. Also, the cloud provider will likely continuously change/improve their services, which can add to the chaos.
Then comes the other components like CI/CD, observability etc,etc. Most likely either from another vendor and/or have a different look & feel.
Having a single consistent interface where you bring all of your tech stack, tools, observability together without actually replacing all these tools is, in my opinion, a great investment.
Building your own portal is in general expensive, labour intensive, and difficult to maintain. So leveraging this as SaaS or self-hosted solutions could take away many concerns.
One of these developer portal solutions is Backstage. It's an Open Source platform where you could build your developer portal on top of, using plugins. You can check it out here: https://backstage.io (disclaimer: I do DevRel for backstage)
🙌 2
k
Kaspar
02/14/2022, 12:59 PMHey everybody, I gave the talk 🙂
ON the debate of whether you need a platform team to do this I'm not sure I follow your point. What you want to have is consistency and something that drives standardization. It makes sense to have one team looking at this. If you have everybody look at this by definition you don't get much standardization and it becomes pretty pointless.
On the tech used:
I'm not a huge fan of generalizing. If you believe Kubevela can do what you need that's what you should use. I've seen it in action, I do not believe it scales across larger teams. On self-build in general: I honestly have not seen the return of self-build setups too often but I think it's unproductive to try pushing people into a certain offering.
Where I do have a very strong opinion is where you should focus your time when building these. And you should be very clear where you focus your time. In my opinion focussing on things like user onboarding, service templating and documentation is not where the actual return lies (unless you're a global tech player with X new services a week). The actual return is in the daily self-service of developers. @Lee Ditiangkin wrote a great article on this: if you put a pane of glass on a pile of shit, you're developers see a pile of shit.
🤔 1
Kaspar
02/14/2022, 1:00 PMBut happy to discuss this in more depth, @JKleinlercher
a
Andrew Fong
02/14/2022, 1:46 PMI can say as someone that has both been an operator and exec in global tech players X new services doesn’t really happen that much either. We found we had 1-2 a month at Dropbox. What helped us a lot more was having a set of technology principles which started with “Consistency above all else.” Launching IMO is the easy part, its a 1 time cost. The hard part is maintaining and moving the organization (we were ~1k developers) along over time. The abstraction is key here and is why I ask the question around knobs. I believe there’s probably a small set of knobs that most non-horizontally scaled organizations need. Most apps never reach humanity scale and even then they aren’t “complex” - they are in fact really simple and easy to reason about when done right
👍 1
Andrew Fong
02/14/2022, 1:47 PMGiving up the knobs are hard but I think if platforms are to evolve and for this set of operators to focus on providing maximal business value (esp in non-pure tech companies) that has to happen
🙌 1
28 Views