Serverless, Decoupled Drupal With A Hybrid Cloud Approach For A Global Resort Developer

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.

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.

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.

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.

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 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.

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.

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.