Having missed last year’s SUGCON in Berlin due to family commitments I had no excuse to visit the conference in London this year. Well, apart from a small family commitment in the form of my son due to arrive in a week! Still its only a 4 hour trip home should he decide to arrive early ?
I took the opportunity to go in early on the morning of Day 1 and update my Sitecore certification to version 9.1 kindly stewarded by Tamas and the team. Once that was done it was time to grab some food and meet up with friends, old and new, and catch up with whats going on in the world of Sitecore.
Azure Devops – Donovan Brown
The first talk of the day was from Donovan Brown on Azure DevOps. This was an enlightening talk further strengthening the case for Azure DevOps in the coming months and years when it comes to dev/test workflow. I think it will only be a matter of time before even the most ardent of detractors will see the benefits Cloud technology can bring to repeat-ability, reliability and cost savings. That is, perhaps, until that fateful day when the providers decide to hit their captive audience with price rises 😛
I attended many other talks of high quality, but the stand out ones for me were:
Sitecore Host – Architecture and plugin – Kieran Marron and Stephen Pope
Sitecore Host runs on .NET Core and acts as a base framework for other services e.g. Identity Server and Universal Tracker with the Publishing Service soon to be migrated too. Host takes care of many common concerns such as Dependency Injection, Configuration management, Route registration and more. The idea behind it is to provide a consistent experience for any application on the Host from installation to configuration even allowing command line configuration without the need for a User Interface. This is what we’ve been looking for a long time and I find it reassuring and exciting to some extent that Sitecore has embraced splitting out the monolith into its constituent parts. For years It felt like Sitecore was gradually falling behind as it remained so tightly coupled to the .NET Framework and had a huge deployment real estate. But over the past couple of years the the move to split out parts of the beast is rapidly gaining pace and I applaud this move. I will be interested to see what happens in the next few years and what candidates are picked to receive the Sitecore Host treatment. My only concern will be the whether the DevOps guys are sucking through gritted teeth at what will soon be landing on their plate. Perhaps with the adoption of Docker, this side of things might improve but lets wait and see…
Taming the Marketing Automation Engine – Nick Hills
This was a timely talk for me as I’m currently looking at harnessing the power of Marketing Automation for my current client. Nick really cut to to the heart of the matter and delivered an engaging talk covering pitfalls and common issues.
Even as a Developer with a limited appreciation and grasp for Marketing, I’m always astounded by the potential and power of Marketing automation in Sitecore, so to Marketer’s it must be a dream. Such is the power and ease of use I really do think Sitecore should have a compelling demo video on their homepage; Perhaps a whistlestop tour employing a campaign to engage customers in a plan, upsell, cross-sell, I think it would really captivate Marketers from the off and let the customers roll in!
Nick covered Automation from a Marketer’s perspective and then from a developer’s viewpoint. For me this is the single area of Sitecore besides personalisation that stands out as having the ability to generate a massive difference in potential revenue for customers. One you see it’s ease of use and power, you can imagine the huge possibilities for revenue generation and addition of business value. e.g. The system could:
- Send an email reminder to customers if they abandon a basket, potentially capturing some lost revenue.
- Send post-purchase experience countdowns and attempt cross-sells/ upsells
- Send a “customers also bought” email or employ Machine Learning to suggest items that match the buying habits and likely interests of the user.
- Integrate with a weather API for companies that benefit from particular types of weather. It could be used to suggest bringing an umbrella or suncream or upselling a day trip such as a water park on a nice day or an aquarium on a wet day. A car hire company could use weather data to upsell a 4×4 vehicle for wet or snowy weather
- And so on…
JSS immersion – lessons learned and looking ahead – Anastasiya Flynn
Anastasiya covered many lessons in her talk from scaffolding out components and structuring your project, to debugging techniques. As a complete n00b to JSS, I was hoping to glean hard won tips and tricks in this session that would kick-start my learning. However on reflection I would really have benefited from studying React and playing about with JSS beforehand as many of the concerns here were difficult to fully grasp without a base grounding in the tech.
She explained how the component factory worked (which went over my head having never used React or JSS). I intend to return to her slides when I get time to delve into JSS with either React or VueJS.
Debugging tips were shared in the form of the Chrome debugging tools and useful extensions for React or Vue though I was surprised to see console.log being recommended as a fallback option. I know its has always been a quick and easy way to output given information but it does make me wonder whether the stack is now so complex that we are still waiting for the debugging tools to catch up.
I’m looking forward to tinkering with this in my spare time but the big question still lingering in my mind is, what if you don’t want to go completely greenfield? Many clients don’t have the budget to scrap their site and build from scratch and I’ve not read much in the way of blogs on how to piecemeal migrate to JSS or combine JSS with traditional Sitecore sites. It’s an area I’m very keen to investigate…
PAAS it on – Learnings from a year of Sitecore on Azure Paas – Criss Titschinger
I enjoyed this talk from Chris, what it brought home was how complicated a full Sitecore 9 deployment to the cloud can be versus Sitecore 8 especially in a Blue/Green setup. Criss brought many of his learning experiences to the table. A few highlights for me were:
- Recommending the use of TFS2018/ Azure Dev Ops and Service principles rather than Publish Profiles. In Blue/Green setups it pays to be mindful of the fact that the CD server will be shared between both instances which obviously puts a bigger strain on the resources of that machine.
- Diagnosing issues with a specific instance in a cluster has always been a pain. In the past I’ve used a HTTP Header to identify servers. Criss suggested using the ARRAffinity Cookie together with browser plugins like EditThisCookie to allow you to edit the cookie and load a page on each instance.
- Azure portal gives you Availability and performance stats, CPU, Memory reports. You can even kill the process from here.
- Application Insights is a great tool for searching logs by time, or for a specific exception but pay attention to the amount of data being harvested, especially from test servers as you will be charged for all the data.
- Azure search is very easy to set up but it is limited to 1000 fields per index. This might necessitate excluding unnecessary fields in the ContentSearch configs otherwise building an index can hang. Azure Search can be expensive so it might be an idea to use Solr for local development purposes
- Azure SQL audit / threat detection works very well and detects all failed logins or firewall anomalies.
- Bandwidth can be pricey for bringing content down – think about media and putting it into a CDN to save costs.
- If you cant find what you’re looking for in the Portal try resources.azure.com. The option to use HTTP2 was active in Resources 2 weeks before it was available in Portal.
- Autoscaling sounds great in principle, but it means cold starts. And cold starts mean there is a period of time when your site is unavailable to serve requests, which is less than ideal. It is therefore advisable to reduce startup time as much as possible by streamlining Sitecore e.g. making use of the the Prefetch cache and Precompiling views.
I must admit it was quite worrying to hear Microsoft’s seeming indifference to swapping out the instances making up part of his cluster. With Sitecore’s cold start time, this was enough to cause downtime and I’m very surprised this is still an issue with Azure at this point in time. Issues like this are always a worry for me as it is all well and good recommending the cloud to a client but if they end up experiencing downtime and lost revenue through no fault of your own it looks bad. Stakeholders don’t care about the minutiae of machines or containers spinning up and down they only see lost revenue and bonuses disappearing into thin air and much shouting will occur. One of the audience did suggest some solutions to this after the talk but I don’t feel it should be up to the client to have to monitor services with Application Insights just because Microsoft decide rejig your services on a whim.
Personally before moving to the cloud I wouldn’t feel comfortable without producing a full end to end plan with rollback and fallback options. In my opinion it makes sense to retain your OnPrem setup to allow testing in parallel and it also allows a fallback option should the cloud setup not fully fulfill expectations early on. It takes years to gain a good reputation and minute to lose it.
10x your Sitecore development – Mark Cassidy
It was a pleasure to finally hear one of Mark’s talk in person. A lot of what he described really resonated with me with regards to overengineering Sitecore solutions. Although often we try to produce the most flexible design for a client, beneath all the noise it is often time to market which is their number one priority. Get the product out the door then iterate. I am a big fan of this mentality as opposed to taking much longer to get the “perfect” solution before pushing it out the door. What was the perfect solution at the time often ends up changing and so the time spent up front is often money taken from the budget that would be better spent elsewhere. By trying to take our ego out of the equation as an architect in delivering all singing all dancing solutions we can deliver a product better suited to our clients needs much more rapidly.
Having said all that, although this approach works well for agency clients and small customers, with Enterprise clients and larger Sitecore solutions with a huge real estate, it can pay to slow things down. Often I will be tasked to work on a Sitecore site that has had years of development behind it and although time to market is still important here, other factors such as performance, and reliability under stress come to the fore. Nevertheless I usually like to offer clients a short middle and long term solution to a given problem.
I can appreciate the use of the native Sitecore API as a default approach especially when you have big teams of .NET Developers or even newly certified developers. I have seen people get lost quite easily when an ORM comes into the equation as it is not something they will find in the Sitecore documentation or training. It also hammers the point home of YAGNI (You aren’t going to need it). Do you actually need an ORM to achieve the MVP of the product or can it be shipped without? Personally I feel the advantages of automapping to strongly typed models and decoupling from the Sitecore API beneficial on most occasions but we should still stop and think. Mark put a very valid point across that the Sitecore API is very stable and hasn’t significantly changed in around 10 years. This is a big point for me that many architects seem to ignore. Take Glass for example, its a fantastic product provided free of charge and I use it regularly. However updating to version 5 from 4 does mean there is work to do from a development perspective and hence additional testing too. Can your client absorb the cost of the inevitable refactor? It’s something that we rarely talk about but I feel should be a consideration when choosing an ORM. We should set the expectation that it won’t be maintenance free forever.Â
Using xDB at scale – Mike Edwards
This talk was a refreshing take from Mike on how to apply presentation and profile cards when dealing with a massive amount of content pages (think thousands). Solving this maintenance nightmare involved creating a centralised config item in Sitecore with a rules field. The rules engine is run against this field on every request and if the predicate evaluates to true, the profile card is assigned.Â
Personalising content en masse also presents problems and Mike talked through using a centralised item with personalisation applied which is accessible to the Content Editors. These renderings get injected into the layout XML at run time via the mvc.getxmlbasedlayoutdefinition pipeline and I’ve seen this approach used to good effect by clients before. Although you take the hit on every request with judicious caching, you save the Content Editors weeks of time navigating through dialogs in the Content Editor.
In my experience making Content Editors life easier is often not number one priority when developing solutions. Developers are often far removed and often don’t meet the editors, when they should really should interact closely. Often the closest they get is a ticket in their sprint backlog or kanban board from the Content Editors requesting a feature or some additional functionality. By putting ourselves in the Content Editor’s shoes it can help to deal with their frustrations. I try to remind myself that a CMS is designed to be used by non technical users and I should try and empower people to do their jobs without constant developer support.
Sitecore 9 Architecture 101 Thomas Eldbrom
Thomas started his talk with a cracking trip down memory lane showing how the Sitecore user interface has evolved over the years. I’d love to know more from people more about what it was like working with the early versions – Site Core, and SiteCore.
Thomas showed how the Sitecore real estate has expanded from a single role in version 4 to over 50 roles in 9.1. There are now 18 databases, 12 indexes and over 20 services. The advent of microservices has obviously caused this to balloon in recent years but it’s starting to become a challenge to stay on top of both development and architectural concerns. We can obviously mitigate this by investing in continuous learning and Martina Wehlander has done a staggering amount of work in making massive improvements to the Sitecore documentation over the past few years. It is much easier now to locate official documentation and you can also target the version of Sitecore you are interested easily to get version specific information. The Master Sitecore YouTube channel is also a valuable resource.
The talk progressed through how the 9.1 architecture works at a high level in terms of CM, CD, Authentication, Publishing, Processing and Tracking. Thomas discussed Sitecore Omni released as part of Sitecore 9.1 which is a range of products supporting headless scenarios where you want to decouple the delivery of the content from it’s rendering. This allows Front end developers to build out a site and interface while still be able to harness the power of Sitecore versus the traditional way heavily dependent on .NET Developer resources.
I must say I reflected a lot on this presentation and although the rate of progress is rapid and exciting in the Sitecore space, I can’t help but feel a little sad that the combined Sitecore Solution Architect / Developer role feels like its going to go the way of the dinosaur. There is simply becoming too much to the platform to be an expert in everything. Perhaps over time, it will become necessary to specialise in the same way that a Full Stack Developer can’t reasonably be an expert in the entire full stack nowadays. They can be excellent in some technologies and competent in others, able to quickly adapt, as they should, but the estate is simply too large to have an up to date intricate knowledge of all aspects. On the other hand I do love that there is so much to learn with this platform, it is constantly evolving and definitely not a dull technology stack from that point of view.
I struggled with Sitecore on Docker so you don’t have to – Sean Holmesby
Having recently got into tinkering with Docker and Sitecore I found myself nodding along with Sean’s talk having gone through all the stages he did. I can really see the advantage of using Docker in Sitecore to spin up and down containers and environments quickly. Ideal for demos or sharing between developers, it cuts down on the time spent setting up environments. I can see Docker coming into its own in the near future as more and more Sitecore services are migrated to .NET Core. Linux containers have a small footprint so with .NET Core being cross platform it sounds like the perfect pairing. Many times I have known developers taking a week to set up their local environment (no joke). With Docker in the picture there is no longer any excuse – with a “docker compose up” you’re ready to go
Measure if you want to go faster – Jeremy Davis
I love a good talk on performance and metrics but I realised shortly after Jeremy started his talk I’d already watched the video last year! Doh! It was a nice recap anyway delivered by Jeremy succinctly, and I liked his judicious use of the VS debugging and profiling tools in VS 2017. I wholeheartedly agree with Jeremy when it comes to measuring the impact of our changes. How can you be confident your code performs if you don’t measure it? Historically I’ve tended to use JMeter/Gatling/DotTrace and a scattering of Sitecore tools to identify bottlenecks and the potential impact of code changes. I will be adding the Visual Studio Profiler to that (VS2019 caveat notwithstanding)
Sitecore 9.2 The Hidden Bits – Pieter Brinkman –
Peter rounded off the conference with a brief chat on the upcoming features in 9.2 which will be released this quarter. A few highlights for me were:
- Horizon – the replacement for the editing experience in Sitecore. This will be tweaked based on feedback from MVPs and the community. I’m very much looking forward to seeing this in action.
- Sitecore Host this will be upgraded to the latest version of .NET Core
- JSS SXA and Sitecore Forms integration as mentioned by Adam Weber and Kam Figy in their presentation on JSS.
- Further work on Helix principles with new samples and designs with talk of a simpler structure for projects in Visual Studio.
- Rainbow serialisation – merging changes with the current serialisation format which contains a file length has always been pain as it necessitates the file length to be updated manually post merge.
- Personalisation report – This looks like it will provide an easy way of display details of the personalisation currently in effect. I have a feeling this will not only be useful for Marketers but useful to Developers for making performance optimisations also.
- Sitecore Install Assistance – This is effectively a GUI wrapper for SIF providing easy installations for developers and non technical users and I’m looking forward to trying it out. Of all the things Peter talked about, I have to say I am most looking forward to SIA for reasons I’ve talked about here. SIA will initially be available for XP0 only but I feel that is where it is needed most and I will welcome it with open arms ?
Missed sessions
Unfortunately as many of the sessions ran in parallel I missed out on some interesting talks. However the slides are currently online, hopefully with accompanying videos shortly: https://www.sugcon.eu/video-downloads/
I’m looking forward to watching some of the great talks I missed including:
- Jason Wilkerson – Sitecore Cortex: From Introduction to Extension
- Nick Wesselman – Helix Mutation & Changing Habitat
- Pete Navarra – the Wheels on the Rebus go queue, queue, queue
- Kamruz Jaman – Offline Tracking with the Universal Tracker
- George Chang – How Sitecore Host is your Density
Summing up
Having had time to reflect on the conference, the future of Sitecore looks very bright indeed. The massive strides in architecture and feature set demonstrated at SUGCON shows just how much effort is being put into the platform.
On a personal level I enjoyed visiting the Big Smoke. I am a big fan of architecture so I am always amazed at some of the buildings coming from my small backward town up north.
It was also great to catch up with friends and see what they’ve been up to personally and professionally, as well as meet new ones in a very positive environment. The coffee and food was decent and the sessions ran like clockwork thanks to the efficient team of Volunteers.
Looking forward to next year, wherever that may be!