Welcome back, Tridion!

As most of you probably know, SDL has postponed the release date of their CMS, which by the way goes back to the roots as far as naming goes. The new version will (again) be called SDL Tridion Sites 9 instead of SDL Web 8 / 8.5, and for me personally, this is great news. When I started working with SDL’s software some five years ago, their CMS was called Tridion, so that name will always have a special place in my heart. Oh, and by the way, people kept calling SDL Web 8 / 8.5 Tridion anyway :).

What’s new in Sites 9

In the middle of July, EXLRT (2 of my colleagues and me) visited an SDL organized technical bootcamp in their Amsterdam office to get first hand information about the new features, improvements and plans. It was a very positive experience and the presented material seemed very promising; it was more than enough to get the creative juices flowing and to make us anticipate the new version even more. If you weren’t present at the boot camp, don’t despair as SDL will hold a series of 5 webinars, each of them covering a topic which was presented at the event. I plan on writing a blog post about all of them so even if you miss any of the webinars, you can still inform yourself, and since the first webinar was already broadcasted, please feel free to scroll down a bit to see what it was about.

SDL Tridion Sites 9 – Technical readiness

The following topics were covered in this presentation:

Platform support

The first part of the presentation was concerning the versions of operating systems, database servers, and other software which are supported for both the CM environment and CD environment, or rather the UDP as it’s now called. UDP stands for Unified Delivery Platform and is key in SDL’s plans to integrate the delivery systems of Tridion Sites and Tridion Docs into one. UDP also plays a key role in Content Mashups, a topic which will be covered in one of the upcoming webinars/blog posts, so stay tuned :).

The list below shows the recommended versions:

Content Manager:

• OS
  • Windows 8.1, 10, 2012 R2 and 2016
• .NET Framework 4.7.2
• Java 8
• Database
  • SQL Server Azure, RDS, 2016 SP1 and 2017
  • Oracle 11.2.0.4 and 12.2.0.1

UDP:

• OS:
  • Windows 8.1, 10, 2012 R2 and 2016
  • Linux RHEL 6.9 and 7.4
• .NET Framework 4.7.2
• Java 8
• Database
  • SQL Server Azure, RDS, 2016 SP1 and 2017
  • Oracle 11.2.0.4 and 12.2.0.1
• XO*
  • ElasticSearch 5.5 and 5.6

XO* - stands for Experience Optimization and starting with Sites 9 there are some major changes in this area as well. As you can see it now requires ElasticSearch, and the same as with the Content Mashups, this will be presented in more detail in one of the upcoming webinars/blog posts, so again stay tuned :).

Upgrade Paths and Strategies

The supported upgrade paths for upgrading to Tridion Sites 9 are:

• Tridion 2013SP1 HR2
• ​SDL Web 8 CU1
• SDL Web 8.5

Since an upgrade usually involves a significant cost (both timewise and financial-wise) and is a complex process, SDL has come up with 2 upgrade strategies which aim at reducing the cost, making the upgrade process easier, and maybe most importantly, reducing the risk and giving the ability to do the upgrade with (near) zero downtime. The first one is the Staged Upgrade, and in this version of Tridion, the CM side is upgraded first. Earlier it was the other way around, first CD then CM. The reason why it is switched is because in most real-life systems there are a lot more of CD systems than the limited number of CM servers. Upgrading the CD systems first would mean that we try to address the most complex and riskiest environments first. Additionally, new functionality is most of the time introduced on the CM side, so upgrading the CM first ensures us that we have the prerequisite for said functionality. If the CM is upgraded we can even deploy an isolated (new version of the) CD to play around and test the functionality, using the actual content, before upgrading the rest of the CDs.

The second strategy is called Rolling Upgrades which lets us do upgrades the following way:

1. Upgrade the CM database on the live system, even though the DB is upgraded, the old versions of the CMs will still work
2. Upgrade one of the CM servers (in a clustered CM environment), or provision a new server, and test all the extensions. If all is OK, upgrade all the CMs
3. Upgrade the CD database on the live system, at this point the microservices are running on the old version
4. Slowly replace the microservices with their new versions. This is also possible for the microservices individually; it’s not needed to upgrade all of them in a package. So, for example a new version of the Discovery Service in combination with the old version of the Content Service
5. Finish upgrading all CD environments to the new version

An important note is that Rolling Upgrades are possible starting Web 8.5 and are applicable in upgrades to only the subsequent versions.

High Availability of CM

Changes have been made on the CM side to remove dependencies on the file system, thus enabling us to easily (re)deploy (new) CM servers into the cluster without the need to configure them individually or worry about breaking something. This is accomplished by the fact that the following is no longer kept on the filesystem:

• Local file based storage for CME and XPM, for example Custom Pages configuration on the CM
• ​Audience Manager local temporary storage for Sync

SAML 2.0 Support

And finally, support for SAML 2.0 was added and now it can be leveraged to do SSO for CME and XPM. Both ID Provider and Service Provider scenarios are supported. 

This would be all for the first topic, don’t forget to check out the rest of them. Personally, I think that all of these improvements will come in quite handy, especially the upgrade plan. What are your thoughts?