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.
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.
The size of the slack channel alludes to the size of the eco-system, and the scale at which Kubernetes is solving not just technical coding problems, but non-technical communication problems
Kubernetes isn't the source of complexity - it is the problem domain of building and operating distributed systems that are fundamentally and essentially complex.
Compare the complexity of Kubernetes to Openstack - the next most similar project in the same problem space, and you will find Kubernetes is actually pretty simple.
Flanksource is a niche consultancy focusing exclusively on Kubernetes and the Cloud Native ecosystem. We help companies navigate the CNCF landscape by evaluating and integrating technology into an infrastructure continuous delivery pipeline, tailored to each customer's particular environment and stack.
We are looking for Kubernetes focused Site Reliability Engineers to work remotely and ideally contribute back upstream.
Flanksource | Remote First | Full Time / Part-Time
Flanksource is a niche consultancy focusing exclusively on Kubernetes and the Cloud Native ecosystem. We help companies navigate the CNCF landscape by evaluating and integrating technology into an infrastructure continuous delivery pipeline, tailored to each customer's particular environment and stack.
We are looking for Kubernetes focused Site Reliability Engineers to work remotely and ideally contribute back upstream.
I think this post misses the point of where kubernetes brings value the most: multi-team environments. If you are a single-team, then nomad, non-distributed docker, systemd units, etc is probably a better choice today due to the operational complexity of running Kubernetes (GKE,AKS,EKS do lower the complexity, but you still need kubernetes experts on call)
However if you are in an organization with multiple teams (as are the vast majority of developers) then Kubernetes provides a common language for deploying, operating and securing your applications which enables you to go from a process which could takes days, weeks or even months to provision and configure a VM to minutes or hours to provision a kubernetes namespace.
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