<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=278116885016877&amp;ev=PageView&amp;noscript=1">

Customer:
Luxury Resort
 

In partnership with:

wunderman-logo-color-left-1

Industry:
Hospitality
 

Services:
Development | DevOps | Agile Delivery

 

Technologies:
Infrastructure as code (IaC) | API Gateway | Content Delivery Network
 

Tools(DevOps Specific):
Terraform | GitLab | Jenkins

 

Platform:
Amazon Web Services | Aliyun

 

Implementing Multilingual, Headless, Serverless Drupal

We helped a luxury resort client consolidate their different web properties onto a single platform. This enables them to offer their users modern content experiences faster, to market themselves better, and to become more profitable.

 

About the customer

The customer is a developer of casino gaming and entertainment facilities. They own and operate a large number of facilities throughout Asia. Based in Hong Kong, they have a largely Chinese audience. This situation set Axelerant up for a truly cutting edge, global endeavor.

20,000+

employees

280+

International awards

16

years in operation

Business Challenge

The client was facing issues due to their previously disjointed efforts in the digital technology ecosystem. They were not using any specific technologies across their web properties, and this left them with a very unstructured approach to content management. 

They were still running basic, outdated HTML/CSS websites and their content was effectively scattered across different HTML files. It became impossible to effectively manage this kind of architecture beyond a certain point—these platforms were not future-ready.

The client wanted to set up a Content Management System (CMS) so that a single solution would answer the content management needs for all their brands. They needed a multi-site solution.

Their objectives were: 

01. To consolidate their different web properties.

02. To raise profits by offering better experiences.

They needed to migrate to a single platform that allowed them to effectively serve each brand and its capabilities.

They needed to manage content more efficiently, offer better experiences faster than before, and become more profitable.

Axelerant’s skills and experience, backing by Acquia and our alignment with the client’s ambitions made us the right choice to support Wunderman through this implementation. 

Solution

The client decided to use decoupled Drupal with Acquia Cloud Site Factory (ACSF)—so that their different websites could have the same base but also an easily manageable content structure—with the latest version of Angular on the frontend. Unlike conventional decoupled Drupal for enterprise which is usually hosted in Acquia Cloud, this implementation brought in several other elements that make the architecture unique.

Wunderman-Devops-Decoupled-Drupal-Desktop
Wunderman-Devops-Decoupled-Drupal-Mobile

Above: Serverless, decoupled Drupal in a “hybrid” cloud environment, visualized

Wunderman-Devops-Different-Regions

Different Regions To Address

Since the client is a luxury resort chain, they had different regions to address. Content needed to reside closer to the user in a central base. Eg. Content in India would need to use a server in Mumbai. Hence, Amazon CloudFront became a consideration.

Omnichannel-Support

Large Number Of Brands

Additionally, as a luxury resort chain, the client had multiple sites serving a number of brands. These needed to be unified with Acquia Cloud Site Factory rather than plain vanilla Drupal in order to establish a common backend with multilingual versions.

Wunderman-Devops-Multicloud-Architecture

Multicloud Architecture

The target audience was based mainly in China. Internet access in China is restricted, meaning there are delays to sites hosted outside the country, so we implemented an API layer connection between Amazon Web Services (AWS) along with Aliyun (Alibaba’s cloud offering) to expedite.

Wunderman-Devops-Multi-cloud-Architecture-Visualization
Wunderman-Devops-Multi-cloud-Architecture-Visualization

Above: Multi-cloud architecture visualization

 

Results
Wunderman-Devops-Multicloud-Architecture-Global-Reach

Global reach through multi-cloud approach

Our hybrid cloud approach enables the client to serve content worldwide, including key markets like China. The code is modularized so that a single Terraform script is able to handle both the AWS and Aliyun clouds.

Wunderman-Devops-Multilingual-Content

Faster, effective multilingual content

The client is now able to serve multilingual content (via Lambda as the proxy) to all its brands through a unified backend, with much faster content delivery. Elements get cached in the frontend and API responses are faster.

DevSecOps-Tooling-Automation

A future-proof solution

Also, now that they have APIs, the CMS is effectively working as an API, and in future it can be consumed by mobile hosts as well. This makes the solution easily scalable and future-proof.

 

Quote
“Axelerant shows much more professionalism and expertise than others.The client is very happy… we love working with them.”
Maggie-Tong-Circle-1
—Maggie Tong
General Manager,
Wunderman (Hong Kong)

 

Headless Serverless Drupal

Decoupled Drupal instances are still not very popular, and each such setup tends to be unique. In this instance, Axelerant implemented an Angular-based front-end and a headless Drupal site.

Amazon Web Services And Aliyun

As the client was present in multiple locations, we had to choose a CloudFront distribution. But that wasn’t all.

Due to the hosting restrictions imposed by the Chinese government, all sites needed to be hosted in two places. The .com version of the website is served by AWS and located in Singapore with the API hosted on CloudFront. The Aliyun website is hosted in a region called Shenzhen in China, and accessible through Aliyun’s CDN offering.

IaC And Terraform

We are believers in IaC (Infrastructure as Code), and when it came to implementing it, Terraform was our choice.

Given the multi-cloud approach and decoupled architecture at every level, there were multiple experts from different areas working on this solution.

Terraform, by default, stores state in a local file called terraform.tfstate. The use of local files makes it very complex for users from different teams to access the same state and ensure that no one else is running Terraform at the same time.

Fortunately, Terraform offers a concept known as “remote state,” and we implemented this.

Remote State

Remote state allows teams to share infrastructure resources in a read-only way without relying on any additional configuration store.

We used S3 buckets in AWS for remote state, and DynamoDB for table lock. For simplicity and a single point of truth, the S3 bucket holds the state for both the AWS and the Aliyun-based infrastructure.

The above snippet explains how the S3 bucket can be used to store the state of each Terraform plan.

Here, the S3 bucket is versioned. This is highly recommended for getting the state back in the case of accidental deletion of the state file.

You can also observe that prevent_destroy is set to be true for the lifecycle policy of the bucket.

AWS Lambda And Aliyun Function Compute

As the content needed to be displayed in visitors’ regional languages, Lambda (for AWS) was needed as the proxy to trigger custom server logic, delivering targeted, personalized content to website visitors.

A similar functionality was implemented in Aliyun with Function Compute.

Continuous Integration/Continuous Delivery (CI/CD) With Jenkins

For CI/CD on the project, Jenkins was used.

To keep the pipelines configured, we chose to stick with Groovy instead of creating them via the UI. Our approach was to define several stages and have meaningful steps in each stage of the job.

Each stage starts with a notifier function that might set an alert (like in a Slack channel) or some other communication.

An excerpt from the Jenkins file showing the linting stages can be seen below.

These different stages, defined in a Jenkins file, will get sequentially built and run once they are loaded as pipelines.

Handling failures within each stage can be done through effective utilization of exceptions.

✖