Take the 2-minute tour ×

We're a team developing a hosted CMS (something like WordPress.com, but in .NET platform), and we want every site to get updates as we update our software. Our CMS is not multi-tenant, i.e. each site is an entire copy of a site template and has an individual database, files and folders, and would be deployed across many servers (2000 sites per server). Now our problem is that we can't figure out how to update all these sites in a centralized way, without users firing the update process (because this is a hosted solution, not on-premise). For example, imagine that we want to add a module to these sites and imagine that we have over 10,000 sites over 5 servers. It's really really really horrible to install this new module on 10,000 sites. Or imagine that we want to add a new template. Again it's not practical to copy template files to 10,000 sites.

Is there any known pattern for such a distributed hosted solution update/upgrade?

share|improve this question
Are different sites on servers that are not under your control? –  JeffO Jul 30 '11 at 12:54
add comment

1 Answer

up vote 2 down vote accepted


Stick with ordinary update processes which are currently used by most companies to update client or server-side software.

It's up to the users to trigger the update process when they need to update. It's even more true for a website, for several reasons (some of the reasons apply as well for client-side software):

  • Security: as a user, I don't want someone I don't trust to update my website at any moment without asking my permission,
  • Privacy: if your updates are accessing the database, how can the users be sure that their data will not be used maliciously by your company?
  • Performance: if most of my users are connected from 2 PM to 9 PM, and there are no or few connections between 3 AM and 5 AM, I want the updates to take place in the middle of the night, not when all the visitors are using my website. What if you're triggering the update at 4 PM?
  • Risk management: what if during an update, my website goes down? What if I notice it only after a week, and I find that it's your update that you've done without any permission which caused that? Would you compensate the financial loss?
  • Compatibility: what if I've done some changes or added some plugins which are not compatible with your updates?

So either don't do it, or be ready to be sued and to see your customers leaving you.

imagine that we want to add a module to these sites

What if the user don't need this module? Fewer code server-side means fewer security holes. If the user doesn't need an additional feature, there are no reasons to force him to have this feature enabled on his website.

There is an exception: hosted solutions with unified codebase. Consider the following cases:

Case 1:

  • Third-level domain name (mywebsite.example.com) or an optional redirect from a second-level domain name,
  • Hosted solution,
  • No server-side scripting,
  • No external plugins (i.e. plugins which are not already hosted),
  • No direct access to source or data (for example it is not possible to access the data of the database directly, nor to do backups and save them locally), etc.
  • Inability to migrate the website to another hosting,
  • Customization limited to the options in a configuration panel,
  • Forced advertisement embedded in the pages of the website (optionally removed if you pay).

Case 2:

  • Second-level domain name (mywebsite.com) or third-level domain name (depending on price),
  • Hosted solution,
  • Maybe server-side scripting,
  • Maybe external plugins,
  • Ability to make SQL queries and/or backup data locally,
  • Ability to download everything you need to migrate the website to another hosting,
  • Ability to customize the website by uploading additional content (stylesheets, images, etc.),
  • Maybe forced advertisement embedded in the pages of the website (optionally removed if you pay).

What makes the difference?

  • In the first case, we have a generic solution which tries to fit all the needs. If your needs are different, go away, our website is not for you. We own the service, so either you agree to use it as is, or you search for another one.
  • In the second case, we have a generic core you can use to build something which fits your needs. Now, you own the website.

Behind the scenes, it may have a huge impact on the architecture of the solution:

  • In the case of a generic solution, there are no files hosted separately for every website. If there is a CSS file for a specific template, this file is hosted once. For every of the thousands of "websites". If there is a PHP file containing a class which is used by every website, there is only one PHP file per server.
  • In the case of a generic core, on the other hand, there may be no unified hosting (even if it might be an option, but, well, when I build my own website hosted on my own server, I don't host JQuery, but use Google CDN instead, so it's the same thing). This allows a customer to change a specific file without affecting other customers.

You see that in the first case, per-user updates just don't work, and cannot be implemented. As a service provider, you can only update everyone at once, since everyone share the same files. You cannot ask users permission or let the specific user schedule the update. But in this hosting situation, the users are expected to be updated passively, so it's ok.

share|improve this answer
But @MainMa, as I said, this is a hosted solution. For example, your Gamil updates automatically and you'll never being asked. –  Saeed Neamati Jul 30 '11 at 10:02
@Saeed: GMail is a single service, which is not the same than 10 000 separate websites. There is also a notion of ownership: I don't own "my GMail"; your customers, on the other hand, feel like the owners of their websites. –  MainMa Jul 30 '11 at 10:12
Good points, however there is a hosted solution called Weebly which acts kind of the same. How do you analyze that? –  Saeed Neamati Jul 30 '11 at 10:14
I see. I edited my answer to address your concerns. –  MainMa Jul 30 '11 at 11:00
add comment

Your Answer


