EPiServer Server Architecture

Views:	7913
Number of votes:	3
Average rating:

EPiServer Server Architecture

Dec 06, 2012

Planning server architecture is usually based on a variety of requirements such as availability, performance, security, available budget, and more. In some cases, as I will discuss below, over-planning an architecture can actually reduce the performance of your solution. At EPiServer we help our customers and partners by asking the right questions and defining the architecture through this process based on the steps below.

Process steps/definitions:

1. Availability Management

High availability architecture typically includes multiple servers to ensure if one or more servers or system goes down your site remains up and running with your content accessible. Ensuring that systems have minimum dependencies on each other is an important consideration. For example, when integrating with a third party such as a CRM system it creates a higher probability of failure since your solution now depends on additional pieces be available.

2. Performance Management

Performance management is designed to ensure your site handles as many visitors as your requirements demand while also keeping server response and page load times within acceptable ranges. This concept is often relative depending on where the visitor is coming from and also how many visitors are coming to the site.

Many people might thing simply adding servers will help increase performance. However, adding servers could actually work against you. For example, if you have a very low number of visitors, adding more servers may actually slow down the site as latency is added in the load balancer.

For international companies a CDN network is often highly recommended rather than load balancing or mirroring to globally dispersed sites.

3. Information Security

Information Security is important to ensure that your content is safe from potential intruders and that the right content is available to the right users. Many customers ask for a content staging environment where they can have a completely separate site for creating content and approving it via workflows before it goes live to a production environment. This can often be accomplished using mirroring, which allows the staged content to be pushed to the production site.

Often, this is more than what is needed to meet the customer goals. Instead, having an authoring server behind a firewall may be a consideration as this can be equally secure. In this case the EPiServer backend UI is typically removed from the front-end server(s) and instead made available on a server inside the firewall, securely, as users need to be connected to a VPN to get access. In this case, the content contributors are making changes to the live production server and not to a staging production. Finally, for the best security it is always recommend to have the database on a separate server.

4. Change Management

Changing Management is a process which helps stakeholders manage, track, and implement changes to their environment. These types of changes typically include items such as patching new hardware or applying Windows updates, but not code changes. This effort can often be made easier with a test or staging environment that is identical or as similar to the production environment so that updates can be tested in an environment that is as close as possible, reducing risk when changes are made to the production environment. Typically a process for maintaining high availability should be prioritized above ease of changes.

5. Incident Management

Incident Management is a process of identifying and resolving issues through documented case (e.g. a support ticket) as well as investigation and/or research to determine the most appropriate solution. Finding and correcting problems in a load balanced environment with multiple servers first requires determining which server is causing the issue. Sometimes the investigation can take time as issues will often appear intermittently.

6. Release Management

Release Management is a predictable process for managing product improvements, upgrading of software/architecture, and meeting customer expectations.

7. Financial Management

Financial Management includes (but is not limited to): hardware, hosting, and EPiServer License costs. Often, available budget is the most imperative factor in a solution as each server also requires an EPiServer License. Each SQL License is also often five times more expensive than a typical Windows license.

5 different scenarios within EPiServer and some of their advantages

SINGLE SERVER	SEPARATE DATABASE	LOAD BALANCED FRONT	AUTHORING	FAILOVER BACK END

ADVANTAGES	ADVANTAGES	ADVANTAGES	ADVANTAGES	ADVANTAGES
- Cost efficient - Simple deployment - Easy to maintain	- Performance on database intensive applications - Preparation for scaling front end Securing sensitive data	- Availability on front end - Performance on front end - More resilient release management (staging) - Change management on front end without downtime	- Security on edit admin - Preparation for dual DC solutions using mirroring	- Availability on back end - Change management on back end without downtime
WHEN TO USE	WHEN TO USE	WHEN TO USE	WHEN TO USE	WHEN TO USE
This solution is appropriate for small websites where load is not a concern.	This is a typical solution for most websites. It offers the flexibility for scaling and provides additional security over a single-server solution.	This solution is appropriate for sites that receive moderate to high traffic. It allows for continuous uptime even during change management and enables more control over desired performance.	A separate authoring environment is often necessary for a company to protect proprietary information and have more control over the release of content, information, and data. This solution typically requires internal (or VPN) access into the environment and provides the most security.	Failover planning in an environment eases change management and reduces the risk of downtime. One common architectural scenario is to plan failover both on the back-end and on the front-end. Typically the technical considerations (and possibly financial implications) for these two scenarios differ.