Datum Community Huddle

​

May 14, 2025

Agenda

• Welcome & Housekeeping
• Upcoming huddles
• Alt Cloud Awesome List�
• Updates
• Telemetry Exporter: ElectricSQL demo
• Enterprise Readiness: Overall scope + Zitadel implementation�
• Tech Bet: Kubernetes Resource Model
• Joshua Reese: Datum’s story
• Tom Wilkie: Grafana’s story

Housekeeping

Updates on our NY and SF gatherings, and awesome list 🤣

Upcoming Dates

• June: Wednesday, June 11th 2025 @ 12pm EST
• July: Wednesday, July 9th 2025 @ 12pm EST

Alt Cloud Awesome List

• Link to GitHub repo�
• How to make this list:
• Be public
• Be self service
• Be critical to others�
• Additions/edits welcome!

Enhancements Repo

View the enhancements repo on GitHub!

✔ Central place for all enhancements�

✔ Detailed functional design documentation�

✔ Help shape features for Datum Cloud

Datum Cloud Updates & Demo

Telemetry exporter and overall enterprise readiness 🚀

Datum Capability Stack

Infra: 18x Metros, 24 Sites, 38x Nodes, Netbox, Ansible AWX, ARIN IRR, K3s HA Cluster, BGP Anycast via BIRD, Hyperping, Catchpoint, RIPE ATLAS, Flux + Kyverno

K8s Control Plane: Locations, Workloads, Gateways, Secrets, Telemetry Exporters

GCP Operator

Workload and Network Operators

Envoy and KnotDNS

Vector Telemetry Exporter

Datum Cloud Portal and API

Datum OS (Auth and RBAC)

HickoryDNS (ns4)

ElectricSQL Introduction

• From ElectricSQL: “Sync little subsets of your Postgres data into local apps and services.”
• Leverages PostgresSQL logical replication to create a hot read path for your applications
• Subsets of data, called “Shapes” can be HTTP long polled directly into React components.
• Incredible scale through caching, flexibility through proxy usage, and modularity for modern application use.
• In Datum’s testing, database writes provide near instant updates into Webapp React components.
• ElectricSQL can launch on Datum in < 10 minutes!

ElectricSQL - Deployed in Moments with Kustomize

~$ kubectl apply -k location-network

~$ kubectl apply -k workload-electricsql

~$ kubectl apply -k workload-electricsql

~$ kubectl apply -k workload-frontend

~$ kubectl apply -k gateway

~$ kubectl apply -k telemetry

​

~$ kubectl get gateways -o json | jq '.items.[0].status.addresses.[0].value'

"8733c77a-a6ca-4843-87ec-9f1e12aa7293.prism.global.datum-dns.net"

​

​

​

​

The Real Demo: Datum Telemetry Exporter

Read more on the telemetry system enhancement and tracking issue

Envoy Gateway Metrics

2025 Q2 To Date: Enterprise Readiness

• Organization & Project Management ✅
• RBAC system w/ roles & fine-grained permissions ✅
• User & Machine Authentication 🚧
• Enterprise SSO (OIDC / SAML) 🚧
• Quota Management 🚧
• Audit & Event Logs via Export Policies 🚧
• Event Platform
• Domain Ownership Verification
• Metering

Tech Bet: Kubernetes Resource Model

Rationale, benefits and challenges. Special guest, Tom Wilkie (Grafana)!

Let’s Get on the Same Page

Kubernetes API compatibility - what does it mean?

​

• Leveraging Generic API Server libraries to provide an API server which is compatible with all existing Kubernetes tooling.
• Only registering relevant API types from Kubernetes - Secrets, ConfigMaps, Namespaces, etc. No StatefulSets, Deployments, or Pods.

External Benefits

​

• Use the tools you're familiar with - kubectl for interacting with API resources via the CLI, kustomize, terraform, or Flux for configuration management via GitOps practices, controller-runtime to develop operators to manage Datum resources, or any other tool compatible with the Kubernetes API.
• Expect the same behaviors from the Datum control plane as you would from Kubernetes. Resources are reconciled to ensure intended state has been met, failures are automatically addressed, and transparent status information is made available.

Internal Benefits

• Automatically compatible with a wide range of tools in the Kubernetes ecosystem.
• Less demand on engineering team to develop bespoke CLI tools, configuration management providers, or API clients.
• Ability to leverage all relevant features of the Kubernetes API
• Custom Resources
• Authentication and Authorization
• Audit logs
• Validating and Mutating webhooks
• Ability to leverage tools such as kube-state-metrics to provide extensive visibility into API resources defined in projects.
• Ability to leverage the controller-runtime library to build control plane software
• Leadership election, webhooks, queueing, retries, backoffs
• Level based reconciliation patterns

Challenges

• The Kubernetes API is not designed for multitenant use cases, requiring isolation via discrete API server deployments for projects, or solutions such as KCP.
• Discrete deployments bring operational overhead, though do provide fault isolation benefits.
• Projects take longer than we’d like to provision - we’re sub-minute now, but aim for seconds (or less with KCP approaches).
• Will need to abide by feature deprecations in the upstream libraries.

Tom Wilkie!

Thanks so much!