When deploying a service on your infrastructure, it can be tempting to just grab open source containers and roll them out with simple tools. Docker compose or ansible playbooks can do a fantastic job at rolling out a few containers in no time. But putting simple services online is the easy bit. The more containers in your stack, the more difficult it becomes to deploy them consistently, and the more chances for it to break.
A solid deployment is forgiving, battle tested, and has professional support to back it. At Element, we’ve based our ESS Pro Matrix stack on Kubernetes, because we believe it’s the most efficient way to address infrastructure teams’ challenges. Kubernetes itself does half of the work, and our helm chart does the other half.
Kubernetes doesn’t just solve scalability problems
This section is a Kubernetes primer in a few paragraphs for people unfamiliar with it. If you are comfortable with it, you can skip to the next section.
Kubernetes is a platform in itself that lets infrastructure teams deploy container-based services, and that is often seen as “the platform for deployments that scale”. But before even considering auto-scaling, one key selling point of Kubernetes is its declarative nature. You describe what building blocks you want to deploy on your cluster in yaml files called manifests, and Kubernetes figures out how to do it.
A manifest can describe what building blocks you want to deploy in your cluster: a specific container, a volume (storage space) to persist files, a configuration file that other building blocks can use, and many more. For example, a manifest that deploys a Pod containing a nginx container version 1.31.6 looks like this. This is a simple example file that would not be used as is in production.
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.31.6
ports:
- containerPort: 80That declarative nature means that Kubernetes deployments can be self-healing (to an extent), or at the very least much more forgiving when doing upgrades. If you write a manifest asking for two containers, Kubernetes will deploy the two and ensure that if one crashes, it’s replaced. If you want to update your container to a new version, Kubernetes will:
- Pull the new container image
- Attempt to start the new container
- Check that it has started and is healthy
- Remove the old container.
- If the upgrade goes wrong, keep the old version running instead.
But deploying the building blocks and assembling them manually is tedious and error-prone. Without anything to help, deploying and wiring the building blocks becomes the responsibility of the infrastructure team who maintain services on a cluster.
Fortunately, infrastructure teams rarely have to deploy building blocks like these manually. Instead, they can deploy pre-assembled Lego sets: helm charts.
Charts are products
A helm chart is a pre-assembled set of Kubernetes building blocks to roll out a functional deployment. Instead of deploying each building block and wiring them together manually, infrastructure teams can use a helm chart that will do it for them.
A simple helm chart is primarily made of two things
- A configuration file, better known as a values file, that infrastructure teams can edit to make a deployment that suits their exact needs. It contains safe defaults that the teams can override.
- A list of manifest (building blocks) templates to create a consistent deployment. The templates contain placeholders that will be filled by the values from the values file.
All the wiring between the building blocks has already been done by the vendor who wrote that list, so they fall neatly into place once deployed, even after the infrastructure teams customise the values file.
A simple values file can look like this:
serverName: example.com
database:
postgres: enabled
host: db.int.example.com
port: 5432The manifest templates in the chart will reuse some of those values (e.g. the content of serverName) to deploy and assemble building blocks for a real-world deployment.
Vendor-owned charts shift part of the deployment burden from the infrastructure team to the vendor. Vendors know how their software is meant to be deployed. Instead of just shipping software, they can ship a comprehensive package, that infrastructure teams can configure.
A vendor-owned chart allows easier support by the vendor themselves. Since the deployment is done as intended by the vendor, it’s easier for them to rule out some common deployment pitfalls already covered by the chart and focus on bugs in their products.
A good chart also takes trial and error
While it sounds easy on paper to write a good chart, there are quite a few challenges. The more components in your stack, the more moving parts you have to wire together, the more opportunities there are for things to break.
It’s not very difficult to write tests for a default set of components. But even here, it is possible to do testing at various depths: checking that the charts still make sense when overriding the default values; checking statically that the helm chart doesn’t contain syntax errors and will deploy components in the right order; doing proper integration testing by actually deploying the chart on a test environment, etc.
Writing good charts and good tests requires experience. As a vendor, you need to have a good understanding of how infrastructure teams work and what tools they usually work with, so you can test for how you think they will use the chart.
But even then, some users will use different components, in ways you hadn’t anticipated. The sturdiest charts necessarily have field experience.
ESS is “just” a Matrix chart, and more
Element’s own chart, ESS, is just a helm chart in theory. But when you look closer it comes with a lot more.
We test ESS extensively
On each new release, we do 10,700 tests mutating values on our ESS Pro solution. Put differently: for each possible parameter in the values file, we change it to any value the user could use in a real-world deployment, and we make sure that the chart is still consistent and sensible.
We also run 300 tests for what we call static choreography analysis. We test the order in which building blocks are going to be deployed so that the final deployment is built on a solid foundation once those blocks are assembled together. These tests allow us to detect statically errors that would happen at runtime.
To make the whole stack really robust, we also run 34 integration tests combining various components of our stack (with or without Matrix Authentication Service, with or without Advanced IAM, testing tenants mode, etc), and making sure that the various components respond as expected. In other words: whether you use the full stack or only some parts of it, we’ve got you covered.
We work with real-world deployments
We have worked with and supported 100+ organisations to shape ESS Pro, with 4M+ users in total. Each support request makes our chart sturdier. Each bug found is fixed for everyone.
Because we are supporting large-scale deployments in the public and private sectors, we know the kind of problems you can hit at scale, and it’s reflected not just in our charts but also in the Pro components that come with our paid offering. If we can support NATO, the United Nations International Computing Centre and the Swedish Social Insurance Agency (Försäkringskassan), we can support you.
We are here to support
Despite our best efforts to offer a fully integrated suite of high-quality components, you might still bump into issues. As the maintainers of nearly all the components of ESS, we know how they should be deployed and how they work with one another. Using ESS for Matrix deployments is the fastest way to get sturdy deployments with Level 3 support. We also offer Long Term Support (LTS) versions in our Pro offering, and get them through the same amount of tests.
Give it a go
If you haven’t already, you can give ESS Community a go for your proof of concepts, and upgrade to ESS Pro smoothly when you need Level 3 support, LTS, Advanced IAM features, endpoint management integration, and much more.
