This means that you can have your web server or web servers anywhere on the planet, as long as you have IP access to ftp files and SQL access if you have a front-end database server.
As your web presence is likely to be absolutely mission critical, you can host your website internally or with a third party without any issue. If you want us to host the site for you, we offer specialised Contensis hosting services. This service was set-up because it makes support easier, as the same people who support your CMS support our hosting infrastructure too, so there is only one number to call or helpdesk issue to log.
However, if you want to configure your front-end web server(s), we have very likely been there and done it already with almost every configuration you can imagine. The key really is to have a resilient solution, with a simple recovery model and simple scalability when your website grows.
Throw the CMS Server out of the office window and your website will still be fully-functional.
We often joke in presentations that you could throw the CMS out of the office window and your website would still be fully-functional; perhaps an extreme example but it demonstrates the point.
De-coupled publishing is something that only a few of the CMS providers can actually deliver. Many have a half-hearted solution that they claim is de-coupled but only a few, including us, have a complete solution. In order to understand how the system works, we have provided a diagram below of a simple front-end architecture.
In essence, all files are sent via FTP to the Web server. All you need do on the web server, using IIS as an example, is simply configure the FTP and configure a website to point at it. There is no need to install any Contensis software on the server at all. This means that once you have a server available for Contensis to publish to, it will take care of the rest for you.
Keeping on the theme of IIS and .Net publishing, we actually deploy the entire bin directory through FTP, configure the web.config and publish all the ASPX pages.
You don't need to lift a finger.
If you want a new server in your load balancer, or just a hot replacement server for the event of failure, then, assuming the server has an OS and IIS installed, your site can be publishing to it in less than 5 minutes.
Some may ask, if you are publishing pure flat files, and the system is decoupled, then how do we produce dynamic data such as a news archive, for instance, or render menus.
A nice part of our licensing model is that we do not charge for extra front-end web servers. If you want five, go for it!There is no extra cost other than the hardware, and only requiring a simple standalone server per front-end server, the cost of resilience and scalability is low.
Typical web servers that Contensis can publish to.
As Contensis publishes using FTP, any web server that serves files is a possible contender, although if you want to use our standard .Net Web Controls, then a Microsoft IIS server is required. If you are happy to develop your own controls or wish to use Java, PHP or JSP, you simply configure this against the templates and define a standard publish template.
Whatever your web server, we support publishing to it. Examples include Apache, Domino, Zues, Yaws, Microsoft IIS (Internet Information Services) and Zope, to name a few. A brief comparison of web servers can be seen at:http://en.wikipedia.org/wiki/Comparison_of_web_server_software. .
The short answer to whether your web server is supported is that if you have it we can publish to it.
System Resilience And Scalability
Resilience and scalability for the front-end is very simple; in essence just add any number of web servers you like, fronted with any IP load balancing system you like. Can it be that simple?
With Contensis it is absolutely that simple. There are no extra licence costs, all you need do is pay for the physical or, of course, virtual server and operating system licence, and once the server has an operating system installed the system can be up and running in as little as 10 minutes.
For every one of our customers, performance is a very key issue. If you have read about Contensis, you will probably realise that we do not have a reliance on a single or cluster database server. This really does open up our options as we don't have a single point of failure from a performance perspective.
Each front-end web server can standalone, from a performance perspective. Usually we would recommend that our customers, if they are expecting high traffic, simply load balance their web server to ascertain a level at which it will happily serve requests and if necessary simply introduce extra servers to cope with extra load.
When we are looking at performance, obviously load is an issue but what you can get out of a single server is very important too. Contensis has had literally hundreds of tests applied to get the absolute most out of the code. We use tools such as Ants Profiler to examine, line by line, our source code to ensure that there is no better of more efficient ways to achieving the same result. We find that often a switch from using a regular expression to a brute force code search, for example, has improved areas of the system by as much as 500%.
We regularly carry out performance analysis on our code to ensure that it runs at the absolute optimum, this goes for the CMS back-end too!
When running in a .Net environment, we naturally utilise ASP.Net page output caching, which in our experience can improve performance by up to 10 times. However, this should be configured carefully in situations where you have dynamic elements such as a news homepage, as you want to make sure that the caching is not preventing new news from coming through for too long.
Typically, a caching implementation is done on every new system that goes live, and generally it can be configured in a few minutes. The difficult part is just ensuring you agree the principals from a management perspective (i.e. how long are we happy to wait for the latest news article to appear; 1 minute, 5 minutes an hour?). As each page of the site or type of page can have a different cache profile, we simply need to decide these profiles and then implement them.
Disaster recovery is a very important topic for all of our enterprise and even non-enterprise customers. We provide scalability and disaster recovery solutions at a fraction of the cost of our competitors.
The way we can achieve this is that we publish data, if required, to each of the front-end servers. This means there is no requirement for a SQL cluster in the front-end web architecture.
Use Contensis and save £20,000 or more on your web architecture in the first year alone
Removing the requirement for a SQL cluster, and SQL Express being used for each of the individual web servers, can offer a saving of over £20,000.
You may wonder how SQL Express can be used in an enterprise scenario, but bear in mind that Contensis operates a disconnected publishing platform, so the database is used only as an index for certain data and rarely exceeds the 4GB limit even in configurations with 50,000+ web pages.
Probably the most important area to consider is the cost saving, which in today's economic environment is an important factor. With Contensis you can have the same resilience and scalability at a fraction of the cost.
Although cost is certainly an important factor, it is also worth thinking about the time impact; a complex solution is much more onerous and requires far more maintenance.
This architecture diagram shows a cluster of front-end web servers, fronted by a load balancer, with an optional SQL cluster
Web Architecture - Resilient A
This web architecture diagram shows how Contensis can be deployed in an environment with any number of front-end web servers.
As you may notice, there is an optional SQL cluster. This is optional because you do not require a SQL database unless there are specific Contensis modules or features you are using from Contensis that require one.
You could, for example, be using a different database server such as Oracle to service dynamic data.
This architecture diagram shows a cluster of front-end web servers, each of which have a separate install of SQL Server
Web Architecture - Resilient B
This architecture is the most cost effective way of delivering Contensis within a totally resilient solution.
Contensis can publish a separate set of data to each of the SQL servers installed on the web servers. As even with the largest implementations this SQL database rarely grows above 4GB,
SQL Express can be used, which is free.
This architecture gives you database resilience without the need for a SQL cluster and the extra hardware and licences that go with it.
This architecture simply involves one server for your front-end website; this could be shared hosting from a hosting provider
Web Architecture - Non-Resilient A
This architecture gives you a single server deployment, which means that if the server fails for any reason, your website could go down.
This architecture includes an SQL server on the web server to serve any dynamic content that may be required. Often SQL Express, which is free, could be used in this scenario.
This solution is likely to be the most cost effective architecture and if you run VM Ware or another virtualisation technology, restoring the system in the event of a disaster has minimal configuration requirements.
This architecture simply involves one server for your front-end website, with a separate database server.
Web Architecture - Non-Resilient B
This architecture is identical to Non-Resilient A, except that the system uses a separate database server.
The database server would normally be separated for performance reasons, but could simply be because you already have a SQL Server configuration in the web hosting environment.
Although the diagram does not show it, the SQL server could be a SQL cluster if required.
The solution is simple but again non-resilient if the single server fails.