Published on

Takeaways from Building a Bank with Kubernetes

Authors

A while ago I watched a talk by one of the guys from Monzo about how they built their digital bank using predominantly Go. Today I watched another talk of theirs called Building a Bank with Kubernetes - this is definitely well worth checking out.

My key takeaways from this talk are:

  • Infrastructure cost saving using Kubernetes: Monzo used about 1/3rd of their original infrastructure when they switched to Kubernetes to manage the microservices.
  • Monzo ,as of this talk, had roughly 150 microservices to power their app
  • Before Kubernetes they ran all 150 on each of the hosts
  • But with Kubernetes to manage their services and replicas they switched to having 3 replicas per microservice spread acorss the hosts
  • The talker mentioned how the initial setup of their roughly 150 microservices was painful but said how it was worth it as it is much easier now to scale when adding more engineers to the team
  • Segregation zones: As Monzo is a bank they segregate different services into different zones for security reasons
  • The very secure zone for example can only speak to services within its zone
  • They use a tool called Calico. Calico makes it super easy to setup network policies within your Kubernetes cluster by defining a network policy deployment file which allows you to do things like specify that only components with a given label are allowed to communicate only with other components with the same label
  • TraceId: All requests that enter the Monzo system via their entry point have a unique id they call a traceId added to it
  • This traceId is really useful as it gets passed along with that request to all microservices that process it. This has allowed them to build tools to trace a request through their cluster
  • Distributed Monolith: One thing the talker cautioned against is building microservices that all rely on some key pieces of shared code before they can start working, he reffered to this as a distributed monolith as the shared code that is needed forms the monolith
  • RPC Layer: Monzo originally used RabbitMQ to handle the communication between microservices
  • They eventually ran into issues with trying to get it to handle a cloud environment where their apps are deployed
  • They ended up swithing to a tool called Linkerd
  • This tool is built on top of Finagle, a tool Twitter built which they have been using for sometime
  • Signing of build Artifacts: Monzo has their builder pods sign their artifacts after they have been built to ensure they have not been tampered with
  • They trust the signature as only their builder nodes can sign them