Deltatre chose Flux, Helm and K8s to automate and scale
Challenge
Deltatre is a leading company in the sports industry, specializing in the creation of graphics and tools for journalism and live television broadcasts. Deltatre’s development team was at an advanced stage within the Cloud Native Maturity Model, but needed support to create an easily replicable and scalable white-label automation project. Initial requirements included:
- Validate ongoing implementation of GitOps as a pivotal technology for release automation, centralized project repository management and access segregation.
- Introduce best practices for release speed and quality, standardizing project delivery.
- Strengthen a multi-cloud/cloud-agnostic approach, avoiding vendor lock-in.
- Optimize the local development process by expediting productivity of team members.
- Increase operation-side skills of developers (shift left).
- Increase by-design security level of current infrastructure (shield right).
Solution
Deltatre tackled automation and scalability challenges by leveraging Kubernetes, Helm and Flux. These tools allowed teams to streamline operations, enhance deployment efficiency and effectively manage extensive software libraries.
Impact
This transition to Kubernetes, Helm and Flux not only optimized their infrastructure and development processes but also increased flexibility and responsiveness to evolving industry demands, accelerating adoption of progressive approaches like “shift left” and “shield right.”
Projects used
By the numbers
50% reduction
in pipeline runtime
50% reduction
onboarding for reproducible dev envs
Improved SCM
through cross-team software/library use
Advancing on the Cloud Native Journey
A cloud native journey is always a journey that addresses the entire software lifecycle and crosses the organization in terms of processes and people, as well as technology. It is always challenging, but in this case, it was particularly interesting because of the cloud native maturity of Deltatre’s team, with whom we worked assiduously.
In the initial phase, we made a thorough assessment, through meetings and asking dozens of questions, to get a clear picture of the starting context and avoid false or trivial steps. In-depth meetings took place biweekly, while quick 30-minute weekly meetings were held to assess the progress of ongoing work.
For the success of our shared journey, not only access to code and infrastructure, but also a continuous exchange of information was essential. This drove the decision to adopt regular journaling, not to simply record meetings, but to analyze, at each step, temporary objectives, problems identified, as well as solutions proposed and implemented. It was a successful experiment, resulting in actionable to-do lists to clear out our backlog.
The Operations Side
The first leg of the journey involved the entire operations side, with particular focus on bootstrapping a new project based on Forge, a highly-scalable publishing platform in Deltatre’s product portfolio. Analyzing the current workflow, we identified steps requiring manual work that we could automate. What emerged was a set of optimization activities and an issue backlog, for which we proposed the creation of a seed infrastructure-as-code (IaC) project. The project would automate and standardize all manual tasks required during the initiation of a new project, including security (for example, initial configuration of cloud resources and repositories).
During this phase, it also emerged that the operations team’s tasks usually took less time than the development and design of the frontend solution. The initial infrastructure setup, delivery of access credentials to the platform, subsequent setup of the CI/CD pipeline as well as staging and production environments, took 2–3 weeks at most, between support and optimisation, compared to several weeks for the frontend solution.
After collecting information on developer workflow, from machine setup to how communications are integrated between various teams, to the sharing of infrastructure and application front-end code, we saw a need for greater consistency. That is, consistency between the development environment on local machines and internally-created development environments in the pipelines should increase. The ultimate aim was to create a local containerised environment to:
- Ensure alignment of various software/library versions used by individual developers.
- Promote consistency of deployment pipelines sharing the same configuration.
- Ensure that developers can start activities without no need to wait until the development environment is ready
Enhancing DX: The Development Side
Considering that developer activities take up most project time, we devoted a second leg of the journey to identifying ways to improve the daily developer experience (DX). Among the changes we made:
- Automated user registration and authorisation on the authentication platform for new projects.
- Automated creation of the schema with the initial structure of the Forge frontend pages.
- Automated the initial release phase of a new frontend module, creating starting templates and speeding up the initial integration phase in the CI environment.
- With a view to “shift-left,” added active Git Hooks in the developer’s local environment to automate code linting tests with SonarQube; this would allow code issues to be identified without waiting for pipeline execution.
The last leg of the journey focused on high availability, content delivery network (CDN) utilization and system observability, leading to evaluation of cloud cost analysis and autoscaling tools. On the whole, Deltatre’s GitOps system was already very well set up; in fact, our adjustments only enhanced it so that changes to the cluster would be possible only via GitOps, invalidating any manual changes.
We conclude with a couple of the biggest lessons from our cloud native journey:
- Regardless of the objectives of a cloud native journey, often cloud agnosticism is desired yet countered by ties to the present vendor. Such ties are frequently downplayed with notions like, “we know how to handle it,” but may be far stronger than realized.
- A cloud native journey often calls to the table different teams, which, despite belonging to the same company, may never before have directly communicated with each other. This is an extremely interesting side effect, and mostly effective in terms of resolving any communication knots or procedural misunderstandings.