How we are managing a container platform: a tale from the future
In this final chapter of our series, we’ll explore the planned improvements in the management of our platform for the upcoming months and years. From self-generated changelogs to the development of an operational CLI and the optimization of cluster configurations, we’ll uncover how these updates promise a more agile and efficient platform management.
Automatic generation of changelogs per cluster
Although the current generated CHANGELOG.md indicates when a change has been made in the configuration repository, given our automatic maintenance windows, it could be beneficial to know precisely when a new configuration has been automatically applied to the cluster. This could be achieved by listening to synchronization events and pushing the new generated file to the repository.
Operations CLI
Since we have many container clusters across the world, it’s really important to handle everything from one place. Managing each cluster separately causes issues with updates, monitoring, and applying rules consistently. Operating from a single point makes everything easier: it’s simpler to manage and ensures changes and rules are applied the same way across the global infrastructure.
Avoid cluster specific configuration
Currently, we copy/paste a cluster template directory and then replace placeholders with the right values from a specific cluster. However, we can avoid this by utilizing a feature provided by Flux known as post build variable substitution, described here: https://fluxcd.io/flux/components/kustomize/kustomizations/#post-build-variable-substitution.
In essence, this approach is quite similar to our current process, but it involves leveraging a feature offered by Flux. There are some risks associated with this approach, mainly:
- Creating a dependency on this specific feature, which might cause issues if we decide to switch to a different GitOps implementation.
However, there are also advantages to this method:
- Most of the configuration can be shifted to a configmap, which we already have in place. From there, we can substitute these values directly from the configmap.
- It will assist us in standardizing cluster configurations. Currently, if we modify the cluster template, we need to replicate these changes across the entire list of clusters. Utilizing this approach will streamline this process and ensure alignment across configurations.
Enhance self-service
Right now, our users can automatically create their tenants on the platform, following a defined approval cycle based on adidas’ internal policy. However, there’s still room for improvement. For instance, the deletion/decommissioning of these tenants isn’t automated yet.
Similarly, we’re focusing on provisioning dedicated tenants (clusters) instead of shared ones. This shift will enhance our platform’s capabilities and meet specific user needs more effectively.
Ephemeral clusters
We’re working on enabling users to create ephemeral clusters, whether connected or disconnected from our internal network. To achieve this, we’ll work on automatic infrastructure deployment from within the cluster. When a new cluster appears, it will connect to our network, set up necessary AWS resources, and request internal firewall rules.
Onboarding new teams
We’re bringing new teams onto our configuration platform, which is the foundation for everything we do on our container system. Our goal is to help these teams use the platform more effectively.
We’re not just adding teams; we’re building a collaborative environment where different specialized groups — like monitoring, API, and security — work together smoothly. This teamwork helps us improve how our system operates.
Our aim is to create a space where each team brings its expertise to the table, making our entire system stronger. This collaboration encourages sharing ideas, learning from each other, and making the most of what our platform offers.
App platform
This project is a big deal on our to-do list. We aim to create a new setup that controls how both our platform and some applications grow and change over time.
The platform keeps evolving, but sometimes it’s tough for applications to keep up with these changes. That’s why we want the platform to handle these updates instead, making sure everything runs smoothly even as things grow.
Thanks
Thanks for joining us on this journey through our container platform’s evolution. We’ve covered a lot, from improving how things work to making it easier for teams to do their jobs.
We’ve shown how teamwork and innovation drive us forward. But this isn’t the end of the road — it’s just a checkpoint on our way to an even better platform.
So, let’s keep pushing boundaries, thinking big, and supporting each other. There’s plenty more to come, and we’re excited to keep moving ahead together!
The views, thoughts, and opinions expressed in the text belong solely to the author, and do not represent the opinion, strategy or goals of the author’s employer, organization, committee or any other group or individual.
