It's limited in Azure by the size of the VM (K8S node) which clearly impacts the scalability of the solution. But, that being said, the major issue for us was the number of disks you can attach to a VM. We can manage quite deeply POSIX accesses (👍), the throughput/performance is there as we can use Premium SSD. Disk(s) created are attached to the VMs (k8s node) where the pod runs.

Azure Disk is based on the block-devices created on-demand by Kubernetes using Azure API.

It's obvious that there is an issue with this as we are talking about a CMS solution managing content and access permissions on what you expose on the Internet. No way to modify file and folders access mode and their ownership for everything created on that kind of volume. The main drawback for our use case if that this is not entirely POSIX compliant. Kubernetes creates on demand the volume on top of the Azure File feature.

Regarding Azure Files ‘CIFS’, this solution is based on file share.

With Ephemeral Storage, the application content is removed any time the pod is deleted (as suggested by the name) which does not satisfy our persistence need.

Let us describe what were the constraints of other solutions available: There are several different storage bricks available in the Kubernetes ecosystem and our Michelin implementation:īased on the solution on the shelf, the choice was made to use Azure File ‘NFS’. This storage is a must-have to allow sharing content between Drupal pods and to persist all content brought by users even if we are losing or spawning new pods. Drupal needs shared persistent storageĪs said before, we decided to instantiate our Drupal on a Michelin Kubernetes platform (hosted on Microsoft Azure) to manage elasticity and high availability.įirst, regarding Kubernetes features, Drupal is a stateful system and has one important requirement that we had to cover before starting: shared & persistent storage, with good quality of service regarding throughput. Here below is a simple architecture overview of a typical Drupal implementation.

Obviously, there is a big User eXperience challenge behind hosting this showroom so it has to be Highly Available and scalable was equally important. As the first impression is often decisive in the success of a digital service that’s why it’s important to provide a best-in-class experience to maximize the famous “prospect to revenue”. Components used in Drupal ArchitectureĭDi showcase is the first touchpoint prospects will have with us. I was quite worried about such approach due to our requirements and the complexity to be … elastic and highly available. We’ve seen several implementations of Drupal on Infrastructure as a Service, and it was the solution proposed by our integration team. Our showcase is based on Drupal ( v9… no, you don’t need to know 😆) a famous CMS.

The ContextĪPI Monetization is about different tiers and services, and below I will describe the showcase part: how we implemented it and the way we handle the its elasticity. Among other things, you will find one of the technical challenges we encountered: the elasticity of the solution. This article aims to present a production implementation of our API portal developed on top of Drupal and hosted as a stateful application on a Kubernetes cluster. This approach is aligned with Michelin strategy around developing services & solutions in the mobility market. To meet customers expectations and provide them easy to use services helping them create value for their own, Michelin DDI is launching a Service Catalog, a great showroom gathering all available Michelin Connected Mobility APIs. We have more and more customers who are asking about accessing our data and ready to pay for it. On DDi we are starting our journey to API Monetization.

Drupal containers