So this is a pretty big deal to me (it looks recent, just put up last October). One of my big frustrations with Matrix was that they didn't offer helm charts for a kubernetes deployment, which makes it difficult for entities like nonprofits and community clubs to use it for their own purposes. Those entities need more hardware than an individual self hoster, and may want features like high availability, and kubernetes makes horizontal scaling and high availability easy.
Now, according to the site, many of these features seem to be "enterprise only" — but it's very strangely worded. I can't find anything that explicitly states these features aren't in the fully FOSS self hosted version of matrix-stack, and instead they seem to be only advertised as features of the enterprise version
My understanding of Kubernetes architecture is that it's difficult for people to not do high availability, which is why this makes me wonder.
Looking through the docs for the "enterprise version, it doesn't look like anything really stops me from doing this with the community addition.
They do claim to have rewritten synapse in rust though
Being built in Rust allows server workers to use multiple CPU cores for superior performance. It is fully Kubernetes-compatible, enabling scaling and resource allocation. By implementing shared data caches, Synapse Pro also significantly reduces RAM footprint and server costs. Compared to the community version of Synapse, it's at least 5x smaller for huge deployments.
And this part does not seem to be open source (unless it's rebranded conduit, but conduit doesn't seem to support the newer Matrix Authentication Service.)
So, it looks Matrix/Element has recently become simultaneously much more open source, but also more opaque.
Yes and no. There are many things that are much easier with Kubernetes, once you figure Kubernetes out.
High availability is the most notable example — yes, it's doable in docker, via something like swarm, but it's more difficult. In comparison, the ideas of clustering and working with more than one server are central to the architecture of Kubernetes.
Another thing is that long term deployments with Kubernetes can be more maintainable, since everything is just yaml files and version is just a number. If you store your config in code, then it's easier to replicate it to another server, either internally, or if you share it for other people to use (Helm is somewhat like this).