Skip to main content

Take Magnolia to the cloud, but keep one foot on solid ground

Posted by rah003 on March 30, 2014 at 11:02 PM PDT

While parts of the cloud IT that are still being hyped are changing rapidly, the whole segment is not past the hype yet. The cloud report [1] that Gartner published 9 months ago still holds true today.

Reports of disillusioned customers of such solutions [2][3] are a clear sign that the hype might have reached its peak for most parts of cloud offerings, though. And while many articles discuss the failure of cloud providers, not so many actually look into what the failures mean for users of cloud services. Understandably, no customer that bet their business on cloud services and is then affected by failure wants to admit to wrong judgement publicly. Take, for example, the failure in Oct 2013 [4], or the outage of Casablanca INT and their Big Blue One cloud service [5] where, even though it is a small cloud, the damage was estimated in the millions - for only a few days of outage [6].
And while clouds as a whole and services they offer continue to mature, their prospective customers are increasingly becoming aware of potential risks. This process, while very natural, re-shapes the cloud offerings towards a new silver bullet solution - hybrid clouds [7]. The trend towards hybrid solutions has been adopted in IT many times, whenever monolithic solutions didn’t lead to the desired results. And not just in IT: the car making industry has been producing hybrid cars for years now, and engineering has been working with hybrid materials (they call those composites) en masse for nearly a century. Please keep on reading. I promise that the generic intro is over and I will get to the point soon.

Taking the cloud (and Magnolia) to the next level

We can now see this as an emerging trend in the Cloud area, too: so called Hybrid Cloud Solutions are on the rise, starting from the simplest solutions such as hybrid (private/cloud) storage [8] or hybrid hosting [9], moving to more complex solutions such as hybrid cloud deployment of your Magnolia CMS installation.

Due to its architecture that’s relying on a set of semi-independent, purpose configured instances, Magnolia has always been geared towards scaling not just vertically (by using more powerful hardware to run the instance), but also towards scaling horizontally (by simply adding more instances). The horizontal scalability feature was not just designed to increase the throughput, but also as a means to provide customers with configurable instances that could be optimized towards specific goals without affecting the rest of the web hosting infrastructure, as shown in the diagram below.

In the most basic deployment of Magnolia CMS, the client ends up with a single authoring instance and a single public instance. While both instances are running the same version of Magnolia CMS, the authoring instance is configured to support the task of authoring the content, while the public instance is optimized to serve the published content to the public. This separation not only makes it easy and possible to optimize the widely opposing needs of authors and the public, it also offers free additional measures that can be taken to ensure the security of your data.

And while this sort of minimalistic deployment allows you to run Magnolia CMS with a single public instance so to have an instant failover, most common customer scenarios are set up with 3 instances, ensuring that the public consuming your web content will not be affected if one of the instances goes down for whatever reason. Unless, of course, you choose to host all of those public instances in the same data centre, in which case all instances would go down if the whole data centre collapses. This would be a conscious risk on your end, driven perhaps by cost cutting measures, rather than something that the software dictates.

Building a hybrid cloud solution with Magnolia

This basic architecture is actually key to using Magnolia CMS in combination with cloud infrastructure to build a hybrid cloud solution. But of course, this is not the end of it. While it allows you to keep your private data secure prior to publishing, as well as giving you some public instance for emergencies on-premise and having some other instances in the cloud, it doesn’t do anything to alleviate the pain of having to spin up those multiple instances, pre-populating them with the content that is already published to the others, and registering them with the authoring environment as subscribers so it knows to publish the content there. You’ll need more than architectural choice here. The new REST API delivered with Magnolia 5.2 allows you to do all that. You were always able to execute the synchronisation command to sync new instances, you were always able to add new subscribers to the author, but it used to be a manual process. Now, with the new REST API, you can simply script those operations and add them to your startup script for new cloud based instances so they can register and sync themselves when going up as well as deregister when going down.

Additionally, you might want to make this process even more simple and instantaneous. Look at the following deployment schema:

Here, we do everything we did with the first setup I described, to make sure any unpublished data of yours (such as performance reports, new products or services or upcoming campaigns) stays private: we use an on-premise based author instance and one emergency public instance, to cover up possible cloud failures. However, we changed our cloud hosted instance from a set of instances to a cluster of Magnolia instances. This takes advantage of the fact that clustered instances share the same data set and thus don’t need to synchronise the data or register themselves as subscribers into your Magnolia CMS installation publishing schema. As long as one node in the cluster is registered and has all the latest data, they all are going to share and serve that data to the public, allowing you to bring new instances up and down hassle free. This gives you both the “hybrid cloud” as well as the “cloud bursting” offering, thanks to the speed with which you could be spinning up new instances, to react to spikes of web traffic in real-time.

There are many more advantages to this deployment that I can’t explore here at this point. Examples include integration options such as taking advantage of the publishing mechanism to expose public-sharable data from other internal-access-only infrastructure with a flexible synchronisation schedule. Another option is the use of cloud based clustered configuration to pair instances with other already-in-the-cloud offerings that your company might currently employ, to provide real-time data to web users.

And, if you want to listen to me talking about Magnolia in the cloud some more, you should make sure to attend Magnolia Conference in Basel, June 24 - 26, where I’ll present alongside Daniel Menges at ETECTURE@Ogilvy [10] See you there!