With the advent of SDL Web 8.5, we’ve seen many nice improvements to the software. We’re able to move items in the blueprint hierarchy, we can now set up a whole content delivery environment with a number of powershell scripts, … but in our most recent upgrade, we’ve found a big problem.
How big can a production CMS server get?
The short answer is as big as your blank check allows.
As you add users, workflow, translation, heavy publishing, and lots of opening/changing components, the CMS server size will inevitably increase.
Often times, multiple CM services are all enabled on one large machine for the enterprise, but the downsides of that are when one problem happens, all aspects of your CMS fail with it. Below I show what an infrastructure looks like that handles very large publishing loads and is scalable to add more load. The CMS also handles workflow services and translation integration with World Server.
Containers are a common approach when designing CMS content models. They allow Authors and Content Editors to organize content hierarchically. While containers allow contributors to group, reorder, and organize content easily, they also add a lot of dependencies to the content across the system.
The release of SDL Web 8 has seen the biggest overhaul of the Content Delivery stack since Tridion 2011 and much of it has been applauded much, as the new Micro Services architecture and with it the ability to scale, deploy and be distributed in general, gives many more architectural options than just having an API in your web application connecting you to a database.
Building this while guaranteeing backward compatibility with the Tridion 2011/2013 CD stack is more than a major task and I for one am happy to see that that feat was pulled off really well. That is, unless you have overridden the default DAOFactory classes in your Deployer Storage Extensions, as is the case with the SI4T Storage Extensions. When testing SI4T with Web 8, it turned out that loading of the SI4T Storage Extension did not work in every scenario. This has to do with the subtler points of Spring Bean Class loading.
Had a couple of DTAP related conversations this week and remembered that I’d once put together some notes about DTAP that I’d emailed to a former colleague. Figured I’d give a bit of a polishing up and share it.
A while back I wrote a post on using Context Variables as a templating cache. When I came across some requirements to cache data between templates on a recent project I revisited this concept, but found some limitations with Context Variables which I had not realized before. As such I ended up implementing a different approach to caching
While designing and building a Fredhopper/SmartTarget enterprise environment recently, a couple of interesting requirements came up. The first requirement, these days quite often asked for when building infrastructures, was that every Fredhopper component needed to be to be automatically deployed, configured and run. The second hard requirement was that in a production environment being under constant high load and being distributed across multiple data centres, the Fredhopper Index servers need to be in sync and highly available in each data centre, while having failover mechanisms causing the least amount of disruption time. After a lot of headache, trialling, erring and creating a mountain of broken Fredhopper instances in the process, we finally managed to meet requirements and this post shows the how of it.
If you have used SmartTarget, you will probably know that the security model for managing promotions is pretty basic – you either have rights to manage promotions or you don’t. On my current implementation we have different business units managing their own SmartTarget promotions for various sites and applications, all within the same CMS, so all able to view, edit (and accidentally break!) each others promotions. This post shows a simple solution we came up with to ensure each user could only manage appropriate promotions.
At the Tridion Developer Summit in September Siawash Shibana and Albert Romkes gave a presentation of a DD4T .NET application running under vNext (The codename for the next .NET framework) on Linux.
Siawash and Albert made the application available publicy and although it currently uses mock SDL Web 8 provider objects plugging this into a real life content delivery service should be really simple when SDL Web 8 is released this month.