-
Episerver Digital Experience Cloud (DXC) is the new cloud hosting offering provided by Episerver. DXC is a managed cloud-based hosting service that Episerver provides for clients. If you choose to use the DXC service, Episerver will in effect take the hassle of hosting away from you and, instead, manage everything for you. I think there is still quite a bit of confusion in the development community about what exactly DXC offers.
DXC isn't a new product that Episerver has created, instead, it's a service they offer that uses industry-standard providers to host your Episerver environment. The benefit of using the DXC service is that your Episerver website will be hosted and configured in a best practice configuration that Episerver has identified. These industry-standard services include:
- Episerver licenses
- Azure: DXC comes with 3 Azure environments, integration, used for your testing, pre-production used to deploy your website and production, the environment that hosts your live website. Episerver only has access to production, managed services copy the code from integration.
- Cloudflare: This adds your WAF protection and CDN support. Even though Episerver uses CloudFlare, as part of the deal you will not have access directly to edit it.
- EpiFind for search.
- New Relic for website monitoring and stats
- 24/7 Episerver Support
- SSL Included
- VPN
- From my understanding, a Redis server will also be included in the future (June 2017)
DXC obviously won't be for everyone but for certain clients, it provides a better option than doing everything in-house. Obviously, as it is a managed service, the costs are also slightly higher than doing it all yourself. The idea behind DXC is that it’s a service that has everything a company needs to host an enterprise level Episerver website, set-up and configured in the most optimum way to run Episerver. DXC pricing is based on performance, your website's average traffic and page views.
The best advice is to set a low usage quote and then pay for the extra resources, as and when you need them. If you have a summer sale, for example, once a year where your websites traffic doubles for a brief period, then it's more cost efficient to pay for a low tier option and pay the extra only for peak times. In terms of environments, Integration is your playpen.
You can think of integration as a single server, it won't scale. You wouldn't do your load testing here. Pre-production is the environment you put your production code. This is the area that you will need to work with Episerver to get to an area where they will be happy to deploy your code into production. This process might seem a bit odd at first, but with DXC you get a 99% uptime SLA which includes your own custom code, so before they can release anything they have to inspect your changes.
Some of DXC Pro's
Episerver Support
If you have limited in-house Episerver or IT infrastructure skills, DXC is a good option as you get a lot of hand-holding included in the support options that many companies traditionally have had to deal with themselves. It's like using Everweb.. but on steroids!
Compliance
As you won't have direct access to production, you have a very well documented email trail of what code gets deployed and who has access to your sensitive data.
Find Included
Epifind comes with DXC so if you use Find you get an improved deal as it's bundled in. Find is a great option if you need advanced search requirements on your website, like in an e-commerce website product search.
Azure Windows
One benefit of using Azure is that it uses a scaled-down version of Windows. This obviously means that an azure website is a lot more secure, as there are fewer points in your system that can be compromised.
Some of DXC Con's
No Direct Access To Production
On the flip-side of the coin, for some companies not having access to the server itself may cause issues. If you run a website that needs to do code deployments frequently every day, then this might be a show stopper. As mentioned above, the DXC SLA also covers your custom code. This means that when you deploy to pre-production you will need to work with Episerver managed services and agree when a release meets their standards.
If you need to release frequently then you will need to consider this. Personally, I would argue why you would need to do this. Using DXC definitely means you need to architect your solution differently. For example, in a normal project, you may keep a number of site settings in your app settings, in the web.config. If you need to change these settings frequently, instead of having to wait on Episerver, you would be better off making these values configurable within Episerver, removing the need to do a new release to production.
EpiFind
If you don't need to use EPifind and your website only provides a basic search you will end up paying for a service you won't use. In this instance, something like Google Site Search can be used instead for a fraction of the price. If you are not planning on using Epi-Find then you’re paying for a service you are not using.
No Access To Your WAF
Does your site have any subsites/white label sites/services? If you need to add in WAF rules, although technically possible, the DXC service doesn't allow you access to configure it yourself.
Price
More expensive than hosting it yourself. This pricing may put some people off. DXC offers an all or nothing approach. With DXC you have to pay for everything, even if you don't need it all. It would be good if a client could pick and choose what they wanted to help them get cheaper deals.
Conclusion
As I'm hoping you can start to appreciate, DXC provides quite a lot. For certain companies, the DXC offering provides a lot of good benefits. From my personal experience and some conversations I've had with other Episerver partners, some of the sticking points around DXC include, do you want to host a website in the cloud? Do you need to access to the live server?
Do you have the skills in-house to manage everything yourself? Do you want to use Find? Do you already pay for DDOS protection? Personally, I like the idea of DXC, having a managed service via Episerver as it takes a lot of the hassle of hosting and deployment out. Obviously, I never have to pay the bill myself but it means I can concentrate on the things that will help a company to improve its sales funnels and conversions.
If you already have a WAF and DDOS protection, or you need access to the WAF firewall rules then things become a little less straight cut. At this point, you will need to crunch the numbers and figure out what works best for you. If you can answer all these and DXC is still a viable option, I'd recommend getting in contact with Episerver to get a quote. When I've recommended DXC it's been for clients with little Episerver knowledge in-house who would fully maximize all the services included in DXC.
-
Nowadays, when hosting is predominantly moving towards the cloud. EpiServer, as a company, is usually on the ball when it comes to new tech trends and cloud computing is no different. In terms of hosting your EpiServer project, you have three main options; traditional self-hosting, cloud hosting, or, Episerver's own offering, the Episerver digital experience (DXC).
A lot of companies I've spoken with are struggling to decide how to host their EpiServer project. Traditionally, a website was hosted on a dedicated server either internally or through a third-party provider like RackSpace, but with Azure and DXC the game has changed and maybe the traditional approach isn't right for you anymore. If you find yourself in this situation, then the aim of today's post is to cover some of the pro's and con's of each solution so you can make an informative decision about what is right for you.
Traditional Hosting
In a traditional hosting environment, a company pays for a server that they effectively own. The company's website files and/or database live on the server and people within the organisation (devs/IT) have access to the box, whatever software required can be installed, log files can be viewed and in essence, people can do whatever they want. This flexibility comes at a cost, these costs include:
- Don't scale, if you have a sudden surge in traffic it may take hours/days/weeks for you to get a new server up and running
- It can be more expensive, a PC is capable of doing a lot of processing at the same time. If you run a single website instance on a server, most of the time it will be sat there waiting for things to do. Regardless of how busy your website is, your monthly maintenance costs will be the same. If you have a very low volume of traffic then you'll be burning money on processing power that you may never need.
- Your company needs IT skills to maintain/back-up and manage the servers
A traditional hosting model isn't all bad... the benefit of using Episerver with traditional hosting include:
- You have complete control over the server. With a cloud environment, you are limited/restricted in the things you can do
- You can install whatever reporting, debugging and sale software you require on the server
Cloud Hosting
In recent years, a lot of companies have heavily invested in cloud architecture and dev-ops jobs are becoming more in demand. In a cloud architecture, your website is hosted in a data centre, hosted and managed by someone else (Amazon, Google, Microsoft, and Rackspace). Instead of having a dedicated box that your company purchases and manages, your website lives on a virtual server that you rent out on a per-needed basis.
- Managed Hosting: When you host your website in the cloud, your website will live on a virtual server. Virtual servers give lots of benefits to companies. First, as the server is virtual you can ramp up or down the amount of processing power available. This pay as you use model gives huge cost savings. Paying for exactly what you use and not for an unused server, storage and processing time saves money.
- Virtual Servers: As the servers are virtual and you can't install software on your server, your dev team is forced to design a scalable architecture and code base. This architecture can help you develop more robust, flexible and less coupled code.
- Scalability. Servers scale up and down automatically depending on the applications needs, unlike traditional hosting where you have to manually add or remove servers as the traffic to your website changes.
- Automatic: The server are managed for you, so anything like Windows updates, anti-virus, firewall upgrades are done without you needing to worry about it
Episerver Digital Experience Cloud Service (DXC)
As DXC is still quite a new offering, I think there is still quite a lot of confusion in the EpiServer community about what exactly DXC has to offer. I started off thinking it was Azure with some managed support, but after talking with David Knipe from EpiSEerver, I've learnt more about the service).
The idea behind DXC is that it's an Episerver hosting solution that has everything a company needs to host an enterprise level website included. You get a license to use EpiFind, Cloud Flare CDN support, Firewall, Azure hosting, New Relic support, SSL certificates and upcoming products like the new A/B features, EpiServer Insights and personalisation will be bundled in automatically without you having to worry.
DXC pricing is based on traffic, page hits and performance and as Episerver is handling more of your IT load, the costs are higher than hosting a solution in Azure and managing everything else in-house. Like Epi-Find the number of content items you have, the number of page views will all determine how much your monthly cost is. If you have limited in-house Episerver and IT infrastructure skills, DXC is a good option as you get a lot of hand-holding that many companies traditionally haven't wanted to deal with.
The benefit of Using EpiServer With DXC
- Compliance Benefits, as the client (or dev team), has no direct access to live) also tends to ring nicely in the ears of organisations under compliance checks. Add auto-scaling in and it plays nicely with anyone who ever runs a campaign too
- Like using Everweb.. but on steroids
- Solution built for scaling, useful if you have sudden spikes in traffic
Cons
- No access to the server itself. Will need to implement new ways and customization work in order to log and read application errors.
- If you are not planning on using Epi-Find you're paying for a service you are not using
- As more services are managed for you, the perceived costs are higher than managing it in-house
Conclusion
If you're reading this, then I'm hoping you can see which hosting option is the best can't be answered. Every company will have different digital objectives, different in-house capabilities, and budgets. All of these will factor into which solution is right for them. Personally, I like the offering of DXC and the thought of having everything done for me simplifies my life and lets me concentrate on the things I care about.. creating cool digital products.
If a company has a large IT infrastructure support for other business critical services, then this might be less appealing than a small company in an attic. For me, the main choice depends on the level of control and management you want to have over your website. If you have to have access to a box to install specialist software on then your options might be limited. In most of these cases, though, a look at the architect can usually help. DXC isn't the cheapest option, but then again, that's not what it's designed for. Like anything, you pay for the quality of server and it's up to you to decide what you want to offload externally and what you want to manage internally.
-
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.
Caching
When 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 expiry headers set correctly, your servers will do the minimum amount of work.
Log Files
In 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.
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.
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.
Configuration
Traditionally, I think most developers have used AppSettings to store a website's configurable features. As DXC is a managed service, if you need to quickly update an AppSetting then you'll need to deploy to pre-production and wait for them to publish your changes before you can do it. 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 Episerver, as discussed here.
Transforms
In a normal release, you would use debug/release as your transforms. In DXC world you would use web.intergration.config, preproduction.config, and production.config to perform your different transforms in the Episerver environment.
-
This is another simple and easy guide for people like me, who can never remember URL's. Logging a ticket with Episerver DXC's managed services team is pretty easy. You log tickets via the online portal here:
https://servicedesk.episerver.com/otwg/Login.aspx?guestlogin=1&tzo=0
The portal's log in page should look something like this. When you sign up with DXC you should have been given one (or more) support accounts. If you haven't got one of these and you need one, in your monthly DXC call I suggest you raise it :P
One thing to note, the portal doesn't have a forgotten password feature, so if you forget your password, it's a little more complicated than clicking a resend password reminder, so make sure you use something you won't forget! Otherwise, make sure you have the support number to hand :P Logging a ticket is as simple as clicking the 'New Service Request' button and creating a new ticket.
Someone from Episerver usually gets back to you the day you raise a ticket, however, I have found that it can take 3-4 days to get a request to be actioned after raising a ticket. In the beginning, when you're setting up DXC for the first time, I would definitely factor this turn around time into your planning. After you raise a ticket, you'll get an email and from that point forward you can manage your ticket via your inbox, rather than needing to go into the portal again. Simples!
-
In today's tutorial, I'm going to walk you through how you set-up deploying to DXC via Octopus. Episerver also has a pretty good guide, available here, but I still struggled a little bit when setting it up.
Setting Up You DXC Account
The first thing you need to do is set-up an Azure/DXC account in Octopus. You will need some information from Epi/managed services to do this. If you don't have a Client\Application ID, Subscription ID, Tenant ID, and Password\Key then log into the service desk and ask for them.
In Octopus, go to 'Environments' -> 'Accounts', click on the 'Add' button.
Click on 'Add Accounts' which should be top right on the screen.
In the new account, screen give it a name like 'DXC Integration' and add in your details. You need to use 'Use a Service Principal' aside from that everything else is pretty obvious. When you click save and test, your Octopus will try and talk to Azure. The first time I did this the client I was working for had a WAF (firewall) which was blocking the request. So the test failed. I thought it was something I did, so if you find yourself in a similar situation then check with your infrastructure team first to ensure the request goes out.
Setting Up The Environment
After you have an account set-up, you need to create an environment. When you set-up your Octopus project, you need a way to tell it where to push your files... that 'thing' is the environment.
In Octopus, click 'Environments' -> 'Add environment'. Give it a name like 'DXC' and save it. When you look in your environments you should see your new entry in the list.
Click the 'Add deployment target' button next to your environment. This is basically configuring the server/web app that you want to deploy to.
Select 'cloud region' this is Octopus terminology for Azure web app.
The environment should be pre-filled so all you need to do is add a 'name' and a role.
Setting Up The Lifecycle
Next is the lifecycle your Octopus process will use. This is the container that will use the environment created above, to deploy to DXC.
Click 'Library' at the top and then 'lifecycle' on the left hand side.
Give your lifecycle a name, click 'add phase' and call it whatever and then in the environment list, pick the environment we created in the step above.
Deployment Time - Set up the deployment process
So now we've done all the set-up tasks, configured an Azure account, created an environment to deploy to and then created a lifecycle that we'll use in the build process to deploy our code to. Next, is setting up the deployment process. In this guide, I'm assuming you've already set-up a project in Octopus and you can build to it. If not you need to create a new project, all that standard Octopus stuff and isn't specific to Episerver or DXC.
Select your project from the 'projects' tab at the top and then select 'Process' on the left-hand menu.
Click 'Add step'
Click 'Deploy To Azure Web App'
Add in a step name. Select your Azure account from the Azure section. Add in your package id (how that gets generated isn't covered in this tutorial), this is the Nuget package that will get deployed to DXC. Add a channel at the bottom if you need one.
Deploy It
That's basically everything you need to do. As everyone will have different project configurations etc... the exact step you will follow will probably be slightly different to mine. The steps above give you everything you need to deploy to Azure. After you push to DXC, go the URL provided in DXC Services for the Integration environment, to verify that the website is working. At the start getting all the variables to transform etc.. will take a while. I personally find build scripts very frustrating and if you're like me, then good luck.
Also, note if you have a WAF or Firewall, then please be aware this might block the request. In a lot of situations, if the process fails it might not necessarily be something wrong that you've done. When you come to setting up DXC I suggest you make sure someone on your infrastructure teams free and available!
Quicklinks
Follow Me
what are you looking for?