See! White and Fluffy

See! White and Fluffy

It’s been a little over a year since we started the “Tridion in the Cloud” project at SDL. Traditionally, SDL’s flagship content management system, Tridion, was is an on-premise solution. Customers either installed the product on their own hardware or private cloud or with an SDL partner. However, Tridion was the only SDL product was not possible to host with SDL. So, a year back we set out to change this so that SDL’s customers that wanted to have a completely managed SDL solution.

Code or Infrastructure

During my day to day role, I talk with many of SDL’s customers who are looking to re-provision their Tridion environments and are taking the opportunity to look at cloud providers like AWS or Azure. This is typically IT driven on the idea of cost reduction or outsourcing responsibility of the platform to experts. What I rarely come across is the idea of moving to a more agile approach with regards to infrastructure. Public cloud providers like AWS and Azure have APIs for the creation of infrastructure using code. This means that you can move from treating infrastructure as a series of interconnected virtual machines (servers) to code objects. This concept is not one that IT teams grasp easily because infrastructure is something you provision and then hand over to the application team to install something onto it. Even with templating of virtual machines, which is common place in IT teams, IT teams still work on the very fixed idea of how hardware has always been provisioned.

When you treat infrastructure as code, then you can roll up the build of infrastructure into the deployment of the platform (Tridion) and the deployment of the implementation (your websites) and do this from a single provisioning process. If each layer in that process is abstracted, then you can even replace different layers with new or updated layers (e.g. an updated Tridion version). For a single organization this makes little sense to go to the effort of coding all of this just for Tridion but it would make sense to do this as an approach for all your deployed applications. For SDL, it makes perfect sense to do when you are managing many Tridion implementations. Not only does it make building and rebuilding environments fundamentally easier but also it make configuration changes easier to deploy, moving to different regions is straightforward and issues with individual servers can be quickly removed by replacing the server within a short period.

Provisioning

When we provision environments at SDL we undertake the following steps;

  1. Provisioning of the infrastructure, security groups, DNS, tagging and storage
  2. Installation of the Tridion application, required modules, hotfixes and pre-requisites
  3. Configuration of the installed software
  4. Deployment of the customer’s implementation
  5. Hook each infrastructure component to monitoring

The process is very quick. If you would compare this to a traditional physical deployment, you can expect around 12 weeks to order and install the hardware and then an additional 1-2 weeks to get all the software installed. With a fully automated approach, you can expect – once you have everything set and ready to go – that an environment can be built in less than an hour. Preparation time is of course, potentially time consuming, but once that is done the process is repeatable in the event of failures or updates to the platform.

To do this you can control the provisioning process with technologies such as Chef or Puppet and leverage any technologies that your cloud provider might have to make this easier. SDL uses AWS CloudFormation. This is not transferrable to Azure so if you would want to be agnostic of cloud provider you will need to control the process completely with 3rd party tools rather than leveraging cloud provider specific technology. SDL uses CloudFormation because it is very powerful and to code something similar would have been time consuming. This was labeled as pragmatic portability by SDL because the built provisioning could be ported but we did not want to code forever for scenarios that may or may not happen. Better know where it is not portable and keep coding to add value to the Tridion product.