Lessons from Jessie Frazelle

Lessons from Jessie Frazelle

Jessie Frazelle is a software engineer who built core components of Docker and Kubernetes and popularized running desktop applications in containers. She later co-founded Oxide Computer Company and Zoo to push hardware design forward. Her writing and talks tackle systems engineering and the tech industry with a blunt, first-principles approach.

Part 1: The Nature of Containers

1. On Demystifying Containers: "A container is not a thing; it's actually just a group of Linux namespaces and control groups applied to a process." — Source: [Spicy Takes]
2. On Orchestration Alternatives: "You could easily build your own orchestrator without Kubernetes. It is entirely possible to just use containerd." — Source: [Jessie Frazelle's Blog]
3. On Ubiquity: "I run literally everything in containers. It is the best way to keep your base system clean." — Source: [YouTube]
4. On Definition: "Cloud native is such a buzzword. I think that it's just honestly anything that you can deploy in the cloud easily." — Source: [GCP Podcast]
5. On Kubernetes Evolution: "Kubernetes is the new kernel. We can refer to it as a 'cluster kernel' versus the typical operating system kernel." — Source: [Jessie Frazelle's Blog]
6. On Minimalism: "Sometimes the simplest tool for the job is the best. You might not need the full complexity of Kubernetes for every single deployment." — Source: [Jessie Frazelle's Blog]
7. On Desktop Integration: "By running Spotify, Chrome, and even games in containers, you ensure that if an application is compromised, the blast radius is contained." — Source: [Uses This]
8. On Process Management: "At its core, a container runtime is just an advanced process manager that understands Linux primitives." — Source: [YouTube]
9. On Tooling Tradeoffs: "Computing is all about tradeoffs. I learned from experience with everything I've worked on that people will use it for things it was not built for." — Source: [Spicy Takes]

Part 2: Security and Isolation

1. On Absolute Security: "To be clear I am not saying containers are secure, literally nothing is secure." — Source: [Jessie Frazelle's Blog]
2. On Damage Control: "Containers aren't going to be the answer to preventing your application from being compromised... but they will limit the damage of a compromise if it occurs." — Source: [YouTube]
3. On FUD in Security: "Spreading FUD while ignorant or not doing proper research is harmful to the facts and hard work many people put in to making containers at least decently isolated by default." — Source: [Jessie Frazelle's Blog]
4. On Sandboxing Alternatives: "I truly believe gVisor cannot be possibly more secure than the defaults for containers are today and surely it is not as secure as a real hypervisor." — Source: [Jessie Frazelle's Blog]
5. On Kernel Defaults: "I added the default Seccomp profile to Docker and maintained the default Apparmor profile to ensure we had a baseline of defense." — Source: [Jessie Frazelle's Blog]
6. On Multi-Tenancy: "For true, high-security multi-tenant environments running untrusted code, you need VM-level isolation, like Firecracker, rather than relying solely on container namespaces." — Source: [Spicy Takes]
7. On Image Building: "Building container images securely on Kubernetes as an unprivileged user is one of the hardest problems in Linux sandboxing." — Source: [Jessie Frazelle's Blog]
8. On Firmware Vulnerabilities: "If you've ever used a Supermicro server I probably don't need to tell you that it's a piece of shit running a 2.6 linux kernel on the BMC." — Source: [Jessie Frazelle's Blog]
9. On Defense in Depth: "Security is never a single toggle; it requires stacking primitives like seccomp, AppArmor, namespaces, and cgroups to create a meaningful boundary." — Source: [YouTube]
10. On Trusting Hardware: "Proprietary firmware at lower rings, like the Management Engine, represents a massive, unauditable security risk that we blindly accept." — Source: [Jessie Frazelle's Blog]

Part 3: Hardware and the Physical World

1. On Manufacturing as Code: "Manufacturing workflows could be treated like software deployments, with declarative configuration files defining robot positions, behaviors, and artifact pipelines." — Source: [Spicy Takes]
2. On Hardware Quality: "Manufacturers of computers should be embarrassed for even selling such a shit machine. It infuriates me to no end that consumers have an option of even buying a $400 computer that will give them such a terrible experience." — Source: [Spicy Takes]
3. On Vertical Integration: "What we think people are begging for is an iPhone in their DC. They're begging for that fully integrated, vertically integrated experience." — Source: [Wikitia]
4. On Modern CAD: "Traditional CAD tools rely on decades-old, single-threaded engines. We need tools built from scratch to leverage GPUs for faster rendering and complex calculations." — Source: [YouTube]
5. On Programmable Hardware Design: "Bringing software engineering best practices like version control, continuous integration, and automation to the hardware world reduces the toil engineers face with archaic tools." — Source: [Simplecast]
6. On First Principles in Manufacturing: "Tesla’s Battery Day showed the value of optimizing cell design and manufacturing processes together from first principles rather than in isolation." — Source: [Spicy Takes]
7. On Hardware Access: "The future of computing should make powerful compute readily available to everyone, not just those who can afford premium hardware." — Source: [Spicy Takes]
8. On the Hardware/Software Interface: "Building a proper service processor means writing a custom, open-source operating system to replace the traditional, buggy BMCs we've suffered with for years." — Source: [Wikitia]
9. On the Physical/Digital Bridge: "I basically automated the role of CIO in Rust, exploring how software paradigms can directly manage physical networks and hardware states." — Source: [Spicy Takes]

Part 4: Open Source and Maintainership

1. On Saying No: "The art of closing issues and saying 'no' to pull requests is the most difficult but necessary part of maintaining project integrity." — Source: [YouTube]
2. On Open Source Careers: "Open source has been like a driving factor for my career... it's given me a way to show my work." — Source: [CodeNewbie]
3. On Maintainer Empathy: "Being a maintainer is hard, but other maintainers actually commiserate with you, which makes the shared scars a bit more bearable." — Source: [Software Engineering Daily]
4. On AI Coding Assistants: "If you've got nothing to say, don't say it. AI agents that clutter pull requests with low-value 'looks good to me' comments are missing the point of code review." — Source: [Spicy Takes]
5. On the Burden of Success: "When an open source project achieves massive adoption, the weight of backward compatibility and edge cases often stifles the very velocity that made it popular." — Source: [Changelog]
6. On Firm Open Source: "We desperately need open-source alternatives to proprietary firmware like UEFI to improve security, ensure transparency, and accelerate boot times." — Source: [Wikitia]
7. On Community Entitlement: "Users of open source software often forget that maintainers are humans volunteering their time, leading to unreasonable demands for support." — Source: [YouTube]
8. On Transparent Governance: "A healthy open source community requires transparent decision-making; opaque roadmaps inevitably lead to forks and fragmented ecosystems." — Source: [Changelog]
9. On Upstream Contributions: "If you are running a patch set internally that fixes a bug, failing to upstream it is just taking on technical debt that you will pay for on the next rebase." — Source: [Jessie Frazelle's Blog]
10. On Evaluating PRs: "A good pull request doesn't just provide code; it provides the context, the rationale, and the test coverage proving the fix actually works." — Source: [Jessie Frazelle's Blog]

Part 5: Systems Engineering and Architecture

1. On Technical Distractions: "There is a lot of hype in our field and little truth behind the hype. Evaluate tools based on their architectural merit, not their marketing." — Source: [Spicy Takes]
2. On System Reliability: "Hope is not a strategy. You cannot operate distributed systems under the assumption that networks won't fail." — Source: [Spicy Takes]
3. On LD_PRELOAD: "LD_PRELOAD is the hero we need and deserve; it allows for creative hacks like injecting cloud-native syscalls without recompiling the underlying application." — Source: [Spicy Takes]
4. On Corporate Impact: "I realized how much of a cog you are at big tech companies; you don't really do anything that necessarily pushes the wheel forward much." — Source: [YouTube]
5. On Abstractions: "Every abstraction leaks eventually. If you don't understand the underlying primitives like how a kernel actually schedules a process you will be helpless when the abstraction breaks." — Source: [YouTube]
6. On Legacy Systems: "Many APIs don't even have GraphQL interfaces, but also I am old school and I don't really want to learn something new when a simple REST call works perfectly." — Source: [Spicy Takes]
7. On Engineering Scope: "Context matters. I value taking all contexts into consideration when thinking about a problem. I hope you all do the same." — Source: [Jessie Frazelle's Blog]
8. On Evaluating Tradeoffs: "Good architecture is just making the right series of painful tradeoffs and documenting why you made them." — Source: [Software Engineering Daily]
9. On Performance Benchmarks: "Microbenchmarks often lie. The only performance metric that matters is how the system behaves under your specific production workload." — Source: [Jessie Frazelle's Blog]

Part 6: Leadership, Trust, and Transparency

1. On Earning Trust: "Trust is not given but earned through consistent integrity. It starts at zero and must be actively built." — Source: [Spicy Takes]
2. On Information Weaponization: "Leaders who default to secrecy over transparency are often weaponizing information asymmetry against their own teams." — Source: [Jessie Frazelle's Blog]
3. On Making Mistakes: "The best we can do is apologize and grow when we fuck up. Acknowledging the error is the first step to rebuilding trust." — Source: [Spicy Takes]
4. On Assuming Intent: "Most people will tell you to always assume good intentions... I tend to be less and less willing to do that without verification." — Source: [Jessie Frazelle's Blog]
5. On Hiring Dynamics: "Hiring is guessing but firing is knowing." — Source: [Spicy Takes]
6. On True Leadership: "A distinguished engineer isn't just someone who writes brilliant code; they are someone who elevates the technical rigor and culture of everyone around them." — Source: [Software Engineering Daily]
7. On Transparency: "I think people tend to underestimate how important it is to be transparent about things that don't need to be private." — Source: [Jessie Frazelle's Blog]
8. On Organizational Silos: "When engineering and product teams don't share the same ground truth, you end up shipping the organizational chart instead of a cohesive product." — Source: [Software Engineering Daily]
9. On Measuring Impact: "Pass: I am doing the minority of the speaking and people are disagreeing with my opinions. Fail: I am being quoted back to myself." — Source: [Spicy Takes]

Part 7: Tech Culture and "Spicy Takes"

1. On Hero Worship: "I really do not enjoy when people hero worship me and I do not think people should hero worship anyone. We are all humans and we are all flawed in our own ways." — Source: [Spicy Takes]
2. On Taking Challenges: "Hard things are super fun and like I guess don't be scared by them because it's really rewarding when you pull it off." — Source: [Spicy Takes]
3. On Writing Style: "I like to think that I write how I speak. The industry has enough sterile corporate blogs; technical writing should reflect the author's actual voice." — Source: [Spicy Takes]
4. On Academic vs. Practical: "There is a massive disconnect when academia pushes complex implementations, like Intel's TSX, while ignoring the warnings of practitioners who have to deal with the resulting vulnerabilities." — Source: [Spicy Takes]
5. On Limits of Capability: "I think anyone is capable of doing or learning anything, they just need the right motivation and to believe in themselves." — Source: [Spicy Takes]
6. On Tech Marketing: "I have a problem with the messaging around some new technologies. There is a large amount of ignorance towards the existing defaults." — Source: [Jessie Frazelle's Blog]
7. On Echo Chambers: "The tech industry loves to form echo chambers where we congratulate ourselves on reinventing a concept that mainframe engineers solved thirty years ago." — Source: [Software Engineering Daily]
8. On Being Direct: "Sometimes you just have to say the current implementation is garbage so that you can clear the path to build something that actually works." — Source: [Spicy Takes]
9. On Deep Dives: "The nerdiest podcast on the face of the planet is simply what happens when you put two people who care deeply about the hardware-software interface in a room together." — Source: [Transistor]

Part 8: The Joy of Hacking and Automation

1. On Personal Infrastructure: "Automation is fundamentally about reclaiming time by transferring repetitive manual tasks to scripts and services." — Source: [Spicy Takes]
2. On Tooling Joy: "I fucking love Airtable. Its design just feels right and works the way my brain works." — Source: [Spicy Takes]
3. On Side Projects: "I always have some random side project I am working on, whether it is making the world's most over-engineered desktop OS all running in containers or updating all my Makefiles to be the definition of glittering beauty." — Source: [Jessie Frazelle's Blog]
4. On Learning Strategies: "This is my learning technique. I bounce from one thing to another, recursively digging deeper as I learn more." — Source: [Spicy Takes]
5. On Physical Constraints: "Everyone knows shitty internet is a productivity killer. When you build an office, optimizing the network isn't an afterthought; it's the foundation." — Source: [Spicy Takes]
6. On Workspace Ergonomics: "I am deeply attached to the i3 window manager and Debian Sid; once you build a minimal, custom environment that perfectly maps to your workflow, everything else feels sluggish." — Source: [Uses This]
7. On Automating Workflows: "If a task requires me to type the same sequence of commands more than three times, it deserves a shell script." — Source: [Jessie Frazelle's Blog]
8. On Infrastructure as Code: "Treating your personal home lab with the same declarative rigor as a production cluster is the best way to safely experiment with infrastructure as code." — Source: [Jessie Frazelle's Blog]
9. On Exploring the Stack: "There is immense satisfaction in peeling back the layers of a system, from a high-level API request all the way down to the voltage changes on a CPU." — Source: [YouTube]
10. On Building for Fun: "At the end of the day, hacking on weird edge cases and over-engineering personal tools isn't about utility; it's about the sheer joy of making computers do exactly what you want." — Source: [Jessie Frazelle's Blog]