This is the approach we took while building our Internal Developer Platform: watches (via client-go informers with client-side caching) to sync data into a Postgres database as JSONB. Changes are tracked using JSON patches and Kubernetes events. To avoid a watch on every resource kind, we handle this by performing incremental object fetches for the objects involved in watched events.
Getting this to perform well required several optimizations at both the Go and Postgres levels. On the Go side, we use prioritized work queues, event de-duplication, and even switched to Rust for efficient JSON diffs. For Postgres, we leverage materialized views and trigger-based optimistic locking
Flanksource | Founding Level Go Engineers | REMOTE, Worldwide
Flanksource is building a next generation mission control platform that enables teams to communicate and coordinate around system health and incidents, by aggregating health, configuration, change, logs and traces into an application focused view.
Flanksource | Go & React Engineers |Remote, Worldwide
Flanksource is building a next generation mission control platform that enables teams to communicate and coordinate around system health and incidents.
Flanksource | Golang, React and Kubernetes SRE Roles | Worldwide REMOTE | Full-Time or Contract
We are currently in "stealth" mode building a test-driven incident response platform for enterprises - automating most of the mundane and frustrating work required in incident response.
High Availability, Scalability, Deployments, etc are NOT the goal of Kubernetes, they are features that are not exclusive to Kubernetes, nor is Kubernetes necessarily better at them then others.
The goal of Kubernetes is to improve the portability of people by introducing abstraction layers at the infrastructure layer - These abstractions can seem overly complex, but they are essential to meet the needs of all users (developers, operators, cloud providers, etc)
Before kubernetes in order for a developer to deploy an application they would need to (send email, create terraform/cloudformation, run some commands, create ticket for loadbalancer team, etc) - these steps would rarely be same between companies or even between different teams in the same company.
After kubernetes you write a Deployment spec, and knowing how to write a deployment spec is portable to the next job. Sure there are many tools that introduce opinionated workflows over the essentially verbose configuration of base Kubernetes objects, and yes your next job may not use them, but understanding the building blocks, still make it faster than if every new company / team did everything completely differently.
If you only have a single team/application with limited employee churn - then the benefits may not outweigh the increased complexity.
> these steps would rarely be same between companies or even between different teams in the same company.
And the quality can differ a lot too. I used to think that k8s is not necessary, since our team has mastered both stateless and stateful app deployment on VM, with ansible calling aws/gcp API. Everything just works.
And then I joined another company, which has a hotchpotch of unorthodox terraform and ansible code and a homebrew service discovery layer, with frequent incidents in the early mornings, especially on weekends, when autoscaling of aws/gcp VM would fail due to a myriad of reasons.
Flanksource | Founding Backend (Go), Frontend (React), SRE (Kubernetes) and Staff/Principal | Full Time or Contract | Remote First
Flanksource is building a test-driven incident response platform that enables teams to communicate effectively through real-time system models, reducing the broken telephone, "Please re-test" feedback loops that plague organizations with multiple teams.
Flanksource | AWS and Kubernetes SRE's | Fully Remote
Flanksource is hiring for AWS and Kubernetes Site Reliability Engineers we are remote first since inception with a strong focus on open-source - both from a technology perspective and a way of working.
We are looking for strong engineers to join our remote, fully distributed team to help us build a management plane to cater for Kubernetes as the OS for the Datacenter/Enterprise.
Getting this to perform well required several optimizations at both the Go and Postgres levels. On the Go side, we use prioritized work queues, event de-duplication, and even switched to Rust for efficient JSON diffs. For Postgres, we leverage materialized views and trigger-based optimistic locking