Nicky Wrightson, Financial Times
200 containerized services + kubernetes orchestration across two regions.
Why containers
Monoliths didn’t cut it if they were to keep relieince while developing new features
80% cost reduction using containers.
Increased testability using containers (everything is guaranteed to be in place).
Serverless
Too much change too soon!
Some serverless components today.
PoC early 2015
Kubernetes not around, so built their own.
Java not extremely resource conservative compared to e.g. Go. ==> High Container footprint
Use only where needed, consider lighter alternatives elsewhere.
Containerise all the things == a lot of hard work
Of course, changed DB to Neo4J at the same time as they did everything else…
Control issues (mapp service hw req vs hosted VM)
Stateful services make containers sad
Limit container growth.
Monitor at the right level to get the high level view. <== put effort in Core Business Value critical services.
SIMPLE deployment pipeline.
Operational Testing awareness.
Automate the complex things, even if they are rarely done
AWS dropped Fleet support ==> forced migration to Kubernetes and Helm – yay!
Tweak deployment details during active development during migration.
Benefits
Cost
Control
Operationally supportable
Deployments are more graceful
More self-healing
Next?
Rewrite parts of the architecture to fit into all of the nice new features.
Monolithic cluster via namespaces?
Continuous migration?
”3 innovation tokens” <== gör vad du är bra på
Köp resten