In this tutorial, I will introduce some of the considerations that you will need to think about when building a site using Episerver DXC/DXP. If you are new to Episerver DXP, you can learn a little more about it in Episerver DXC – What Is It?. DXP is a new cloud web-hosting service offered by Episerver. DXP hosting is based within Azure. When you host an Episerver website in Azure, some of the old patterns and technologies that you've become used to while building websites hosted on-prem will no longer work.  One of the main issues around DXP hosting is not having physical access to the server, so you'll need to re-think how you'll work with your log files, your Ci/Cd pipeline as well as how you manage your releases.  The aim of this post will help point you in the right direction.

Caching

DXP comes with a few things. It uses Azure to host your web file and Cloudflare as the CDN. When hosting a site using DXP, you will not get access to your infrastructure directly. You will not get access to Azure or the Cloudflare portal. This means that things like caching will need extra considerations in your project. If you can not access the file system easily, or flush your cache in Cloudflare, what happens if you need to purge something from a page quickly?

Your page performance can also affect your hosting costs. When you host your website in DXP, the hosting cost will be based on usage. Pageviews, bandwidth and the number of items in your Find index will affect your monthly hosting bill. This means that the more efficiently you write your code and manage the cache, the cheaper your hosting costs will be. In the new cloud computing world, good developers who understand performance will be able to save a company a significant amount of money compared to less experienced developers.

With a performance-based pricing model, getting the caching strategy correct is vital. If you write code that doesn't fully optimize caching, your monthly charges may end up costing you more than it should. In terms of good cache management, I recommend doing a page audit. For each page, figure out what parts of the page don't change and which parts do. The bits that don't change can be rendered as HTML and cached in the user's browser for long periods. The bits that do change are prize contenders to be rendered with AJAX. This means with output cache enabled and the HTTP expiry headers set correctly, your servers will do the minimum amount of work, saving you the maximum amount of cash money 💸 💸 💸 .

Log Files

In a traditional server setup, Episerver would write the log files using Log4Net to disk somewhere on the server that runs the website. To view the logs, you would remote desktop onto the server in order to view them. In an Azure environment, you can't access the server directly, so for some clients, you will need to rethink how you read and write your log files. Standard Azure provides the application insights, Azure activity log and daiagnostic logs for viewing your IIS logs and your Episerver logs. DXC provides the same solution. In code, you can use the code below to write data into in the Activity log:

DXC also comes with New Relic. An alternative option is to use New Relics error management instead of relying on logging stuff to disk within the application. One potential solution is to let your code fail fast when an exception is thrown and then use New Relic reports to notify you of anything. Just like the Netflix chaos demon, this approach can only be used when you are committed to fixing everything. The consideration with this approach, though, is that in the DXC service, releases are managed and scheduled by Episerver, so if your pages do fail quickly it might take you anywhere from a few hours to apply a fix to the production website 😞 .

Another consideration is log file backups. If you need backup copies of your logs for compliance reasons, you may implement an alternative logging approach. Log4Net is very customizable, so writing your error logs to a database instead of on disk is very easy. Writing your logs to a database has consequences as it adds bandwidth to your network traffic. If you log into a database, be lean in what you log. If you use Redis or some form of NoSQL database in your solution, you could consider logging your errors there. This is not ideal though, Redis wasn't designed to be queried like SQL so it's probably not a good choice. As of writing, I've always tended to stick with creating a custom Log4Net appender to write the logs into SQL with a commitment to keep the logging to a minimum. I tend to rely on New Relic errors for everything else.

Configuration

Traditionally, I think most developers have used settings located within the AppSettings section in web.config to store a website's configurable features. As DXC is a managed service, if you need to quickly update an AppSetting, you'll need to deploy your site. An end-to-end integration to pre-production release can take over an hour. Be aware you might need to wait an hour to enabled/disable a feature flag. In a managed service like DXC, I avoid using AppSettings as much as possible. Instead, I store everything that I'm physically able to as global data within setting pages within the Episerver CMS. More info about the approach is discussed here.

Transforms and Releases

In a normal project transforms are always fun. Normally, you have a web.release.config to do the life transforms. In the DXP world, we have three environments integration, pre-prod and production. To apply to transform DXP you need to create three transform files. These needs to be named web.integration.config, web.preproduction.config, and web.production.config. This site is hopefully easy to implement, but easy to forget 🤪!

Lastly, is release management. As mentioned a release into production can take over an hour and you may need Episerver supports help to make it live. Add this time into any deployment plans and run-books to make sure it gets done in time !!!!

That concludes the main points you need to consider when deploying using DXP. Happy Coding 🤘