In this episode of Cloud Native Compass, hosts David Flanagan and Laura Santamaria dive deep into the complexities of the Kubernetes release cycle with guest Kat Cosgrove. Kat, a sub-project lead for SIGrelease in the Kubernetes project, shares her experiences and discusses issues such as burnout, handling drive-by PRs, and the nuances of managing a fast-moving open source project. They explore the structure of the release team, the challenges of maintaining CI stability, and the ever-evolving nature of contributing to Kubernetes. Alongside tech talk, the trio reminisces about their work history, the challenging debates over project management, and the quirks of maintaining open source projects. Kat also recommends a book, a movie, and an album, providing a well-rounded blend of tech insights and personal favorites.

Click here to watch a video of this episode.

Featuring

• David Flanagan - Host
• Laura Santamaria - Host
• Kat Cosgrove - Guest

• (00:00) - Introduction
• (00:08) - Meet the Hosts and Guest
• (01:24) - Kubernetes Release Process Overview
• (03:22) - Challenges in Kubernetes Release Management
• (04:08) - Team Structure and Roles
• (06:29) - Open Source Contributions and Burnout
• (11:06) - Managing CI and Bug Triage
• (15:28) - Release Delays and External Dependencies
• (16:51) - Press Embargoes and Publicity
• (20:46) - AI in Open Source Documentation
• (22:13) - The Challenges of Open Source Contributions
• (23:06) - The Auto PEP 8 Incident
• (23:49) - The Overwhelming Decisions of Maintainers
• (24:01) - The Etiquette of Open Source PRs
• (26:39) - Personal Experiences in Open Source
• (28:56) - The Accidental Involvement in Kubernetes
• (32:17) - The Chaos of SIG Release
• (34:31) - Kubernetes 2.0 and Backwards Compatibility
• (37:07) - Book, Movie, and Album Recommendations
• (38:51) - Conclusion and Farewell

Exploring Cloud Migrations & Infrastructure Strategies with Jason Hall of Chainguard

Click here to watch a video of this episode.

In this episode of the Cloud Native Compass podcast, hosts David Flanagan and Laura Santamaria chat with Jason Hall, Principal Engineer at Chainguard. They delve into Chainguard's migration from Kubernetes and Knative to Cloud Run, discussing the reasons behind the move, cost considerations, managing technical debt, and best practices for infrastructure management. The conversation also covers the benefits of using Cloud Run, their strategic use of BigQuery for event logging, and insights into least access security models. Tune in to learn more about navigating cloud-native environments and optimizing infrastructure.

Creators & Guests

• David Flanagan - Host
• Laura Santamaria - Host
• Jason Hall - Guest

• (00:00) - Introduction
• (00:52) - Jason Does Stuff
• (01:32) - Chainguard's Migration Journey
• (02:18) - Challenges with Kubernetes and Knative
• (04:33) - Adopting Cloud Run
• (12:15) - Multi-Region Deployment with Cloud Run
• (19:26) - Security and Authorization Practices
• (27:29) - Operational Decisions and Cost Considerations
• (33:07) - Debunking Kubernetes Myths
• (33:24) - The Illusion of Free Services
• (33:42) - Scaling Challenges and Solutions
• (37:00) - Convincing Leadership to Address Technical Debt
• (39:41) - Developer Environments in the Cloud
• (43:18) - Cloud Run vs. BigQuery Debate
• (47:20) - Security and Logging Best Practices
• (52:56) - Future Plans and Focus Areas
• (54:45) - Final Thoughts and Farewells

InfluxDB 3.0 Rewrite

InfluxDB, a time series database, underwent a major rewrite to create InfluxDB 3.0, also known as IOx. The decision to rewrite the database was driven by the need for strict control over memory management and high performance. The project started as a research endeavor and gradually gained traction within the company. The team decided to build around projects under the Apache Foundation, such as Apache Arrow and Apache Data Fusion. In April 2022, InfluxDB 3.0 was officially announced, aiming to improve performance, scalability, and cost-effectiveness for users.

IOx Database Engine

The new database engine, IOx, is designed to handle various types of observability and monitoring data, including metrics, traces, and logs. It aims to provide a single store for all these signals, eliminating the need for separate databases. However, querying the data efficiently is still a challenge that the team is working on. The goal is to make IOx the go-to solution for storing and querying observational data, not only for server infrastructure monitoring but also for sensor data use cases.

Challenges and Considerations

Working with logs, tracing, and structured events in time series databases poses challenges. The dynamic and inconsistent nature of schemas in logs and tracing use cases can make extracting structured fields difficult. Time series databases also have limitations in handling tracing front ends and require an index to map trace IDs to individual traces. While metrics, logs, and traces are the gold standard for observability, there is room for improvement in terms of usability and performance.

Flux and Data Fusion

Flux, a scripting language developed for InfluxDB 2.0, addresses user requests for more complex query logic and integration with third-party systems. InfluxDB 3.0 incorporates a parser in Rust to translate SQL queries into a Data Fusion query plan, benefiting from the performance optimizations of Data Fusion. However, bringing Flux to InfluxDB 3.0 proved challenging due to the large surface area of Flux and limited time and resources. Updating the Flux engine to use the 3.0 native API could potentially resolve these issues.

InfluxDB Development and Open Source Licensing

InfluxData is focused on improving the core query engine of InfluxDB and enhancing its capabilities and performance. They have created a separate community fork of Flux to allow collaboration on its development. Paul Dix, the co-founder, believes that true open source should be about freedom and expresses his intention to keep InfluxDB 3 as a permissively licensed project. He discusses the recent license change by HashiCorp and the growing distrust in the developer community towards VC-backed open source projects. Putting InfluxDB into a foundation may not be feasible due to the lack of multiple contributors.