Deltatre Cloud Native Journey

The Cloud Native Journey of the world leader in sports and entertainment technology
Deltatre Cloud Native Journey
azure-devops icon

The client

Deltatre is a leading company in the sports industry, specialising in the creation of graphics and tools for journalism and live television broadcasts.

The objective

Pushing the automation accelerator to scale large volumes.

The challenge

Deltatre’s development team was at an advanced stage within the Cloud Native Maturity Model, but felt the need for support in the creation of an easily replicable and scalable white-label project that could give a boost to automation. Initial requests included:

  • to validate the ongoing implementation of GitOps as a pivotal technology for release automation, centralised project repository management and access segregation
  • introducing best practices, speed and quality of release, standardising project delivery
  • strengthen a multi-cloud/cloud-agnostic approach (avoiding vendor lock-in)
  • optimise the local development process by making people productive within their team in a shorter time
  • increase the operation-side skills of developers (Shift Left)
  • increase the by-design security level of the current infrastructure (Shield Right)

The solution

Any Cloud Native Journey is a journey that addresses the entire software lifecycle and crosses the organisation in terms of processes and people, as well as technology. It is always very challenging, but in this case it was particularly interesting because of the maturity of the customer’s team with whom we worked assiduously (maturity in the sense of the Cloud Native Maturity Model).

In the initial phase, we always proceeded with a thorough assessment made up of meetings and dozens of questions to get a clear picture of the starting context and to avoid false or trivial steps. The longest meetings were fortnightly, while a quick 30-minute meeting was held weekly to assess the status of progressively agreed tasks.

For the shared journey to work, in fact, a continuous exchange of information and details and not just access to code and infrastructure is essential. This is the reason that drove us to an experiment, which we can define as successful, of constant journaling: not a simple record of the meetings, but an attempt to analyse at each step partial objectives, problems identified, solutions proposed and then implemented, until arriving at a list of ’to do’s’ that traced the direction of the backlog.

The first phase of the CNJ involved the entire operations side, specifically the bootstrapping of a new project based on Forge, a highly scalable publishing platform in Deltatre’s product portfolio. Analysing the current workflow, we identified those steps that still required manual or sub-optimal steps and could be automated. What emerged was a set of optimisation activities, resulting in an issue backlog, for which we proposed the creation of a seed IaC project that would automate and standardise, also in terms of security, all those otherwise manual steps required during the stab of a new project (such as the initial configuration of the Cloud Vendor and its repositories).

During this phase, it also emerged that the tasks to be performed by the operations team, from the initial bootstrapping of the infrastructure, the delivery of access credentials to the platform, the subsequent bootstrapping of the CI/CD pipeline, and the setup of the staging and production environments, usually took less time (2-3 weeks at most between support and optimisation) than the several weeks required for the development and design customisation of the frontend solution.

After concluding the collection of information regarding the developers’ workflow, from how the machine setup is done to how communications are integrated between the various teams, through the sharing of infrastructure and application front-end code, we concluded that the consistency between the development environment on the local machines and the development environments created internally in the pipelines should be increased, working on the creation of a local containerised environment to:

  • ensure the alignment of the versions of the various software/libraries used by individual developers
  • promote consistency with deployment pipelines that would share the same configuration
  • ensure that developers can start their activities without having to wait until the development environment is actually ready
Considering, therefore, that the activities to be performed by the developers take up most of the project time, we felt it was important to devote a second phase to identifying those points of intervention that could improve the daily developer experience (DX). Among the considerations that emerged:
  • automating the registration and authorisation of users on the authentication platform created for the start-up of a new project
  • automating the creation of the schema with the initial structure of the Forge frontend pages
  • automating the initial release phase of a new frontend module, creating some templates from which to start and speeding up the initial integration phase in the CI environment
  • with a view to 'shift-left', adding active Git Hooks in the developer's local environment to automate the execution of code linting tests with SonarQube; this would allow code issues to be identified without having to wait for pipeline execution
The last phase focused on High Availability, CDN utilisation and observability of the customer’s systems, which led to a subsequent evaluation of autoscaling tools and Cloud Cost Analysis. On the whole, the customer’s GitOps strategy was already very well set up, so much so that our intervention went in the direction of enhancing it in such a way that all changes to the cluster would only be possible via GitOps: manual changes would be completely invalidated.

We conclude with a couple of remarks that we find interesting from our experience:
  • regardless of the specific objectives of a Cloud Native Journey, it is often the case that the desired statement of Cloud Agnosticism is often countered by ties to the present vendor that always seem to be much stronger than one realises, if only as a matter of 'we know how to handle it'
  • the start-up of CNJs very frequently brings different teams to the same table, teams that despite belonging to the same company may never have had the opportunity or felt the need to confront each other before. This is an extremely interesting side effect and mostly effective in terms of resolving any communication knots or procedural understanding. To be taken into consideration

Get in touch

Follow us on social media
Listen to Continuous Delivery