At my company, Tyba, we build software to operate utility-scale batteries in wholesale markets (including ERCOT).

If you're interested in applying software/ML/optimization to energy markets, building distributed systems that interface with power markets, or working on problems that directly impact grid decarbonization, we're hiring engineers (in person and remote)!

Company: tyba.ai

Roles: https://tyba.ai/careers

stack traces have been much better over the past few years

Thanks for kubecfg! Happy user :)

For larger companies, I think a huge benefit of Kubernetes is the shared language for defining and operating services, as well as the well-thought-out abstractions for how these services interact.

Costs are generally less of a concern, but having one way of running, operating, and writing services allowed our dev team to move faster, share knowledge, etc.

True, cost is not the biggest issue. Separation of teams with different velocity and needs on the other hand is.

One API as abstraction with shared processes eases the pain for the people relying on a platform.

When I worked at Asana, we created a small framework that allowed for blue-green deployments of Kubernetes Clusters (and the apps that lived on top of them) called KubeApps[0].

It worked out great for us -- upgrading Kubernetes was easy and testable, never worried about code drift, etc.

[0] https://blog.asana.com/2021/02/kubernetes-at-asana/ (Not written by me).

Interestingly, Datadog's agent was a fork of Server Density's open-source agent[1].

[1] https://en.wikipedia.org/wiki/Datadog#Technology

If the argument is Datomic can't be simpler than a relational DB because it can utilize it for persistence, then you'd have to argue that a relational DB can't be simpler than directly using a hard drive for your storage solution.

"This simplicity enables a relation DB to do more than any hard drive can ever afford."

That also seems debatable for the exact same reasons. I don't think this would convince anyone that needs convincing.