From c0fbf4aec4851e27a4a795f29b904dfeb50f1cfd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Petazzoni?= <jerome.petazzoni@gmail.com>
Date: Fri, 20 Oct 2017 18:48:22 +0200
Subject: [PATCH] Expand the what's next section

---
 docs/whatsnext.md | 150 +++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 141 insertions(+), 9 deletions(-)

diff --git a/docs/whatsnext.md b/docs/whatsnext.md
index 9503310e..f3564c7c 100644
--- a/docs/whatsnext.md
+++ b/docs/whatsnext.md
@@ -1,17 +1,149 @@
-## What's next?
+# Next steps
 
-- Stateful services (databases and the like)
+*Alright, how do I get started and containerize my apps?*
 
-  volumes, persistent volume claims, stateful sets
+--
 
-- Layer 7 constructs (HTTP routing)
+Suggested containerization checklist:
 
-  ingress (check traefik!)
+.checklist[
+- write a Dockerfile for one service in one app
+- write Dockerfiles for the other (buildable) services
+- write a Compose file for that whole app
+- make sure that devs are empowered to run the app in containers
+- setup automated builds of container images from the code repo
+- setup a CI pipeline using these container images
+- setup a CD pipeline (for staging/QA) using these images 
+]
 
-- Logging, metrics
+And *then* it is time to look at orchestration!
 
-- Secrets, config maps
+---
 
-- Developer experience
+## Namespaces
 
-- Dashboard
\ No newline at end of file
+- Namespaces let you run multiple identical stacks side by side
+
+- Two namespaces (e.g. `blue` and `green`) can each have their own `redis` service
+
+- Each of the two `redis` services has its own `ClusterIP`
+
+- `kube-dns` creates two entries, mapping to these two `ClusterIP` addresses:
+
+  `redis.blue.svc.cluster.local` and `redis.green.svc.cluster.local`
+
+- Pods in the `blue` namespace get a *search suffix* of `blue.svc.cluster.local`
+
+- As a result, resolving `redis` from a pod in the `blue` namespace yields the "local" `redis`
+
+.warning[This does not provide *isolation*! That would be the job of network policies.]
+
+---
+
+## Stateful services (databases etc.)
+
+- As a first step, it is wiser to keep stateful services *outside* of the cluster
+
+- Exposing them to pods can be done with multiple solutions:
+
+  - `ExternalName` services
+    <br/>
+    (`redis.blue.svc.cluster.local` will be a `CNAME` record)
+
+  - `ClusterIP` services with explicit `Endpoints`
+    <br/>
+    (instead of letting Kubernetes generate the endpoints from a selector)
+
+  - Ambassador services
+    <br/>
+    (application-level proxies that can provide credentials injection and more)
+
+---
+
+## Stateful services (second take)
+
+- If you really want to host stateful services on Kubernetes, you can look into:
+
+  - volumes (to carry persistent data)
+
+  - storage plugins
+
+  - persistent volume claims (to ask for specific volume characteristics)
+
+  - stateful sets (pods that are *not* ephemeral)
+
+---
+
+## HTTP traffic handling
+
+- *Services* are layer 4 constructs
+
+- HTTP is a layer 7 protocol
+
+- It is handled by *ingresses* (a different resource kind)
+
+- *Ingresses* allow:
+
+  - virtual host routing
+  - session stickiness
+  - URI mapping
+  - and much more!
+
+- Check out e.g. [Træfik](https://docs.traefik.io/user-guide/kubernetes/)
+
+---
+
+## Logging and metrics
+
+- Logging is delegated to the container engine
+
+- Metrics are typically handled with Prometheus
+
+  (Heapster is a popular add-on)
+
+---
+
+## Managing the configuration of our applications
+
+- Two constructs are particularly useful: secrets and config maps
+
+- They allow to expose arbitrary information to our containers
+
+- **Avoid** storing configuration in container images
+
+  (There are some exceptions to that rule, but it's generally a Bad Idea)
+
+- **Never** store sensitive information in container images
+
+  (It's the container equivalent of the password on a post-it note on your screen)
+
+---
+
+## Managing stack deployments
+
+- The best deployment tool will vary, depending on:
+
+  - the size and complexity of your stack(s)
+  - how often you change it (i.e. add/remove components)
+  - the size and skills of your team
+
+- A few examples:
+
+  - shell scripts invoking `kubectl`
+  - YAML resources descriptions committed to a repo
+  - [Helm](https://github.com/kubernetes/helm) (~package manager)
+  - [Spinnaker](https://www.spinnaker.io/) (Netflix' CD platform)
+
+---
+
+## Developer experience
+
+*I've put this last, but it's pretty important!*
+
+- How do you 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?