---
title: "Many Cooks, One Platform: Balancing Ownership and Contribution for the Perfect Broth"
weight: 4
tags:
 - platform
---

<!-- {{% button href="https://youtu.be/rkteV6Mzjfs" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}} -->
<!-- {{% button href="https://docs.google.com/presentation/d/1nEK0CVC_yQgIDqwsdh-PRihB6dc9RyT-" style="tip" icon="person-chalkboard" %}}Slides{{% /button %}} -->

Not unlike a war story talk about trying to make a product work at a gov organization in the netherlands.

## Tech stack

- OpenShift migrating to a new WIP platform (WIP for 2 years)
- 4 Clusters (2x DEV, 1xPROD, 1xMGMT)
- Azure DevOps for application delivery

## Org

- IT Service Provider for the durch juduciary - mostly building webapps
- Value Teams: Cross functional (Dev, Testing, Ops) with a focus on java and C#
- Bases (aka Worstreams): Container Management Platform Base is the focus on this story

## Why platform?

### Where we came from

- The old days: Deployment Scripts
- Evolution: Loosely coupled services like jenkins -> Loose interactions make for fun problems and diverging standards
- The new hot stuff: Platform that solves the entire lifecycle

### The golden Path

subgraph IDP
    DeployService-->triggers|BuildService
    BuildService<-->|Interact with code|RepositoryService
    BuildService-->|pushes image to|Registry
    DeployService-->|deploy to|Prod
end
Prod

TODO: Steal image from slides


### Bricks vs Builds

- Brick: Do it yourself
- Build: Ready to use but needs diverse "implementations"

## Vision and scope

- Problem(scope): Not defined scope results in feature-wish creep
- Problem(scope): Things being excluded that feel like they should be part of a platform -> You now have the pleasure of talkint to multiple departments
  - Old platform used an internal registry -> Business decided we want artifactory -> HA Artifactory costs as much as the rest of the platform
  - The company decides that builds now run in Azure DevOps
- Problem(vision): It's easy to call a bunch of services "a platform" without actually integrating them with each other

## DevOps is an Antipattern

- Classic: Developers are seperated from Ops by a wall of confusion
- Modern™: Just run it yourself! How? I'm not gonna tell you
- Solution™: Add an Enabling Team between Dev and Platform
- Problem: This usually results in creating more work for the platform team that has to support the enabling team in addition
- Solution: The enabling team should be created out of both dev and ops people to create a deep understanding -> Just build a communiuty

## Comunity building

- Cornerstones: Conmsistency (same time, same community), Safe to ask questions (Vegas rule), Aknowledge both good and bad/rant, Follow up on discussions

### Real World Example: SRE Meetup

> Spoiler: This failed

- Every team was asked to send one SRE
- Meeting tends to get cancelled one minute before due to "nothing to discuss"
- Feels like the SREs have ideas or greviances and the platform team defends itself or attacks the asker of questions
- Was replaced

### Real Workd Example: The Microservice Guild

- Contribution via Invitation: Hey I heard you built something cool, please tell us about it
- Agenda always share in advance
- Focus on solutions instead of offense/defense

## Summary

- A Platform is a colaborative effort
- Scope has to be communicated early and often
- Build a community
- Sometimes you need to let things go if they don't work out