Meet the CRE Team Blog Series - Richard Case
This week we introduce Richard Case, a customer reliability engineer here at Weaveworks. Richard spends the majority of his time on kconnect, an open source project created by Fidelity and is also involved in Cluster API projects.
Liquid Metal is Here: Supported, Multi-Cluster Kubernetes on micro-VMs and Bare Metal
You aren't Doing GitOps without Drift Detection
KubeCon and GitOpsCon EU, 2022 - Git Involved!
Our blog series, Meet the Customer Reliability Engineering Team, introduces Weaveworks’ customer specialists, the field heroes that work day in and out with companies to establish production-ready Kubernetes platforms and GitOps workflows.
This week’s spotlight is on Richard Case.
Richard Case, Customer Reliability Engineer
Richard is an engineer and architect by trade, but a retro-gaming and lego addict through and through. With a varied background from developing banking software to working on catch-up video streaming to supporting mission critical teams at Microsoft, he’s been around the block. Before joining the London-based Weaveworks team, Richard helped design, build and operate cloud native and SaaS platforms for ASOS, Compare the Market and others.
What does a typical day look like for you and what are you currently working on?
My day usually starts with a long walk (usually in the rain) with my dog Pippa, and then doing the school runs.
My work day starts with looking to see if there are any issues or code reviews needed for Cluster API Provider AWS (I am a maintainer of the EKS functionality). The remaining morning hours are typically spent working on my client engagement. Currently I am working on kconnect which is an open source project created by Fidelity, this can be coding or responding to new issues or code reviews.
Over lunch I enjoy going for a run and then it's back to my client engagement...so more kconnect. In the afternoon I also attend team stand ups and Cluster API community calls. And finally to round the day off I try and do some coding for Cluster API.
Any words of advice for others trying to dive into cloud native and learn, build, implement Kubernetes platform?
For me it's about jumping in and playing with stuff. Start with EKS or AKS to spin up clusters quickly and easily. You can then try deploying applications using the core workload types...preferably via GitOps. Then I'd work through "Kubernetes The Hard Way" by Kelsey Hightower. And finally learn some Golang.
What’s your top 3 Talks/Books?
These are my top 3 talks:
- Containers From Scratch - fully appreciate what a container is.
- Understanding Distributed Consensus in etcd and Kubernetes - distributed consensus is core to many things in Cloud Native solutions.
- Avoiding Microservice Megadisasters - i love any talk that covers real world problems and how they were solved.
And these are the top 3 books:
- Clean Code by Robert Martin (a.k.a. Uncle Bob): Opened my eyes about how to structure my code to be clear and easily understandable.
- Designing Data-Intensive Applications by Martin Kleppmann: essential reading for any engineer/architect! Data is core to most applications and it has great coverage of distributed data.
- The Cuckoo's Egg by Cliff Stol: a real life hunt for a hacker back in the early days of mainframes. Loved the ingenuity of how they tracked the hacker. If I had read this early enough in my career, I would have focused on security.
What do you wish other people knew about Weaveworks?
It would have to be Weaveworks’ thought leadership and being technical visionaries in the Cloud Native / Kubernetes space. From the instrumental work on Kubeadm to one of the earliest CNI's (Weave Net) to creating GitOps and the first GitOps operator (Flux). And more lately taking GitOps to the next level with Flux2 & Flagger and using GitOps with Cluster API.
What’s your favourite cool new technology?
For me it would have to be Cluster API . After many years of building Cloud Native platforms using all sorts of ways to provision infrastructure and bootstrap Kubernetes I love the declarative nature of defining clusters and that the providers will create the infrastructure providers.