Outsourcing Features on your Site

Drupal can be a scalable platform that can handle high traffic and serve large volumes of data easily with the proper configuration set up and server layout.  The large number of themes and modules in the community makes site development extremely easy and valuable in a sense that you can develop a large set of features in a short period of time without too many hours burned on coding everything from scratch.

 

Peter Cho, Senior Developer
#Drupal | Posted

Drupal can be a scalable platform that can handle high traffic and serve large volumes of data easily with the proper configuration set up and server layout.  The large number of themes and modules in the community makes site development extremely easy and valuable in a sense that you can develop a large set of features in a short period of time without too many hours burned on coding everything from scratch.

Knowing this, it’s tempting to simply install everything within your site.  However, if you are going to maintain a high-traffic website, it might be a good idea to offload some of these features elsewhere.

Plan and determine what features of your site should be maintained within your installation and which features should be hosted from external sources.  I’m not saying you should start copying and pasting embed codes from third party websites or start hosting all subsets of data and media files on separate servers.  More so, I recommend that you should entrust third party services to take care of certain features (especially if they can do it better than what exists in the module space) to minimize risk and increase performance.

There are plenty of modules that can help you with this.  For example, rather than use Drupal’s internal commenting module, you can rely on Facebook or Disqus to handle this for you.  Google Analytics is another way to analyze your site’s traffic externally.  I am also fond of other modules such as Paypal and Intuit Merchant Services, which handle credit card payments elegantly for you without the hassle of worrying about security right off the bat (assuming you configure your SSL certificates correctly).

Sharing (work) is caring!

So if, for example, all the comments on your site take up half the server space, wouldn’t it be nice to have someone take care of that so you don’t have to buy more server space?  You might be better off outsourcing that functionality elsewhere so that you can focus on more obscure features on your site.

I would suggest this approach for many reasons:

  • Reliable support for the application by a team of dedicated maintainers focused on one (or a few) functionalities
  • You can switch these features out with careful modularization
  • Simplifies your site’s architecture…and your job
  • More features outside Drupal’s framework
  • The features are readily available (in most cases)
  • More cost-effective (since the pricing is catered to sharing resources amongst multiple websites)
  • It’s kind of like running your website on several sites at the fraction of the cost (since these external services price their services efficiently to share them across various clients)

But do you trust other people with your information?

 You have to consider the potential repercussions that might occur if you do indeed take this route.  If you do decide to take this route, you should ask the following questions before you make the big move.

  • Is the service reliable?  If the service goes down, will my site go into utter chaos?
  • Is the data exportable?  If I build a new version of the site later on or if I want to use a different solution later, will it be easy to migrate it?
  • Does it have all the features I need and (a lot) more?  Can I trust that I won’t have to move to another solution 6 months from now?
  • Do I really want to own the data?  Will it be difficult to customize it however I want for my own needs?
  • Do I want to be liable for protecting the credit card numbers and other sensitive information in my database?
  • What does the terms of service say?  Do you truly own the data, or can they use it for certain purposes?
  • Do your users trust whoever is handling the data outside the site?  Will it tarnish your site’s reputation if you put it on the site?

You shouldn’t take some of these questions lightly.   Using a credit card processor with a history of data leakage or advertisement software that serves annoying and potentially malicious advertisements can ruin your site’s reputation.  It would be wise to do your research on anything you do externally before you implement it on your site.

Couldn’t I just create these features myself on my own separate servers?

If you have the funding and bandwidth to do it, go for it!   Many opt to use the Apache Solr module to delegate the search functionality away from the main site’s server to achieve this.  This approach is common and not unheard of.

Doing this requires more manpower.  Even if the features are developed externally, you still need to upgrade them internally.  Features maintained externally typically have the advantage of acquiring upgrades without a need to do anything on your end (that’s the beauty of webapps!).  Going this route, you should always subscribe to their blog to make sure you're aware of any changes they make on their end.

Note: At this point, you might think doing all this implies laziness.  Rest assured!  There is nothing wrong with good lazy, however, as long as you achieve the goal at hand.  When the job is done, the amount of work done on your end is trivial as long as you have the research and documentation to handle any future tasks proactively (i.e. be aware of any caveats and risks when using a service, and keep note of any muddy scenarios not covered by their guarantees).

In conclusion…

Remember a decade ago when things rarely ran on APIs, and most site maintainers typically have to copy and paste embeddable codes to achieve the same thing (not to mention the site’s architecture being bloated and messy after a while)?  In some cases, a lot of the code back then didn’t really fit everyone’s needs, so you tend to have a lot of duplicate codebases across sites that tend to go stale months after it gets implemented.

Consider it blessing that we’ve gone all this way to weave various web services into existing sites much easier while tapping into polished features without a sweat on your end!

Peter Cho

Senior Developer