Julian Wraith

Menu Close

10 things to do when deploying SDL Web to the cloud

Now that cloud is on the uptake with almost every organization, it’s likely that during the next upgrade or new implementation of SDL Web you will be asked to move it to a cloud provider like AWS. What you should not do during this move is fall into the trap of just porting some virtual machines to the cloud and running it like you did before. The cloud is better than that (and it is 2016, not 2005), so you should investigate a little deeper in how you should deploy. So to help, here are 10 things to consider;

1.       Use SDL Web 8

It should go without saying that you should use the latest version of a product, but some organizations pull back from such steps until a product version is in a SP1. But with the new product release you get better support for the cloud from SDL. You can read my earlier post on the new infrastructure features that help deployment on the cloud but the main one you need to shoot for is the support for database-as-a-service from AWS or Azure

2.       Elastically scale delivery

In this nice article, the AWS Startup folks at Medium explain that the minimum viable product must scale in order to be a success; they are spot on. As your product is that website you are building then not implementing automatic scaling (or using something like AWS Elastic Beanstalk) of delivery should now be counted as a crime against humanity.

3.       Automate the deployment of your environment

Automating the deployment of an environment is more than saving a VM template of your build servers, but automating the configuration management, topology, software installations etc. This is essential in auto-scaling but deeply important when you are planning things like disaster recovery. The old school methods can go if you can automatically rebuild an environment inside 30 minutes.

4.       Implement Continuous Delivery and then Continuous Deployment

Rome was not build in a day and therefore you need to take this slow but most cloud providers have a CD pipeline available that integrates with the deployment options available at that cloud provider (see. Visual Studio Online or AWS Codepipeline). Get to the point where you can deploy a new version of the site (or part of it) multiple times per day in a robust way.

5.       Scale Publishers when needed

Number one complaint for publishing is it is slow when deploying lots of content. Well, following point four, you should not be able to spin up more publishers when needed. This does not per say need to automatic in response to load (but it could be) but it should at least be an automated process leveraging a graceful shut down and destroy.

6.       Process log files with a tool like Splunk

Now you have servers spinning up and down automatically you probably have little or no access to the running application. It is therefore important to put in automatic log file analysis to ensure that the application is running error free, you can spot failure trends and you can keep the overall health of the environment high. Applications will fail and that is OK, but you need data to proactively reduce the errors, feed into your continuous delivery pipeline and improve performance.

7.       Write custom monitors for SDL Web functionality

The cloud provides you with metrics for things like CPU and memory, but there are no monitors for specific and relevant SDL Web functionality. Is the publishing queue a little too long? Fire a warning to your integrated monitoring solution that something may need to change like a new publisher spun up to help with the load.

8.       Deploy new CD environments for temporary sites

You can easily spin up new delivery environment should you need to deploy a new site that will only last for a short period of time. This keeps complexity low on each site and impact to another site from the new site is impossible.

9.       Adopt a microservice architecture

Architecting your application in the microservice model means that CDaaS can be utilized and sites can just feed content from that. Further splitting your application into smaller functional components which can all be scaled separately will reduce software costs, improve deployment complexity, improve resilience and improve scaling.

10.   Test performance and scaling actively

Too often this is the last of the pile in regards to things to do. Automatic scaling does not remove the need to test performance, in fact, it makes it more important. In years gone by, if the site did not perform it just got slow and then probably crashed. Sadly, website visitors were used to that, but it does little for your business reputation. Now we can scale automatically, all this essentially means is that we keep adding new instances/servers until we meet demand. And what follows is a small heart attack when you read the monthly invoice.

Instead it is now more important that you need to keep your application performing well. Performance should be tested in the CD pipeline as well as on a frequent basis in production. Plenty of tools exist to support this and can help testing from different parts of the world if your site needs to respond to a global customer base.

New Infrastructure Features of SDL Web 8

SDL recently released the latest version of their web content management and this releases has some interesting changes from an infrastructure perspective that I would like to highlight.

Product Name Change

Firstly, whilst not an infrastructure change, the product has changed its name from SDL Tridion to SDL Web. The new name, Web, says a little bit more about what it does (at a very basic level) but does somewhat reject the kudos and history that comes with the name Tridion. The name “Tridion” is distinct and easily recognizable, Web is a little more generic and bland in my opinion.

The version number for the new release is 8 which is a throwback to the “R” releases of Tridion before SDL took over the Tridion company. The last product named in the “R” series was R5.3 and since then there has been the releases 2009, 2011, 2013 and now 8. It’s not directly logical that Web 8 should not actually be called Web 9, but 2009 and 2011 are really R5.4 and R6 respectively.

Improved Cloud Support

The new release has some heavy focus on changes to make it easier to deploy and manage Web. First up is the improved cloud support. SDL always did support “the cloud” through the proxy of supporting specific operating systems and provided they ran as normal it did not really matter where they ran. This meant that an IaaS based deployment of Tridion was always possible.

What SDL now means to say is that SDL now “supports specific features of some cloud providers”. Those are only AWS and Azure and nothing is mentioned about Google or Oracle as a platform. SDL Web 8 adds support for Azure SQL and Amazon RDS. The documentation states “Azure and Amazon RDS” but this is an oversight as it means “Azure SQL” as Azure is the Microsoft cloud platform rather than a specific piece of technology.

All this means is that you now take advantage of the database-as-a-service offerings from these two providers providing you are not using the SDL Web legacy pack (e.g. for VBScript templates), transactional core service code (you can write this out) or implementations with certain extensions. This is because Tridion traditionally made use of distributed transactions and these are not supported on AWS or Azure and legacy style code still needs MSDTC.

In all cases, you can only use the SQL Server engines which has a cost impact over and above the MySQL engine options on AWS RDS but is cheaper than the Oracle engines.

If you use a version of SDL Web prior to Web 8, you should note that you can use Azure SQL or AWS RDS for the Content Delivery database but it is simply not supported by SDL.

Topology Management

Topology Management is new product feature that replaces the existing (now deprecated) Publishing management (e.g. Publish Targets) with a more advanced approach which clearly de-couples the configuration of publishing from the management of content and makes the configuration of delivery environment something tied to the environment (e.g. production) rather than the content management database. Managed through Powershell, the Topology Manager manages the relationships between publications and delivery environments. There is a .NET API which means automation options from other applications that are not PowerShell compliant is possible and an example of using that API can be found here.

Some key terminology to grasp with topology management itself;

  • Content Delivery Environment: in essence just the same as before and is communicated with through a Discovery Endpoint
  • Topology Type: defines the purposes like “Staging” and “Live” and can define a series of purposes to help support a publishing workflow (e.g. Staging Editors -> Staging Executive Approval -> Live)
  • Topologies: combines one or more content delivery environments which have a particular Topology Type (including Purposes).

And on the Content Management side:

  • Target Type are the same as before in that it is what the user selects when publishing to undertake the publishing and has “a” Purpose e.g. “Live”
  • Business Process Type defines how content flows through the organization (published or not) and in this context what topology type and target types, defines the Minimal Approval Status of a target type and the priority which both used to be in the publication target. The Business Process Type is in a publication and can be inherited through the child publications.

The features increase the complexity of publishing management and it is a little frustrating there is no user interface as this was one of the nice features of the current publishing approach. Whilst I support the move, it has yet to be seen how much this would be an advantage in an automation / NoOps approach over what you could already do through existing APIs.

For now, there is no need to change to the new approach, so the advice to customers would be to sufficiently test with the new approach before rolling into a production situation.

More Graceful Publishing Management

SDL has improved how you can manage publishing services. Prior to Web 8, when a publishing service was stopped, it simply forgot everything it was doing (much like a “kill -9”). With the advent of technologies like auto-scaling, this makes simply stopping a service a royal pain because a service may be busy with something that you simply just do not want to forget about. These new features are only available in the new publishing approach described above:

  • Pausing the Publisher service: Pausing means that the Publisher does not pick up any new transactions, but does keep processing deployment feedback on items already send for deployment. Assuming you can test if it has completed all feedback items it had open (?) then a graceful destroy of a server could take place.
  • Graceful shutdown of Publisher service: Shutting down the Publisher service will allow the following to take place before shut down is completed; all transactions that have not yet been transported back in the publish queue (set to Waiting For Publish) and all transactions that have the transaction state “Scheduled for Deployment” have sent their commit packages to transport.

With the approach of starting and stopping delivery environments a little more dynamically then delivery environments have some additional options to help management them:

  • Graceful deactivation and reactivation of a Content Delivery environment: halting a Content Delivery environment for maintenance is now possible from the Content Manager server. The documentation is unclear with what happens to publishing transactions being pushed to other sites as well as what happens to records (e.g. audience manager) that are written to databases belonging to redundant databases in other deployment stacks.
  • Decommissioning of a Content Delivery environment: You can decommission an entire Content Delivery environment without having to unpublish content first.

Content Delivery as a Service (CDaaS)

The major change from architecture side for delivery is the introduction of Content Delivery as a Service or CDaaS for short. This new feature means that web applications can feed content from a SDL Web using a microservice approach. This approach allows non-Tridion (Web) skilled teams to talk to Web and minimizes any impact the libraries for Web would have on other applications.

Development and maintenance of the CDaaS and connected web applications can all happen separately on their own development tracks and upgrades to CDaaS will not affect the applications using the content (assuming the interfaces are reverse compatible). You can scale the CDaaS microservice separately to your other application services (a concept drawn from microservices architectural approach) which means that applications that are not content rich need not have large content delivery farms.

Discovery Service

The Discovery Service is now the know it all of the delivery farms, with the centralized webservice being the go to point to understand what content delivery endpoints there are deployed. The topology manager (see above) needs to only talk to the Discovery Service to get everything he needs to know.

[ Update 9th Feb 2016 – Thanks to Nuno Linhares for some corrections on the version numbers and the information regarding the .NET client for the Topology Manager]

Continuous Delivery vs Content Management

Recently I had a discussion where the initial question somewhat baffled me. Having thought about it more, I want to write something about it to see if I can come to a nice conclusion. The question was; Is Continuous Delivery a threat to Content Management? The form of the question predicates that the asker thinks that Continuous Delivery is actually a threat to Content Management, but why?

As someone who tries to take the independent stance but heavily leaning on Content Management for the staple of work, my initial reaction is that no, Content Management is no threat to Continuous Delivery, but nor is Continuous Delivery a threat to Content Management. Both have a place in any internet delivery environment and such a question is a little like comparing apples and pears. But for kicks, let’s look at it in a little more detail.

What is Content Management (CMS)?
Specifically, we are talking about Web Content Management (rather than the general definition). Wikipedia describes this as:

A web content management system is a software system that provides website authoring, collaboration, and administration tools designed to allow users with little knowledge of web programming languages or markup languages to create and manage website content with relative ease. A robust Web Content Management System provides the foundation for collaboration, offering users the ability to manage documents and output for multiple author editing and participation. (source: https://en.wikipedia.org/wiki/Web_content_management_system)

Systems like SDL Tridion Web make good on the following: allowing non-technical users to edit site content (and even manipulate layout), collaborate on content, version and reuse content across multiple channels and sites. Some systems allow for additional integrations to support content create such as translation systems, DAM etc. and changes can be made to a production website in a matter of minutes. Not all CMS platforms support direct updates but rather they rely on periodic refreshes of the content.

What is Continuous Delivery (CD)?
Continuous Delivery differs in what it, as an approach is trying to resolve. Wikipedia describes it as:

Continuous Delivery is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery. (source: https://en.wikipedia.org/wiki/Continuous_delivery)

The focus here is on agility of changes in a development lifecycle with a heavy focus on automation of repetitive tasks to lead to productivity and quality improvements. These automated stages are things like build, test and deployment. They feature integrated products covering things like collaboration, unit tests, versioning and source control and typically this is focused on product (code which could be a website) development which can and often does include editing of assets such as labels, (website) content and binary objects.

Comparing the two
Both have overlap in two areas; versioning control and pipeline management. Both paradigms focus on rapid delivery of assets and both are only comparable if we are talking about the delivery of a website. A CMS is no good for supporting delivery of a desktop application. Whilst many CMSs support the delivery of code and have a web application, SDL Web does not mandate such a thing and you can develop any application you would like with varying degrees of code in the CMS itself. Currently, the recommended practice of SDL is not to include code in CMS, but to develop a separate application and have SDL Web deliver content which it can do in any form you need (e.g. JSON or XHTML). Continuous delivery specializes in the delivery of code and assets.

In Continuous Delivery, you can enter content assets into a versioning system (e.g. Git) and include that in your build which is eventually deployed. Content can be edited with a suitable IDE in a semi- non-technical form. I do not want to say completely non-technical because an IDE is typically still a technical tool. CMS systems tend to focus on empowerment of non-technical users and organizations that use SDL Web have non-technical marketing users editing content either via forms or using tools like Experience Manager. Content that is entered into the versioning system can then be pushed through the delivery pipeline into the deployment together with all the application code. This has an advantage in agility of deployment because the content will always be delivered by the deployment and the content is as available as the application. Where SDL Web sometimes has challenges is that you need to have a single, scaled and redundant source of content for the webapp. This means that always needs to be there to make the web application works. However, separating the two pipelines of code and content using CD and WCM means that you can make minute by minute changes to the website and not require the application to be redeployed. If you want to separate your web application from your CMS, then content can be delivered through content-as-a-service.

Conclusion
Every web application needs content so if you do not have a CMS then you will need to deliver your content through CD. CD will provide enough features to edit and manage content providing you have the right people and you allow the right speed of updates in the form of multiple deployments per day. What you lose by not having a CMS is the features that the CMS would bring such as content inheritance, translation, inline editing, per minute updates of content. For a simple site (i.e. a micro-site), having a full enterprise CMS is perhaps overkill especially if you do not already have a CMS. If you do, reusing content and content editing processes from the existing CMS is a considerable plus.

If your website is larger in content terms than a simple site and is really multiple sites in multiple languages with a high amount of content reuse, then using CMS and CD together, seems to be the ideal solution. You can manage all your content for all your channels (including campaigning) though one tool and develop awesome apps in record time with CD. One is not a threat to the other.

Going forward I would make a recommendation that your deployments are done in a microservice architecture and in that, your CMS content should be delivered as a service (along with all the other things like targeting). This means all deployed sites take advantage of content that is centrally managed, application deployments are not weighed down by large volumes of content assets and CMS features like content targeting are uniformly deployed on all channels.

Photo credit: Ian Brown (Flickr)

SDL Tridion in the Cloud – Tridion Developer Summit 2014

Earlier this year I presented as lightning presentation at the Tridion Developer Summit in Amsterdam. The even was awesome and really well attended. Here are the slides that I used:

SDL CXC and Tridion

Today I posted some slides to slideshare on SDL CXC and Tridion. Just a simple overview of what we have done for Tridion on SDL’s CXC platform.

The SDL Tridion Reference Implementation

htmlRecently, SDL released the Tridion Reference Implementation, or TRI, to the community. The first edition of the TRI is based on .NET and aims to provide a reference for customers and partners on a preferred approach to an implementation.

Traditionally, Tridion has had an open architecture where a delivery implementation (e.g. an MVC framework) was not supplied with the product. This allowed customers to choose the delivery architecture which suited their needs. As a result we see variations from a simple ASP.NET/ JSP page based site to a fully dynamic MVC based implementation. With the release of the TRI, nothing changes in that regard but should you wish, there is an implementation that you can start from.

The TRI is an MVC based application that uses common elements and approaches with the community MVC application, DD4T. This means that customers using DD4T are compatible with the TRI from a Content Management point of view and so long as the TRI is getting content from something in the right format it can be independent of the content provider though support for semantic web (but by default, Tridion is the content provider). The templates are managed in the application and not in content management and the supplied templates follow a RESS approach and are re-brandable using bootstrap / LESS. The approach means that you can rapidly rebrand the application to another design and this can support a wide variety of devices using one site rather than separate websites for different devices.

The current release, version 1, will be replaced with the upcoming version 2 which will add new features – implementing more SDL product features – will have a java version and will become part of the SDL product stack and available with the installation of Tridion. Right now, you can contribute to the release by going ahead and using it.

You can download it from SDL Tridion World and look at the sources on github.

Five years of MVP events

Via Chris Summers (@UrbanCherry)

The 2012 MVP event (Via Chris Summers @UrbanCherry))

Since the SDL Tridion MVP program started five years ago, there are five people who have managed to be an MVP each year. I count myself in the lucky few who have managed, sometimes narrowly, to still be privileged to be able to attend the events. Each of the five events have been held in and around Lisbon, Portugal. Over time the group has grown from 10 to around 25 and the balance of members has steadily grown in favor of the external (to SDL) community members.

Each year, we descend around this time, on Lisbon and embark on a long weekend of work. From Thursday to Saturday the team works on various community related activities, both in terms of open source projects but also in terms of thought leadership.

This year the team is working heavily on the Tridion Reference Implementation which is SDL’s newly release delivery framework. Currently in a community edition and based on .NET, SDL plans to move this to being fully supported and delivered out of the box with the product. This move comes when there is an updated version which will come sometime in the not too distant future.

This year, the city of Evora in Portugal is our home; a tourist destination somewhere between Lisbon and Madrid. Its old, built by the Romans and probably not really ready for the MVPs. I hope they have a strong constitution…

Provisioning Tridion in the cloud

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.

Updated awards

Finally got around to updating the awards on the site.

SDL Tridion Translation Manager

The last video of 2013 and I am now starting to really enjoy making them. If only I had more time. So, this one is about Tridion Translation Manager (TTM) the plugin that enables sending content to and from translation with SDL TMS or World Server.

© 2016 Julian Wraith. All rights reserved.

Theme by Anders Norén.