Loropiana

An iconic Cloud Native Journey for an Italian excellence: the containerisation of fine yarns
Project
Loropiana
Technologies
azure icon

The client

Loro Piana is a world-class artisan excellence in the manufacture of luxury products and fabrics from the rarest and most precious raw materials, founded in 1924 in Northern Italy and since then a reference point for the world’s most precious yarns thanks to continuous investments in raw materials and production and constant technological innovation. In 2013, the Piedmontese fashion house became part of the LVMH group, benefiting from exceptional synergies while remaining faithful to its heritage and tradition. Loro Piana has 9 production sites all located in Italy, 171 single-brand shops worldwide, 5 million meters of fabric produced each year.

The tension towards innovation is also evident on the digital and infrastructural front: the internal IT division is fully aware of how adopting a Cloud Native approach is now essential.

The objective

Start a path towards the Cloud Native approach that would improve development processes and enable a gradual modernisation of the legacy.

The challenge

The customer needed to understand whether the migration to the Cloud, and specifically to Kubernetes, of one of their legacy applications was feasible, sustainable in terms of resources and concretely effective. In detail, the objectives were

  • Deepen knowledge in the Cloud Native domain with a particular focus on Kubernetes.
  • Evaluate how to transfer from an OnPrem architecture to Public Cloud.
  • Prepare the migration of some development projects to the Cloud: application for Retail on Line 'ROL' management (Java-based); static sites (Apache-based).
  • Support the improvement of development processes.
  • Introduce best practices, speed and quality of release.

At the time of the maturity level assessment according to the Cloud Native Maturity Model, a number of infrastructural and organisational difficulties, such as the lack of documentation or the retention of manual intervention on a number of tasks that could already be automated, made the challenge even more interesting.

Scheme of apps containerization
© Pini Reznik, Jamie Dobson, and Michelle Gienow
An orchestrator, usually Kubernetes, is essential for coordinating the deployment and oversight of microservices within a distributed container-based application, allocating them to various machines dynamically upon execution.

The solution

The evolutionary stages towards the Cloud Native approach cover several different areas, both technical and organisational:

  • Culture
  • Solution design
  • Team/Competences
  • Process
  • Architecture
  • Maintenance
  • Delivery
  • Provisioning
  • Infrastructure
The solution proposed to the Customer excluded certain aspects that were not relevant downstream of the assessment, depending on whether the focus was more or less technical and oriented towards the ’training on the job’ of the development teams, or by virtue of the composition of the team involved.

In the context of the suggested Cloud Native Journey, a complete platform for source code management and Continuous Integration / Continuous Delivery pipelines based on Gitlab CE was implemented on Azure.

Scheme of the development and feedback flow of Continuous Delivery
© Pini Reznik, Jamie Dobson, and Michelle Gienow
Maintaining a short build/test/deliver cycle ensures that code remains continuously prepared for production, facilitating swift release of features to customers.
This enables developers to promptly receive feedback from customers and adapt accordingly.

By means of a fully IaC (Infrastructure as Code) approach, via ‘Terraform’ and appropriate CI pipelines, the following were deployed:

  • Kubernetes AKS Cluster
  • Gitlab Server Community Edition
  • Gitlab runner Kubernetes based (module)
The post-installation analysis of this platform provided the perfect opportunity for a ‘full immersion’ in the world of Infrastructure as Code (IaC), deployment automation through Continuous Integration and Continuous Deployment procedures, and Kubernetes-related issues, from the theoretical foundations to implementation.

Specifically, Loro Piana’s Cloud Native Journey included the following steps:

  • Deployment using a container architecture, to standardise local development environments and release processes.
  • Implementation of automation for building the infrastructure elements necessary for the setup of the development and production environments using Terraform and IaC.
  • Installation of Gitlab as a versioning system as well as a tool for creating CI/CD pipelines.
  • Use of CI also to generate deployment-ready artefacts.
  • Implementation of infrastructure monitoring system with corresponding alerting system.
  • Application of CD principles to increase the ability to release frequently and reliably.
  • Keeping the infrastructure up-to-date through commit and merge requests on the IaC repositories.
With regard to the software dedicated to Online Retail and its architecture at the start of the project, the focus was on the containerisation phase, which required in-depth studies of the architecture itself, development tooling and resource management of a Java-based solution. During the Cloud Native Journey, therefore, the POC related to ROL had as its scope the containerisation of the local development environment.

The results

The PoC confirmed the feasibility of what the client had set out and expected to achieve, and also proved to be easily replicable. After the project, one of the key deliverables expected by the client was an analysis report on the results obtained and the state-of-the-art achieved.

Scheme of different phases of a Lift And Shift process during a Cloud Native Journey
© Pini Reznik, Jamie Dobson, and Michelle Gienow
It's crucial to avoid tackling a Cloud Native Transformation through a mere lift and shift of the current system to the cloud.
Instead, consider selectively migrating certain components towards the end of the process, which could prove beneficial.

What were, in detail, the main results achieved?

  • A CI/CD and code versioning platform (GitLab) that can be easily maintained and replicated through an Infrastructure as Code project.
  • Increased knowledge and awareness of what needs to be done to transform a legacy application into a Cloud Native application, following the principles of the methodology known as 'The twelve-factor app'.
  • Two Kubernetes clusters, one for development environments and one for production environments, could be deployed using GitLab's CICD pipelines.
  • A series of POCs consisting of some Gitlab projects in which a simple static website written in HTML and PHP versioned in git was containerised and deployed on different Kubernetes clusters (development and production) using GitLab's CI/CD pipeline.
  • The realisation that migrating a legacy application to Kubernetes is not always possible without substantial refactoring; the knowledge acquired during the course provided the necessary tools to objectively understand the minimum requirements that an application must meet in order to function in a dynamic environment such as Kubernetes. On the other hand, it emerged that there are also other ways of approaching migration to the cloud in a more gradual manner, even if it is by starting with a simple lift and shift and taking advantage, for example, of the Database as a service services that the cloud vendor makes available.

Get in touch

Follow us on social media
Listen to Continuous Delivery