Hi everyone! From what I read and watch, almost everyone talking about IDP in the context of automation, infrastructure, deployments, cloud, security or policies. I see a lack of good materials about IDP in the context of DEV tooling - I mean libraries and services which provide some standards and good practices on application level, solving cross-cutting problems. I wonder, how in your platforms and companies this look like? Do you have in your platforms software engineers which are integrated part of platform and provide application toolbox for devs in other teams?

You should pay a visit to our website https://mogenius.com/product and https://docs.mogenius.com/. The features you mentioned at first are a very important part of an IDP as it bridges the gap between the Dev world and the cloud native one for many enterprises. But you are right, an IDP mostly makes sense if it can offer developers an extended environment with blueprints and the ability to template your own best practices.

From my perspective tooling for devs on application level is really important. My platform team has strong focus on that. With them, you can create more powerful solutions, but also speedup significantly development of products. In the end - how often we create services or spin up a new environment - and how often you do just a service development? A new feature? Support for messaging, logging, metrics, feature flags, Configuration, creating processes (state machines), meta data's and so on allow developers to focus on essence, not to solving each time from new a common problems.

Sure, both DEV tooling and IDP are indispensable to improve developer experience. Projects like Dapr、Prometheus are really essential.

A team I worked on was doing this a while back and we used to supply packages (NuGet, Maven, NPM, etc) that would be easy to "snap in" and use. For example, we had a package to be used for exceptions. You added the package and created sub-classes for any exceptions you wanted to raise. Each time an exception was raised, the base class made sure the exception was logged to our monitoring platform. One package + a wiki page to show how to use it massively improved our understanding of our application in production. We did the same with many other cross-cutting concerns, as this made it really easy for the wider team to use them, provided a simple update mechanism (the package manager told them when there was an update). Not all platforms have to be a giant effort. Open source gives us some inspirational ideas.

Have similar thing in my team/product. We have many internal libraries, which solves cross-cutting concerns. From my perspective this is a HUGE boost for developers. They can spin new functionalities and services much more quicker/safer/fluently. Of course, there is a challenge to balance between what is a neccessery, what is a tool, and what we don't care (as platform). And there are also a tradeoffs - because you make more coupling on libraries level, it's easier to make a mistake (imagine global package, which all services use, and you brake something in it - you don't have an easy mechanism to rollback). Rolling core functionalities also is challenging (making everyone to update immidietely is almost impossible, or at least, very absorbing). Tools like sourcegraph helps a bit with that, but still.

We initially made a mistake where we allowed our "platform" packages to reference each other, which created a dependency spaghetti... so we learned from that and made sure they were isolated. By making them packages, the team's usual "supply chain security" process should keep them updated - but of course that's an ideal view 😄

Yeah, probably they should be a single purpose, with the minimal amount of dependencies. I am finding, that treating them as open source - is very helpful 🙂

Yeah, innersource software is an emerging trend - along with everyone understanding that team design isn't about "removing all silos", but about designing interactions intentionally (i.e. Team Topologies). Open source gives us all a familiar picture of what this looks like.

Yup — done this in the past. Our developer experience team was focussed more on this level. Inner Source is a huge part of it, a lot of it is actually just nurturing tools that emerge from the development teams. We often did this by secondments of developers into the platform team to build out emerging tools. We also highlighted developers who were solving similar challenges and got them to collaborate and inner source the stuff.

Nice reading! We have similar experience 🙂 Not exactly agree with ownership of inner sources. I found that is crucial to easily contribute, and create a new set of libraries - especially by product teams, FIRST, for their needs. But in the long term, if something must have the hallmarks of a product, it is better if it is owned strictly by the platform team. Because it's not only about creating the solution but a proper design, managing the change, and selling it to developers and all staff around. We did something like that: • we have one mono-repo for "extensions libraries" - where everyone can share their idea or solution for some cross-cutting concern, even the smallest one. (contributing is really easy. No need to set up the whole repo from the beginning. Just enter your code, and the package will be published. These are packages VERY optional. It is a bag of ideas. • we have set of libraries and repos owned, developed and maintained by platform team - these are more serious and bigger functionalities, essential and very often mandatory, like: configuration, messaging, microservice template, metrics, logging, distributed tracing, feature flags and so on

Yeah, I would agree with that. To more answer your direct question, I feel the application side of platform is kinda just “regular engineering” with a splash of sophistication and governance on top, which is why I feel it doesn’t get talked about as much as compared to the more technical infra-y challenges of platform engineering. In my past experience, it looked like a constant loop of engineers creating libraries and tools, formalising those, communicating them, adopting them, encouraging engineers to maintain and support where needed, and so on. Sometimes platform work came top-down, but typically it was in collaboration with application developers.

Probably you are right. Too bad, because I think that these parts of Inner Source libraries and tools are really important, in some cases they give a significant boost to the teams, nothing to compare one time, rare action like creating a new service.