As a developer I have helped many big organizations to publish their sites and place them in EPiServer’s own Digital Experience Cloud (‘DXC’), which is supported and managed by EPiServer Managed Services.Here are some of my thoughts and experiences from the developer and customer perspective.
This article is a torso and is currently being written.
Why should my organization consider to place our new web site in EPiServer’s DXC?
- Because it gives you additional flexibility and confidence to be able to switch (boot) the company that actually develops your websites. Once they are gone, the site is still in DXC and EPi supports it. You still need someone to actually maintain and support your code, but your dependency of a company opening both the consulting and the website are reduced.
- ‘My company’s Preferred hosting partner is so much better.’ So they think. Over my career I have see so many bad hosting providers. I see customers turning to their long term strategic partners who ‘host their SAP’ or some other part of the infrastructure. Believe me, those companies are mostly the worst, they have no idea of the product, but they know how to charge for hosting the service. They don’t support you but just provide the servers and the network.Let them host the SAP, strong avoid.
- ‘I buy my web site from this consultancy x. So let them host the site, too. So easy.’ Until you notice that the agency is actually not that good, or they start overpricing. You find another consultancy to build your EPiServer site, and you want to transfer the website from that old agency partner, too. Probably the new agency moves it into Azure. You can bet the original partner will charge very much for any transfer activities, it will be difficult and expensive. If it’s in DXC, you just inform EPi of the new partner and they will grant them access and throw the old partner out.
- If the site performs poorly, the vendor of the site can claim this to be a ‘server’ or a ‘network’ issue, trying to find excuses for a poorly coded EPiServer site to perform slowly. With DXC, you can ask them to analyze the bottlenecks of the site and to give you the needed information on what causes the bad performance.
- Setting up an EPiServer in Azure (which DXC uses) is very, very, very very easy. Additionally, you get rid of their cumbersome, slow support plus you can manage all aspects of the server by yourself. You can publish to production when you need to do it.
- Setting it up in Azure is dirt cheap. You save a lot of money.
How is the deployment process?
As a developer, you publish your changes to an environment they call ‘Integration.’ This is where you get the necessary details to publish directly from Visual Studio. You also get access to the Sql Azure database for the integration environment.
Normally, as a developer, you publish to Integration and review the changes there. Once you or your testers are confident that the solution works well enough, it can be further published to the Preparation environment.
In order to publish a new version to Preparation, it must first be published to Integration. You then write an email to the support mailbox, email@example.com. Alternatively, you can place a support request (or an incident) at https://servicedesk.episerver.com.
The truth – how well and fast does the deployment work?
It depends. If you are an ‘early bird’ in the EMEA area, or you are located in Asia, publish the changes when the support center in Vietnam starts to work (CET=early in the morning!). No matter what, they solve your issue and take it almost personally to get it done. You can send them any kind of ticket, from simply publishing a website to making complex changes, and they do it. They do it right away. And they do it professionally. Even if your problem looks insanely wrong (it looks as if there is no problem at all, or they cannot reproduce it) – these guys take you seriously. It does not take much time to fix an issue with them.
EMEA area (Stockholm) support is very professional and knows how to solve issues. But if you are unlucky enough and need to request a change when the US support kicks in, then be ready to wait .. and wait … and wait, if it has any more complexity to it. Based on my personal experiences I think the time taken of your ticket to be successfully processed seems to be strongly bound to the person handling it.
Australia? Not sure.
These are just subjective personal experiences.
How is it to work with DXC as a developer?
The drawbacks of DXC are from my perspective:
- No remote debugging from Visual Studio. Makes your debugging / problem solving painful.
- No direct access to the database, any changes to the database directly (like Create / Alter tables + Inserts) need to be performed by DXC.
- It’s just painfully slow sometimes to publish from integration to prep and prod, and to realize that, um, the remote service the prod environment is accessing is giving an error, it’s not your fault but you have to put in all kinds of manual logging and manual debugging into the code and deploy, re-deploy through DXC, with each publish and bug fix taking an average of 2-3 hours.
How do I publish database changes, or custom database context?
All changes from Integration to Preparation and Production are performed by DXC. Some of the support engineers need a little more guidance when doing more complicated database stuff, or when importing data, but it will work.
How do I publish to production?
Through preparation. Even if you don’t use the Preparation environment (e.g. you are not yet on a live site), you still need to go through the Preparation to publish to Production. And of course you need to order this when you have published your working code to Integration.
Even after the drawbacks, I’m quite satisfied of DXC and their support process and the support engineers. There are many drawbacks, but compared to using other hosting partners .. I have seen none outperform DXC. What I would consider as the most viable competitor of DXC is to place your site directly into Azure by yourself. It’s easy and in effect, DXC does not do that much maintenance to the site to require it to be part of the maintenance deal. It’s actually not that useful from many perspectives, but from the client side it gives extra benefits by having a more neutral partner monitoring the site and giving feedback or analysis on its performance.
Wrapping it up; I can easily recommend DXC to any organization implementing their web sites or portals on it.
For anyone publishing for personal use, I recommend Azure. Oh, wait, there is no real license for developers to publish their non-commercial hobby sites on EPiServer, is there? Hmm, that is the reason why I’m not that faithful to EPiServer myself, rather looking for other platforms as alternatives for small sites 😀