Episerver DXC - How To Architect Your Episerver website in the new world
I've talked previously in Episerver DXC – What Is It? about the new hosting and service offering from Episerver. If you decide to work with DXC, or indeed the cloud, then some of the old patterns and technologies that you've become used to will need to change. One of the main issues you'll encounter is not having physical access to the server, so you'll need to re-think how you'll work with your log files, how you manage your releases. The aim of this post will help point you in the right direction.
CachingWhen you start to think about cloud hosting, caching and how you architecture your project, they become even more important considerations in your project. When you host your website in the cloud, the monthly hosting cost will be based on usage. Page views, bandwidth and number of items in your Find index will affect how much your monthly bill will come to, which means that the more efficiently you write your code, the cheaper your hosting costs will be. In the new cloud computing world, good developers who understand performance will literally be able to save a company more money compared to less experienced developers With a performance-based pricing model, implementing the correct caching is vital. If you write code that doesn't fully optimize caching your monthly bill might end up costing you a lot more than it should. On most new projects I undertake, the process is usually figure out what parts of the page don't change and which parts do. The bits that don't change will be rendered as HTML and cache in the user's browser. The bits that do change are prize contenders to be rendered with AJAX. This means with output cache enabled and the HTTP expire headers set correctly, your servers will do the minimum amount of work.
Log FilesIn a traditional server set-up, Episerver would log issues with Log4Net to disk somewhere in the server and you would remote desktop in to view them when you needed to. In an Azure environment, you can't access the server directly, so for some clients, you will need to rethink how you write your log files. Standard Azure provides the Azure Activity Log and Diagnostic Logs viewers for viewing your IIS logs and your Episerver logs. DXC provides the same solution. In azure, you can write out your statements like this, which would be logged in the Activity log.
System.Diagnostics.Trace.TraceError("Log me In Acitivy Log");DXC also comes with New Relic included, so you could just use the error management instead of relying on logging as much within the application. One potential solution is to let your code fail fast without logging anything and use New Relic reports to notify you of anything. 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 a day to fix it. However, if you need back copies of your logs for say compliance reasons, you may need to think of alternatives. Log4Net is very customizable, so writing your error logs to a database is very easy. Obviously, writing your logs to a database has consequences, it adds to your network traffic load so you need to be careful what you log. If you use Redis or some form of NoSQL database in your solution, then you could consider logging your errors there, however, 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 SQL to do my custom application logging and then aimed at keeping the amount of logging down to a minimum. I tend to rely on New Relic errors for everything else.