46 pointsby tarunnnp4 hours ago3 comments
  • robszumskian hour ago
    I was part of the team that proposed this manner of operation (Kubernetes Operator)[1]/controller and it's immensely cool to see a competent team make what seems like an incredible one that really scales the business.

    I had always assumed databases would be the silo that had the most benefits for an Operator. There are a few good Postgres Operators, but not many outside of that which actually do the day 2 operations.

    [1]: https://operatorhub.io/what-is-an-operator

    • tarunnnpan hour ago
      thanks rob! It does help that we are backed by object storage, and we try to make architecture choices that keep the system simple and safe to roll out at any time.
  • wowoc2 hours ago
    Do you collect metrics from those BYOC clusters? If so, I’m assuming you push them, not pull them? That would seem to follow the same direction as the cluster operator config syncs (i.e. the direction in which connections are made, not in which data flows).
    • tarunnnp44 minutes ago
      Yep, all pushed based directly from cluster! It helps that most of the observability ecosystem is converging on this? Even Prometheus, while pull-based inside the cluster, can remote-write to external storage, and that's the shape we'd pick even in that world. (we use datadog right now)
  • hemc42 hours ago
    Interesting read. A simpler way to manage the data plane.

    Curious to understand if you also use OTEL layer to understand what is happening in your BYOC cluster ?

    • tarunnnp40 minutes ago
      Yes, the database is instrumented with OTel, but Datadog (via local agent) is our primary sink.