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.
Page 2 of 12
Recently, 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.
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…
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.
When we provision environments at SDL we undertake the following steps;
- Provisioning of the infrastructure, security groups, DNS, tagging and storage
- Installation of the Tridion application, required modules, hotfixes and pre-requisites
- Configuration of the installed software
- Deployment of the customer’s implementation
- 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.
Finally got around to updating the awards on the site.
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.
In this edition, I look at the basic architecture of Experience Manager and how it interacts with Content Manager.
I *think* I have recovered, although I am really not sure.
So what happened? Well, I would say a lot of fun and games at the latest edition of the MVP meet up. It started late for me after I arrived late on Thursday, driven up to the castle at night was awesome but the final walk was a killer (and also twice the distance it should have been). After an evening of fun, Friday was a day of work and catch up for me. The project I fitted into was the Tridion Context Engine Wrapper (a punchy title, right?). The Wrapper – lets leave it at that, shall we – wraps the new 2013 SP1 context engine with a set of libraries in .NET (following with Java and TCDL) that can be implemented with SDL Tridion 2013 SP1 and the SDL Tridion Content Engine on a delivery website.
Oh so what does that mean?
Well you can do things like this:
<context:Family Names=”smartphone,tablet” runat=”server”> <div>this content will only display on smartphone or tablets</div> </context>
Which is really good because you conditionally act server side for different types of devices; definitions which you create. Awesome huh?
After Friday building documentation we venture out on Saturday to do lots and lots and lots of things. Way too much to really describe but in short it was: Sour Cherry Schnaps tasting, off roading, visiting a lagoon, a guided tour of the city where we stayed (Obidos) and did I forget anything? Not sure… it was just awesome.
Last time I covered SDL Tridion Server Types and this time I have linked them together to make one Content Management and Content Delivery chain. I will expand on this further in the next video where I’ll look at the publishing chain in more detail.