Want to collaborate?

Right now, you can get in touch with me for a few things:
Open Source Contributions
Giving resume feedback
Guest lecturing
+ more
Follow
Technical Product Manager with a passion for solving complex user data challenges in distributed systems. I've spent years working on open source database technologies and enjoy collaborating with other people passionate about the subject. 

In my free time, I enjoy playing guitar, exploring consumer gadgets, and playing the occasional video game. 
Read more
I'm available for
2021
Jun 10, 2021
Jun 10, 2021
Since the release of Self-Balancing Clusters (SBC) in Confluent Platform 6.0, we have been blown away by the reception and users getting real operational benefits from it. Self-Balancing Clusters is a feature in Confluent Platform 6.0 (and greater) that automatically optimizes uneven workloads as well as topology changes (adding or removing brokers). This is done via a background process that is continuously checking a variety of metrics to determine if and when a rebalance should occur. It’s truly a “set it and forget it” type of tool and the operational benefits of not having to worry about manually monitoring and triggering partition reassignments is huge. 
One of the common themes we heard from our users was that while SBC works well, they would love a bit more visibility into what SBC is actually doing at a given time. In Confluent Platform 6.2, We gave our users more visibility with the addition of the add and remove broker tasks API.
The balancer status is a new API that does exactly what it sounds like it does. It provides visibility into the state of the SBC component itself. Given that SBC relies on metrics collection to make decisions, it could take some time for SBC to ramp up the first time it’s enabled so it’s important for our users to know when SBC is ready for work, especially when relying on it for operator-initiated tasks like adding or removing brokers. 
One of the most powerful features of SBC is its ability to automatically detect and act upon uneven distribution of workloads within a cluster. The even-cluster-load API provides visibility into whether a goal violation for workload distribution has been met and what SBC is currently doing about it. It provides more context in case balancing fails due to some internal error or user intervention.
https://www.youtube.com/watch?v=6tij7Ufn-rM
Read more
Jun 02, 2021
Jun 02, 2021
Launched Infinite Storage for Confluent Cloud on GCP. This was a fundamental shift in our internal storage architecture as well as how our users consume and pay for our services.

We've effectively disaggregated compute from storage, allowing users to scale and pay for the resources they need. This also enables critical use cases where Apache Kafka becomes storage bound such as system of record or cases where longer retention is required for compliance reasons.

https://www.confluent.io/blog/infinite-kafka-data-storage-in-confluent-cloud/
Read more
2020
Oct 14, 2020
Oct 14, 2020
With the release of Confluent Platform 6.0, we officially made Tiered Storage generally available. At launch, we supported two major cloud-specific object stores: Amazon S3 and Google Cloud Storage. Today, we are very excited to add support for our first on-premises object storage: FlashBlade from Pure Storage.

https://www.confluent.io/blog/get-cloud-like-flexibility-elasticity-infinite-storage-on-prem-with-confluent-pure-storage/


Storage is absolutely critical to get right, which is why we worked very closely with Pure Storage for this certification. It was an absolute treat to work with the team—they certainly know their stuff and we think you’ll be impressed with the performance, scale, reliability, and ease of use that comes with it.

Read more
Oct 01, 2020
Oct 01, 2020
Tiered Storage was made generally available in Confluent Platform 6.0. This allowed for our users to use cost-effective object storage for long term storage of their Kafka data.

Object Stores have gotten really good in recent years. Especially when it comes to performance, durability, and resilience. Tiered Storage gives our self-managed users the flexibility to scale compute resources independently of storage comes with some important operational benefits in addition to cost savings. 

Because only a small fraction of a users data remains locally on the Kafka broker, data movement operations such as rebalancing or failure recovery happens extremely fast since the majority of data is sitting in object storage. 

This is an absolute game changer for our users and we were extremely proud when this launched. 

https://www.confluent.io/blog/confluent-platform-6-0-delivers-the-most-powerful-event-streaming-platform-to-date/
Read more
Jul 01, 2020
Jul 01, 2020
Launched Infinite Storage for Confluent Cloud on AWS. This was a fundamental shift in our internal storage architecture as well as how our users consume and pay for our services. 

We've effectively disaggregated compute from storage, allowing users to scale and pay for the resources they need. This also enables critical use cases where Apache Kafka becomes storage bound such as system of record or cases where longer retention is required for compliance reasons. 

https://www.confluent.io/blog/infinite-kafka-data-storage-in-confluent-cloud/
Read more
Jun 01, 2020
Jun 01, 2020
Ended my journey as Product Manager at DataStax!
Read more
Product Manager, DataStax
Loading...