200 containerized services + kubernetes orchestration across two regions.
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).
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.
Deployments are more graceful
Rewrite parts of the architecture to fit into all of the nice new features.
Monolithic cluster via namespaces?
”3 innovation tokens” <== gör vad du är bra på