mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-25 07:46:27 +00:00
225 lines
4.3 KiB
Markdown
225 lines
4.3 KiB
Markdown
# Last words
|
|
|
|
- Congratulations!
|
|
|
|
- We learned a lot about Kubernetes, its internals, its advanced concepts
|
|
|
|
--
|
|
|
|
- That was just the easy part
|
|
|
|
- The hard challenges will revolve around *culture* and *people*
|
|
|
|
--
|
|
|
|
- ... What does that mean?
|
|
|
|
---
|
|
|
|
## Running an app involves many steps
|
|
|
|
- Write the app
|
|
|
|
- Tests, QA ...
|
|
|
|
- Ship *something* (more on that later)
|
|
|
|
- Provision resources (e.g. VMs, clusters)
|
|
|
|
- Deploy the *something* on the resources
|
|
|
|
- Manage, maintain, monitor the resources
|
|
|
|
- Manage, maintain, monitor the app
|
|
|
|
- And much more
|
|
|
|
---
|
|
|
|
## Who does what?
|
|
|
|
- The old "devs vs ops" division has changed
|
|
|
|
- In some organizations, "ops" are now called "SRE" or "platform" teams
|
|
|
|
(and they have very different sets of skills)
|
|
|
|
- Do you know which team is responsible for each item on the list on the previous page?
|
|
|
|
- Acknowledge that a lot of tasks are outsourced
|
|
|
|
(e.g. if we add "buy/rack/provision machines" in that list)
|
|
|
|
---
|
|
|
|
## What do we ship?
|
|
|
|
- Some organizations embrace "you build it, you run it"
|
|
|
|
- When "build" and "run" are owned by different teams, where's the line?
|
|
|
|
- What does the "build" team ship to the "run" team?
|
|
|
|
- Let's see a few options, and what they imply
|
|
|
|
---
|
|
|
|
## Shipping code
|
|
|
|
- Team "build" ships code
|
|
|
|
(hopefully in a repository, identified by a commit hash)
|
|
|
|
- Team "run" containerizes that code
|
|
|
|
✔️ no extra work for developers
|
|
|
|
❌ very little advantage of using containers
|
|
|
|
---
|
|
|
|
## Shipping container images
|
|
|
|
- Team "build" ships container images
|
|
|
|
(hopefully built automatically from a source repository)
|
|
|
|
- Team "run" uses theses images to create e.g. Kubernetes resources
|
|
|
|
✔️ universal artefact (support all languages uniformly)
|
|
|
|
✔️ easy to start a single component (good for monoliths)
|
|
|
|
❌ complex applications will require a lot of extra work
|
|
|
|
❌ adding/removing components in the stack also requires extra work
|
|
|
|
❌ complex applications will run very differently between dev and prod
|
|
|
|
---
|
|
|
|
## Shipping Compose files
|
|
|
|
(Or another kind of dev-centric manifest)
|
|
|
|
- Team "build" ships a manifest that works on a single node
|
|
|
|
(as well as images, or ways to build them)
|
|
|
|
- Team "run" adapts that manifest to work on a cluster
|
|
|
|
✔️ all teams can start the stack in a reliable, deterministic manner
|
|
|
|
❌ adding/removing components still requires *some* work (but less than before)
|
|
|
|
❌ there will be *some* differences between dev and prod
|
|
|
|
---
|
|
|
|
## Shipping Kubernetes manifests
|
|
|
|
- Team "build" ships ready-to-run manifests
|
|
|
|
(YAML, Helm charts, Kustomize ...)
|
|
|
|
- Team "run" adjusts some parameters and monitors the application
|
|
|
|
✔️ parity between dev and prod environments
|
|
|
|
✔️ "run" team can focus on SLAs, SLOs, and overall quality
|
|
|
|
❌ requires *a lot* of extra work (and new skills) from the "build" team
|
|
|
|
❌ Kubernetes is not a very convenient development platform (at least, not yet)
|
|
|
|
---
|
|
|
|
## What's the right answer?
|
|
|
|
- It depends on our teams
|
|
|
|
- existing skills (do they know how to do it?)
|
|
|
|
- availability (do they have the time to do it?)
|
|
|
|
- potential skills (can they learn to do it?)
|
|
|
|
- It depends on our culture
|
|
|
|
- owning "run" often implies being on call
|
|
|
|
- do we reward on-call duty without encouraging hero syndrome?
|
|
|
|
- do we give people resources (time, money) to learn?
|
|
|
|
---
|
|
|
|
class: extra-details
|
|
|
|
## Tools to develop on Kubernetes
|
|
|
|
*If we decide to make Kubernetes the primary development platform, here
|
|
are a few tools that can help us.*
|
|
|
|
- Docker Desktop
|
|
|
|
- Draft
|
|
|
|
- Minikube
|
|
|
|
- Skaffold
|
|
|
|
- Tilt
|
|
|
|
- ...
|
|
|
|
---
|
|
|
|
## Where do we run?
|
|
|
|
- Managed vs. self-hosted
|
|
|
|
- Cloud vs. on-premises
|
|
|
|
- If cloud: public vs. private
|
|
|
|
- Which vendor/distribution to pick?
|
|
|
|
- Which versions/features to enable?
|
|
|
|
---
|
|
|
|
## Developer experience
|
|
|
|
- How do we on-board a new developer?
|
|
|
|
- What do they need to install to get a dev stack?
|
|
|
|
- How does a code change make it from dev to prod?
|
|
|
|
- How does someone add a component to a stack?
|
|
|
|
*These questions are good "sanity checks" to validate our strategy!*
|
|
|
|
---
|
|
|
|
## Some guidelines
|
|
|
|
- Start small
|
|
|
|
- Outsource what we don't know
|
|
|
|
- Start simple, and stay simple as long as possible
|
|
|
|
(try to stay away from complex features that we don't need)
|
|
|
|
- Automate
|
|
|
|
(regularly check that we can successfully redeploy by following scripts)
|
|
|
|
- Transfer knowledge
|
|
|
|
(make sure everyone is on the same page/level)
|
|
|
|
- Iterate!
|