4.0 KiB
What's next?
-
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 resources (time, money) to people 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?
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 / same level)
-
Iterate!