Meet the CRE Team - Mahmoud Saada
Over the next several weeks, we’ll be showcasing the talented folks here at Weaveworks. The first team we’d like to introduce are the Customer Reliability Engineers. This week we introduce you to Mahmoud Saada, CRE and certified Kubernetes administrator.
Over the next several weeks, we’ll be introducing some of our talented folks here at Weaveworks. The first team we’d like to introduce are the Customer Reliability Engineers. As experts in both cloud native technologies and GitOps methodology, the Weaveworks CRE team works in tandem and as peers with our customers, acting as embedded team members to deliver solid Kubernetes solutions and platforms on time and within budget.
Mahmoud Saada, Customer Reliability Engineer
As a certified Kubernetes administrator, Mahmoud is experienced in working with cloud native applications and infrastructure in both startup and enterprise environments. Over the past years working as a software and site reliability engineer for a variety of industries such as HR, AI and finance, he developed a deep passion for delivering outstanding experiences for customers and engineers. Before joining Weaveworks as a Customer Reliability Engineer, he worked at ADP and regularly speaks at meetups such as NYC Docker and NYC Uber’s Distributed Tracing. Twitter: @saadazzz Github: saada
What does a typical day look like for you and what are you currently working on?
I like to knock out important customer tasks first thing in the morning. Finishing high impact work early on allows me to avoid multitasking during meetings and lowers my overall stress throughout the day. I usually take two breaks. A 30 min lunch break around noon and a 30 min walk near the end of the work day. Before I end my day, I like to review everything that happened, write notes, and set priorities for tomorrow.
Lately, I’ve been contributing new features to open-source Weaveworks projects such as eksctl and Helm Operator.
Any words of advice for others just taking the dive into cloud native and implementing a Kubernetes platform?
Write more Go code. Go has become an essential part of the cloud native ecosystem. The more practice you get, the easier it is to navigate the cloud native space. Diving into a Kubernetes bug, or adding a Prometheus feature, all of these become easier with a strong foundational understanding of Golang.
What talks or books have you come across lately that you can recommend?
3 Talks
- Throttling: New Developments in Application Performance with CPU Limits - Dave Chiluk, Indeed : This technical talk is close to the heart as it addresses a common misunderstanding of Linux cfs quotas and a source of several incidents customers have faced in Kubernetes
- Bringing back dial-up: the internet over SMS by Alexandra Sunderland | JSConf EU 2019 : This talk was so entertaining and creative I had to include it
- Bret Victor - Inventing on Principle : Opens your mind on what’s possible with a clear focus on the software experience from a human point of view
3 Books
- DNS and Bind: You know what they say about distributed system bugs… “It’s always DNS”
- The Linux Programming Interface: This book is like my Linux dictionary. Whenever I need to dig into a specific area in Linux, I go back to this book.
- Site Reliability Engineering books: The books that were inspired by the famous SRE quote “hope is not a strategy”. A great theoretical and practical guide into software reliability and best practices.
What do you wish other people knew about Weaveworks?
There’s something special about the culture at Weaveworks. Everyone at Weaveworks has a strong emphasis on openness, trust, and transparency. The urgency towards taking care of employees and also humanitarian causes makes you feel like you’re part of something bigger. And you get to work with some of the smartest people in the cloud native space.
Any favourite cool new technology that you can recommend?
I’m excited about WebAssembly and how it could potentially become the standard compilation target for all programming languages. It has the potential to eliminate the need for containers since you won’t need to manage several competing runtimes like a JVM, a PHP daemon, nodejs, rails server, python server, etc… Wasmer could standardize the runtime itself and make different programming language communities come together and avoid reinventing the wheel every time a new language is introduced. Not to mention that you could in theory import a python package in Golang. Or a Ruby package in Nodejs. We wouldn’t need to re-create popular dependencies for every language. Getting rid of unnecessary toil gets me excited!
