92 lines
3.4 KiB
Markdown
92 lines
3.4 KiB
Markdown
---
|
|
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
|