One of the key benefits of cloud hosting over traditional on-premise infrastructure is the ability to auto-scale infrastructure 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.
Subscribers That Don’t Subscribe
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.
Magnolia Publication 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.
Priocept’s preferred approach to this problem is to develop a set of jobs to call APIs in the cloud platform and Magnolia to create a fully automated solution.
This process contains the follow steps:
1) Cloud infrastructure is configured to trigger auto-scaling events whenever the CPU utilisation of public servers exceeds a certain threshold, or other similar scaling rules. The auto-scaling event creates a new server instance (public web server) and supporting database.
2) Once the new server is created, a separate job is triggered by the cloud auto-scaling infrastructure, to call the Magnolia REST API on the authoring server to write the IP of the new web server to the subscriber settings in the “config” workspace (“/server/activation/subscribers”). This process simply adds a subscriber to the publishing process. The reverse process applies when the infrastructure is “scaled in” and a public Magnolia server is removed.
3) Magnolia’s Synchronisation Module is used to bring the new public instance up to date with the latest published content. This ensures that only content that has been published to other subscribers is published to the newly created environment. To achieve this the “Magnolia Auto-Scale Job” calls the Magnolia REST API to write to the subscription path to the synchronisation module: “/modules/synchronization/commands/synchronization/synchronize/subscribers/subscriptions”. The paths of any sites to synchronise are added and the module then synchronises all subscribing public instances, which will include the newly created one.
4) A “healthcheck” end point is implemented on each public instance to indicate whether the instance is fully synchronised with the latest content. There is no web service call in Magnolia that provides the publication status of a given public server. To find out when the publication is complete, a dummy piece of “marker” content is added in the content tree. The presence, or absence of this content on a given public server can then be used to verify if that server is in synchronisation with the latest published content on the authoring server.
5) Once the healthcheck is reporting that content has been successfully synchronised to the new server, the cloud infrastructure (load-balancer and/or auto-scaling group), will automatically bring the new server into load so that it starts serving traffic. At this point the auto-scaling process has completed, the new public server instance is serving content, and has been registered as a subscriber so that it receives all subsequent content publications from the authoring environment.
Magnolia Auto-Scaling Process
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.
It is also worth noting that Magnolia have released a cloud-based service, Magnolia NOW. This provides a fully managed cloud CMS service. It is essentially the same enterprise CMS product, but managed and supported by Magnolia, running on Amazon Web Services.
As this is a fully managed CMS service, all of the issues above effectively become Magnolia’s concern and not that of the implementers. For organisations that don’t have the IT expertise to support their own cloud solution, it may make sense to delegate hosting and support to the vendor by taking advantage of Magnolia NOW.
Magnolia is an inherently cloud-friendly platform that is often deployed to services such as Google Cloud Platform and Amazon Web Services. To fully reap the benefits of these platforms Priocept recommends consideration of the approach defined above.
Priocept is helping its enterprise clients in sectors including travel, media and entertainment, retail and financial services, to architect their Magnolia solutions on AWS and GCP. 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.
In a future article, we will cover the specifics of implementing the above architecture on AWS and GCP.