3.4 KiB
3.4 KiB
title, weight, tags
| title | weight | tags | |
|---|---|---|---|
| Many Cooks, One Platform: Balancing Ownership and Contribution for the Perfect Broth | 4 |
|
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