Two Lessons from CTO of Red Bull Racing | ✉️ #25

Promotional banner for MKDEV Dispatch #25 featuring an illustrated smiling man holding a possum, with text "Two Lessons from CTO of Red Bull Racing" on an orange background with paper planes. Promotional banner for MKDEV Dispatch #25 featuring an illustrated smiling man holding a possum, with text "Two Lessons from CTO of Red Bull Racing" on an orange background with paper planes.

Hey! 👋

This week, I’d like to recommend you a book that has nothing to do with the cloud, software development or DevOps. Instead, it’s an autobiography of Adrian Newye, CTO of Red Bull Racing, named “How to build a car”. Adrian is considered to be the best race car designer, his cars winning in total over 200 races at this point.

As you can imagine, CTO role like this also has very little to do with the software, but has everything to do with the hardware. Still, I find the job of designing and building racing cars not only inspiring, but also quite applicable to our field. Adjusting to ever-changing requirements, constantly thinking of how to integrate new technologies, and spend weeks and months on optimizing the performance and reliability - this is something that race car designers do, but also cloud infrastructure engineers as well.

I am only ~30% through the book myself, but I’d like to share two snippets that I found quite fascinating.

First, Adrian shares how up to this date, he sticks to designing new cars on a drawing board:

Computer-aided design (CAD) systems weren't around when I began in the industry, and although most, if not all, of my colleagues have long since converted, I've stuck with my drawing board. Call me a dinosaur, but I think of it as my first language; for me it represents a state of continuity and I like continuity; it's something I strive for. If I were to convert to CAD I'd have to learn something new, and not only is there a time penalty to doing that, but there's the question of whether I'd be as fluent in my new language as I was in my old.

It reminds me of the battles all of us have sometimes around which new code editor, new plugin, new fancy terminal or shell to use to get the job done. I wrote on this topic a while back in one of the chapters of Meditations on programming as well, with the following conclusion:

A good professional is good not for setting up the most productive, automated work environment with beautiful fonts and color schemes, but for getting the job done in the best possible way and on time.

The second snippet is less practically applicable, but nevertheless inspiring, and it’s about debugging one of the cars back in the 80's:

So I kept redesigning the oil tank. I'd sit down with Mario Illien of Ilmor over dinner in the evening, try and understand what was going on, do a new drawing. The guys would take the oil tank out, weld some different baffles in and try again.This went on for a while before we realised the problem was air trapped under the baffles in the oil tank. The rotation of turn one would set up a tumble motion inside the tank, moving the trapped air onto the pickup tube, where it would be sucked into the engine. God, it took us ages to work that out.

You can almost feel the pain of debugging an issue like this. Today those cars have all the possible sensors and metrics, transmitted in real time to computers and sometimes to the cloud, but, I have to imagine, even today debugging such issues is quite tricky. Makes me want to complain less when I am stuck for hours or days figuring out performance or cost issues in some application.

What We've Shared

Let's define Container Managers and containerd this time!

What We've Discovered

  • AWS Lambda Proactive Initialization: If you thought that provisioned, reserved and max concurrency are the only things you need to worry about when it comes to Lambda cold starts and throttling, think twice: sometimes AWS warms up your Lambdas for you, in order to optimize it's own scaling of the underlying Lambda server fleet.

  • Capture clickstream data using AWS Serverless Services: Yet one more of the many of possible combinations of AWS services to collect analytics data. In this case, fully serverless.

  • DevOpsDays Amsterdam 2023 summary: Mike Morraye gives a summary of talks and topics at the event we've sponsored this year.

  • The Pyramid of Alerting: 3 types of alerts you shoud evaluate for your data-related workloads.

  • Kubernetes Disaster Recovery on AWS: Simply excellent 7 minute overview of how to set up a DR for EKS clusters. If you've been thinking of the use cases for AWS Global Accelerator, this video gives some good answers for this as well.

A random reminder

On our Cases page you can always check out case studies of mkdev dealings with our clients. The latest addition there is the KIWI Case Study about AWS savings.

The 26th mkdev dispatch will arrive on Friday, September 1st. See you next time!