Episerver licensing has become an increasingly difficult topic to understand. With more websites being hosted in the cloud compared to the traditional on-prem server-based, what used to be a pretty simple conversation about the number of licenses you need has become a lot more complex.
When I've dealt with Episerver licensing I've encountered huge confusion even from the Episerver account managers about the definition of 'what counts as a server'. Getting your licensing wrong can cause unexpected costs later on, delayed site launches and unhappy clients, so getting this right is essential!
To help ensure that you do not also fall into this trap, I've written this unofficial guide. I recommend you read this article before purchasing an Episerver license. This is an unofficial guide and is written by someone who implements Episerver on a regular basis, compared to an employee of Episerver.
Traditional On-Prem Hosting
Back in the good 'ole days, Episerver licensing was pretty easy. You'd run your application on a web server and you paid a license for it. Simple. If you wanted a load balanced solution, you paid for a license for each node in tour cluster. Two servers = 2 licenses. Developer licenses have always been free, for development use and you can generate themselves.
If you are new to Episerver and want to know how to create a developer license, then I suggest you read, Episerver license, what is it and how do I get one?. Episerver defines a developer license as the one you use to build your project on, if you wanted a staging server, a QA server or Intranet then you need to purchase an additional license per server. This model still is still available for Episerver and many companies still host their environment on dedicated hardware and use this.
With the growing popularity of the cloud, the conversation around licensing starts to become a lot more tricky. In cloud terms, you have different hosting options:
- Sass (software as a service) You get access to an application that is in the cloud, everything is managed for you. Think of Gmail as a Sass product. Episerver does not work this way, so this is the last I'll mention of it.
Pass (platform as a service) - In Pass your host Episerver as a web app. A web app, as the name applies is an application that runs in the cloud. In a web app, you don't have access to a full server, you do not have access to IIS or Windows. Instead, in Paas you create a web app by clicking a button in the Azure portal, you copy your Episerver code into Azure, via FTP, GIT or a Visual Studio publish and that's it. Everything on top, like Windows, IIS etc.. is all taken care for you.
Iass (Infrastructure as a service). IAAS is basically the same as a traditional hosting environment, you have some dedicated virtual servers hosted, however they are hosted in the cloud, you can RDP onto the servers, you can access the system event logs, you can install software on them as you see fit. PASS, on the other hand, can be thought of as Episerver running within virtual server hosted in the cloud. process rather than within IIS.
Pass and Iass are the two approaches you will need to decide upon between them. When you host your site in Azure for example, Pass is cheaper as you pay for what you use. If you have a virtual server to host your site you end up paying for a load of resources that spend most of their time sat around doing nothing.
With a VM you still need to worry about patching servers, anti-virus, etc.. with Pass all of this is managed for you. In a Pass environment, if your website suddenly gets loads of traffic, scaling becomes simple. Historically, if you failed to plan your load correctly and your website got too much load, you would have to buy a new server, buy a new Episerver license, deploy your code to it and then add it to the load balancer.
Introducing a new server into the mix, can take days or weeks, leaving your site low and sluggish and potentially, not to mention the amount of potential revenue loss. Paas makes our lives as application developers a lot easier, your web app can be scaled to include more RAM, processor speed, data storage virtually and within a few seconds.
Episerver Cloud Licensing
This is the part of the story where Episerver licensing gets tricky. Episerver has two licensing models:
The biggest confusion between these models and Episerver comes from the definition of 'server' between the two. The word 'server' means two different things depending on what license you are buying. This is very annoying and frustrating thing about Episerver licensing AND you need to be aware of this.
'Server' in terms of the on-prem license, means as the name suggest a SERVER.
'Server' in terms of cloud, means AN APPLICATION POOL instance.
The terms are in bold as this makes a massive difference and can completely screw a clients budget over if you get that wrong.
You may want to buy an Episerver cloud-license with an IAAS set-up. If you run multiple sites on the same server, with a cloud license, if each of those sites has it's own application pool, in terms of the cloud licensing this means that license has multiple SERVERS no one. Even though they are all hosted on the same server, cloud licensing is targeted towards web apps. In web apps terms, each application pool is a server. Confusing? AGREED!
If you are running two websites, in two different application pools, on the same server in the cloud and you think that means you'd only need to buy 1 cloud server license. This assumption is wrong. You need 2.
Think of a cloud license in terms of web apps. A web app is effectively a website with its own application pool.
If you use web-apps and a cloud license you don't need to worry. If you try and run a cloud license on a traditional server set-up, double check with your account managers over licensing. This approach mixes things up and causes confusion. A server in terms of a normal definition means a server. A server in terms of an Epierver cloud license means an application pool...
Why Use A Cloud License In Iaas?
Say, one day, you have a sudden burst of traffic and you need to create a new VM to handle the extra load, you deploy your code to it and add it to the cluster. You now hit an error as this new server won't have a valid Episerver and the license error will display for anyone who visits that site. The only way to deal with this load then is capacity planning. You need to give your best guess as what your maximum license requirement ahead of time. This isn't ideal as you then need to pay for those idle licenses until that fateful day comes when you need them.
In Pass, it gets even harder to measure with the traditional license, as you don't know the number of processes running your application. So in the past you might have had 10 licenses, you now only need one web app, so your license costs need to be determined by usage, rather than the number of servers your Episerver is installed on. This is why the question of which type of license to purchase has become really confusing and also needs to be a factor when you start designing your network infrastructure.
One way Episerver combats this complex is through its Episerver managed to host solution, called DXC. The DXC services come with all the licenses you need, you get three Azure environments for live, pre-live and testing, you get unlimited autoscaling of apps (the only real way in EPiserver ATM), you get unlimited sub-domains so you can host as many micro-sites as you need, you get unlimited Epi Find usage. I won't get into the pro's and con's of DXC in here, I'm just going to talk in terms of licensing benefits, but if you need to host multiple things with Episerver it might be worth a discussion with an account manager.
So in terms of true Episerver cloud autoscaling, DXC is your only real option. If you decide the DXC service isn't the solutions for you, the current IAAS licensing model means you can't be fully elastic with Episerver. In this situation you have to rule out autoscaling, instead, as mentioned above you need to buy a predetermined number of licenses based on your assumed max license requirement for the year. This means that sadly you're paying for licenses that won't use most of the time if you run a site that sits quietly most of the time and then has a big summer sale, or, a Brexit day type of spike.
To try and make the model more financially beneficial, if you run a test / QA environment, you could buy a cloud license for 6 machines, use 3 for live and 3 for staging. If you need to burst the live site for a few days, you can then manually deactivate your staging licenses and re-apply them to use in your live environment. This ability to activate and deactivate licensing is the main difference between an Episerver cloud license and a normal Episerver license. A traditional license is bound to an IP or MAC address, cloud licenses aren't. Also, it's worth noting that a cloud license comes with an additional 10% price tag compared to a normal license.
As I'm hoping you can see, licensing has definitely become a lot more complex in the next few years.
If you host more than one Episerver website on a server and use a cloud license, be aware!!! The on=prem license and the cloud license is not a like-for-like. They are very different and the way a server is defined is different.
I'm hoping that in the future, regardless if you choose Paas, Iaas or DXC then you have an option for a fully elastic system. It would be good to be able to pick a hosting model that best suit your business and know you had a corresponding Episerver license, but at the minute, it is what it is. If you want a fully elastic Episerver website, DXC is your only option. I fully admit I wouldn't know where to start if I had to design a pay by usage license for a non-DXC web app, or, an Iaas hosted application.. so I can completely understand why licensing is the way it is.. but then hey, that's why I implement websites and not build CMS applications ;)