Many low-end and middle-end web CMS providers profess (indeed stress) scalability and extensibility but in my experience the architectures of those systems are fundamentally flawed in achieving these aims. What are your thoughts?
The design of most of the systems is centered on the website, i.e. web-centric, which is fair enough as they are not intending to be enterprise content management systems in the wider sense. However, they are also often web-server-centric and this poses significant scalability issues.
Issue 1: web-server-centric scaling and caching
In the web-server-centric (WSC) model, scaling is achieved by scale-out of front-end servers into a web-farm. Typically these servers share a single database but notifications are needed between servers to flush caches. This requires communication between front-end servers. Worse, the amount of communication traffic increases with each additional server in the web-farm reducing overall effectiveness of the addition of servers. Not to mention security issues…
Issue 2: web-server-centric connectivity and control
The WSC model typically only allows full access to the API via the web server. This may be exposed as a web service, or some other distributed communications technology, but the web server is still involved in interpreting the request. This means that any other system that needs to be involved in the creation, management or processing of content needs to have access to a web server. This again has issues for security and also scalability, as it increases the processing demand on each front-end server for work that has nothing to do with presenting content to a remote web-based client.
Issue 3: web-server-centric extensibility
Next on the list of woes is that custom business logic must be added to all the web-servers themselves, possibly compromising security, increasing the processing burden and also the complexity of the task. For example, the extension may need to operate in a guaranteed-once-only mechanism, but that is difficult to achieve with a pure API approach (advocated by many of these systems). Transactional behaviour like this typically needs either a message-based or a database solution. The code must also handle the possibility of an event being missed or fired multiple times, depending on the guarantees of the CMS API.
Issue 4: web-server-centric integration
Integration of other systems with WSC approaches require access to the front-end web servers, often require custom web services (or other extension points) to allow access to the specific APIs and further burden the already overloaded web server.
An alternative approach
An SOA design based on loosely coupled subsystems, installed on the same or multiple machines, would solve these issues directly. No additional hardware or software is required to support this approach but enterprise quality could be achieved by using discovery, orchestration, enterprise service bus and management systems.
Most of the systems I’ve worked with already have the necessary service boundaries in their internal API. To be truly SOA these interfaces should be adapted to support coarse-grained messages and properly controlled boundaries (exception shielding, process isolation, independent security).
What do you think? Do you agree that many low to middle range web CMS solutions get it wrong? Do you know of one that does not suffer from these criticisms?