Anyone here built an internal dev platform that people used?

3 points by DeborahEmeni_ 1 year ago | 4 comments

I’ve seen a few teams build internal dev platforms with great intentions: standardized tooling, faster onboarding, less cognitive load. But adoption often seems like the hardest part.

Would love to hear what worked (or didn’t) for folks here. Did you build it from scratch or stitch together existing tools? Was usage organic or did you have to push it hard internally? Any lessons on what made people actually use it?

Also open to stories where it didn’t work out. Did you end up switching to an off-the-shelf option later?

kamrahnach 1 year ago |

not sure if this is precisely what the questioner is after but will share anyhow. have developed something like this two times. both combine oss solutions with some custom tooling.

1. setup a platform using jupyterhub on kubernetes * use case leans towards research and mixed research-dev workflows * user only requires browser installed locally * jupyterhub server selection menu is configured such that * user selects container image to spawn from: these are usually built per project tool chain * user selects node type to run on: for example if user needs gpu resources, then can schedule onto cluster node with gpu devices attached 2. setup a platform that integrates monorepo with vscode devcontainer * use case focuses on developers * requires vscode, docker installed locally * monorepo contains a collection of subprojects for running services and jobs * each subproject define its own devcontainer settings * these follow common patterns per runtime and runtime version needed for project * devcontainer images are pre-built and maintained in onprem container registry

DeborahEmeni_ 1 year ago | |

thanks for sharing this. really interesting seeing the jupyterhub setup combined with devcontainers. curious how usage went long term. did people keep using it without needing much hand-holding, or was it more of a “power users only” kind of thing?

also appreciate the note on the sister team. i’ve seen the same. lots of energy up front but adoption fizzles when teams don’t prioritize the boring stuff like docs and onboarding

mmarian 1 year ago |

Haven't built, but seen it happen in a sister team. They over-planned, instead of taking a startup-like approach and focusing on the low-hanging fruit. Hasn't been successful.

DeborahEmeni_ 1 year ago | |

appreciate the context. do you know if the platform itself didn’t meet dev needs, or was it more about rollout and team buy-in?