Core Conceptions
Understanding core conceptions is probably the most important step in this comparison, however it is not easy, because core conceptions tend to hide themselves behind the obviousness curtain. Core conceptions seems so obvious to their authors or users, that they are almost always not even mentioned. They are transparent. But they impact everything else.
Acquia.comGetPantheon.comOmega8.cc
The only really working method to discover and expose them is to confront with something different. Acquia.com and GetPantheon.com share the same core conceptions. That is why comparing them doesn’t reveal it. It is still behind the obviousness curtain. Adding Omega8.cc to the comparison chart allows to reveal and better understand the core ideas behind all other technical differences we will discuss in the next articles. Let’s take a closer look at the core conceptions below, but note that we need to assume that you are familiar with some Drupal-specific jargon, even if we will keep it at absolute minimum.
MMonolithic Drupal Codebase – Your Drupal site is a single code repository. It can be cloned into separate environments, so the clones can be used in the typical dev->stage->live workflow. Everything is based on the underlying (Git) repository capabilities, like branches and tags. Thus you must understand what the Git, branches and tags are, and how to use them properly – you can’t avoid that, because it is a part of the essence of the conception. You can still initially develop your site using any method you prefer – either completely manual install and configuration in your local environment or modular setup with custom installation profile, well organized core and contrib code via makefiles, configuration exported to Features etc., but the final result must be committed as a Monolithic Drupal Codebase, so it can be properly and easily managed via control panel on your hosting account. The result is – and it is the key part to understand here – that your hosting control panel is basically a front-end to the underlying single code repository, so it manages both your site – its data and files, and your site’s code in the forced workflow. It needs to force the workflow even if it allows you to enable (temporarily) the “edit in place” mode, since the code must be tracked in the backend repository.
MModular Drupal Codebase – Your Drupal site is not the codebase. Your Drupal site is a provisioned instance of your Drupal Application, but the site itself doesn’t need to use any repository to manage its code – it is recommended, but not forced. Your Drupal Application is the installation profile, which includes all contrib code, along with the configuration exported to Features and lives in the Platform, which includes Drupal core. While the makefile is the easiest way to define and create a Platform, and the Platform is the environment where your Applications (the installation profiles) live, you can build it also manually and then add in the control panel. You can upload your contrib code either in the Application (installation profile) space, or in the Platform space. You can manage your code manually, or as a modular structure tied together with makefiles – exactly as it is expected from any Drupal distribution hosted on drupal.org, but you are not forced to use any method. There are best practices, recommended workflows, but nothing is forced, as expected from the system based on the “Tools, not Policy” principles. The result is – and it is the key part to understand here – that your hosting control panel is basically a front-end to the underlying Drush based backend, so it manages your site – its data and files, its Platform, but it doesn’t manage your code. It allows you to clone and migrate your site between any number of Platforms, so you are not limited to the 3-steps, traditional dev->stage->live workflow. While it doesn’t track your code in any repository, it does track your code meta-data (versions) in its own database (both in the sql database and drushrc files), to be able to check the code compatibility when you are migrating your site between different Platforms.
Both core conceptions have many implications, and we will discuss some of the most important in the next articles, while comparing all three vendors side by side. But to take a break from that magnitude of Drupal jargon, the next article will discuss something different – The Holy Grail of Scalability.
!We post new articles daily (Monday-Friday), so you may want to subscribe to this feed
in your favourite RSS reader to follow up and post your comments on Twitter or App.net.
Introduction « Previous | Next » The Holy Grail of Scalability.