Deploying Magnolia CMS to cloud infrastructure

This blog by Abhay Kumar from Priocept presents some challenges when deploying applications to auto-scaling cloud infrastructure such as Amazon Web Services (AWS) or Google Cloud Platform (GCP).

One of the key technical benefits of cloud hosting, over traditional on-premise infrastructure, is the ability to auto-scale the number of servers up and down to meet traffic loads. This flexibility provides a cost-effective way to cope with peaky website traffic.

Magnolia’s transactional publication model allows web content to be physically separated between “authoring” and “public” infrastructure, with content pushed from authoring to public servers according to the defined publication workflows. The Transactional Activation module ensures that any number of public instances are kept in sync with definitive, published content as defined by the authoring servers.

This model provides a clean and efficient solution, but presents some challenges when deploying applications to auto-scaling cloud infrastructure such as Amazon Web Services (AWS) or Google Cloud Platform (GCP). This blog examines the issues and describes the high-level process that Priocept have implemented to overcome these challenges. For a more detailed explanation, see our recent webinar on this topic.

Content delivery servers (public instances) are referred to as “subscribers” (in Magnolia terminology) as they are designated to receive content from the authoring server. However, the subscription is actually set on the authoring server and the subscribers themselves have no knowledge of the existence of their own subscriptions.

When a publication (otherwise known as “activation”) event is triggered from the authoring server, a content object is created and physically sent over HTTP to each subscribing server, which then imports the new content into its public (live) database.

Figure 1: Magnolia subscriber publishing model

This process works nicely in a pre-defined infrastructure configuration, where the author knows about all of the subscribing instances, and new instances are either never added or removed, or are added and removed manually – for example via an IT change request process, possibly with a turnaround time of several days.

Using an Infrastructure-as-a-Service cloud platform, the ephemeral nature of cloud servers means that new public instances can be created and disposed of at any time, fully automatically, as part of auto-scaling events, deployments, or patching processes that are managed by the cloud infrastructure framework.

In this scenario, deploying a standard Magnolia solution to cloud infrastructure requires additional development work, to integrate Magnolia with the cloud framework that is orchestrating the creation and termination of new public instances. Without this, the Magnolia authoring servers will lose track of which public servers exist.

The diagram below illustrates the problem. This shows that the Public Web Server 3 was recently created as part of an auto-scaling process. This may have been caused by a sudden spike in traffic to the website that this Magnolia instance is hosting.

A load balancer sits in front of the Public Web Servers. If it brings the new instance into the load now the new public instance will not contain the latest content, or indeed any content, and will therefore serve a blank site for 1/3 of website users.

The following diagram describes the orchestration required between Magnolia and Amazon Web Services to achieve a fully elastic solution. The objective is to make the new Public Web Servers available to serve the website only when they have the latest content published to them.

The diagram above shows a “Lifecycle Hook” configured on the EC2 Auto-Scale Group in AWS. This triggers events when new Magnolia EC2 instances are created or terminated by calling a Lambda function via SNS (Simple Notification Service).

The Lambda function’s responsibility is to call into Magnolia to notify that a new instance has been added or removed. If it was added, content is published to the newly created Magnolia Public Server using the Magnolia Synchronization Module.

An Auto-Scaling Group healthcheck configuration is used to check the status of the public server. It does this by hitting a REST end point on the new Magnolia Public Server that returns the status of the server (200 if it contains the latest set of content).

This process requires developing bespoke services both in the cloud infrastructure and in Magnolia, but fully automates the auto-scaling process, providing a content management infrastructure that is both highly resilient and able to scale horizontally to deliver large volumes of traffic.

Magnolia is an inherently cloud-friendly platform that is often deployed to Amazon Web Services. To fully reap the benefits of these platforms, Priocept recommends consideration of the approach defined above.

Priocept helps its enterprise clients in sectors including travel, media and entertainment, retail and financial services, to architect their Magnolia solutions on AWS. For advice on hosting Magnolia on cloud infrastructure, or general advice on cloud services, please get in touch.

Priocept are official consulting partners for Magnolia, Amazon Web Services and Google Cloud Platform.

Watch this webinar to get the most out of your CMS deployment on AWS.