This is Part 2 of 2 of my Drupal vs Adobe Experience Manager (AEM) blog post. In the first part, I've compared the two from the perspectives of content authoring, marketing, and business. In this part, I look at the two from an IT and community perspective. I also need to repeat my disclaimer that I'm a long-time Drupalist, but in this blog post I endeavor to be even-minded and objective.
IT Perspective
Information Technology (IT) covers a wide area of different disciplines. The disciplines discussed in this comparison are development, configuration, and nonfunctional considerations.
Development
This comparison further breaks down development discipline into back end and front end development. Back end development refers to custom development done to change the functionality of an application, whereas front end development pertains to the look of the application -- colors, fonts, layout, etc.
Skillswise, developing on top of AEM requires proficiency in the following programming languages: HTML, CSS, HTL, Javascript, and Java. Developing in Drupal also requires knowledge of HTML, CSS, and Javascript, but uses object-oriented PHP instead of Java. For Drupal, it's helpful to know the basics of the Symfony framework and the dependency injection design pattern. Also for Drupal, knowledge of Twig is required for theming, and knowledge of YAML is required for configuration of themes, modules, and distributions.
Back End Development
The heart of any content management system is, of course, the content, and how it's stored, created, accessed, modified, and removed. AEM and Drupal store their content differently.
AEM stores its content in files. The files are wrapped in a repository called Adobe CRX, which in turn is accessed by a variation of the web application framework Apache Sling. Thus, a developer needing to manage AEM content can do so programmatically by interfacing with Sling.
"Because this content is more structured than in files, more complex retrieval and management operations can be performed on it."
Drupal, in contrast, stores its content in a database. Though Drupal can interact with one of a number of different databases, MySQL is the most commonly used. Drupal wraps the database with components of the Symfony framework. Because this content is more structured than in files, more complex retrieval and management operations can be performed on it.
At the more abstract level, the data in both CMSs can be accessed programmatically through their frameworks, but their frameworks work differently. Much of AEM's activity is through HTTP GET and POST requests. A lot of information is packed into the url when accessing or managing a content resource, including the content resource type (e.g. wiki, image, etc.), the content resource itself, what script to run on it, and parameters the script needs. Sling parses this information and operates on it. Drupal processes its pages through HTTP GET and POST requests as well, using a Router-Controller-View process, where Router, Controller, and View are all executable components of the Symfony framework.
AEM can be extended with application-specific modules. Sling uses the OSGI (Open Services Gateway initiative) framework to allow for new packages of code, known as bundles, to extend the framework. The framework gives the developer easy access to perform such operations as install, uninstall, start, stop, update, and more. Adobe offers a Marketing Cloud Exchange where users can buy and download any from over 300 extensions.
Adobe Marketing Cloud Exchange
Developers can extend Drupal through modules as well, although the process is different. Modules can hook into Drupal's Router-Controller-View process. A developer can add their own routing file and controller to extend or even override Drupal's functionality or alter content. At this writing, there are over a whopping 3200(!) open source, downloadable modules for the current version of Drupal alone, and an even more whopping 20,000 modules available for the total of all versions. Project teams with a need to extend Drupal in a unique way are likely to find a module that already performs the extension for them.
Front End Development
For custom development for the front end, AEM uses HTL (HTML Template Language). HTL is JSP-like in that it mixes HTML and special directives. It is secure and does not require knowledge of Java to code in it. HTL is more secure than JSP because HTL automatically applies the context-aware escaping to all variables being output to the presentation layer. For example, expressions placed in href or src attributes are escaped differently than from expressions placed in other attributes. The same must be done manually in JSP, leaving the opportunity for human error allowing a cross-site scripting (XSS) vulnerability. Further, evaluation of the expressions and data attributes is done server-side and is not visible client-side. Any JavaScript framework can thus be used without interfering.
This all makes for a nice separation of concerns, where developers with different skill sets can work more easily in parallel.
<div>
<sly data-sly-test="${properties.jcr:title &&
properties.jcr:description}">
${properties.jcr:title}
${properties.jcr:description}
</sly>
</div>
HTL Example, from Adobe’s online documentation. Standard HTML tags are in red, HTL expressions are in green, and the special sly directive is in blue, which executes the expressions but does not appear in the HTML output.
Drupal employs Twig for front end development, which is a template engine for PHP and is part of the Symfony framework. Twig is also the name used for the engine's compiled templating language. When a web page renders, the Twig engine takes the template and converts it into a 'compiled' PHP template The compilation is done once. Template files are cached for reuse and are recompiled on clearing the Twig cache. With Twig the developer can define regions, include CSS and Javascript files, subtheme an already-existing theme, pass in various kinds of attributes (including content), and easily manipulate images. Just like with modules, each theme uses a YAML file to provide metadata about the theme to Drupal. Examples of such metadata include theme name, theme description, which group of themes the theme belongs in (also known as "package"), Drupal core version that the theme is compatible with, and much more.
<h1>{{ pageTitle }}</h1>
<div class="row">
{% for product in products %}
<div class="span4">
<h2>{{ product }}</h2>
</div>
Twig example from KNP University. Standard HTML tags are in red, Twig expressions are in green, and control statements are in purple
Configuration and Its Management
Configuration is the ability for developers and administrators to non-programmatically modify the behavior, not content, of the system. Examples of configuration include setting user permissions, defining content structures, and setting up taxonomies.
AEM allows the administrative user a number of places in which to customize the behavior of AEM without custom development. One place is the Adobe CQ Web Console, which is where OSGi bundles and services are configured. A subset of OSGi configurations are available in the repository and can be modified there. This ensures that copying repository contents will result in identical configurations. A few configuration files are in the file system itself and are editable. Finally, some configurations can be performed within AEM using its Tools console. Various functionality is configurable out of box, including classic vs. touch-optimized UI, version purging, logging, run mode (e.g. publish vs test vs development), defining redirects, replication between environments, LDAP, and much more.
Adobe CQ Web Console Configuration
Drupal's configuration resides in both its database and in dedicated configuration files. The database stores configuration for most of its functionality, including block management, content types, users, roles, permissions, menus, taxonomies, Views, module management, search, web services, workflow, and a great deal more. Further, database configuration can be managed from a few different endpoints, including the Drupal UI, Drush, and Drupal Console.
Dedicated YAML configuration files exist for modules, themes, and distributions. These configuration files are highly flexible. One can edit them based on one's needs, and the only restriction to editing is the YAML syntax and format itself.
A small part of Drupal's configuration UI
"Drupal stores site configuration data in a consistent manner: everything from the list of enabled modules, through to content types, taxonomy vocabularies, fields, and views."
Drupal stores site configuration data in a consistent manner: everything from the list of enabled modules, through to content types, taxonomy vocabularies, fields, and views. Configuration is stored in Drupal's database and is exportable to YAML files, making it easy to move configuration between environments, for example, development, test, and production environments. The recipient environment can easily import the exported-to-file configuration from another environment. Also, because site configuration is exportable to files, it can be stored as part of a project's codebase and is thus version-controllable.
Configuration management in AEM is simpler, in that all configuration is stored in files by default. Thus, no export nor import tasks need to be performed.
Nonfunctional Considerations
The term “nonfunctional” pertains to any non-user-facing quality of an application that warrants the attention and planning of an IT staff, including security, performance, and scalability.
Regarding security, like most CMS's, AEM manages user access through users, groups, access control lists, and control over what content can be created, modified, updated, and deleted, and by whom. AEM provides a Security Console to manage all user access. AEM documentation provides a checklist for project teams to follow to ensure site security. Also, as mentioned earlier, AEM's theme language HTL prevents XSS vulnerability by design. One area of vulnerability is in the Sling component, where unauthorized access to AEM’s content repository is possible if developers don’t follow best practices.
Drupal manages user access through users, roles, and permissions. Drupal provides an administrator fine-grained control over what content can be created, modified, updated, and deleted, and by whom. More than this, Drupal is designed with security in mind, and the worldwide Drupal community supports a dedicated security team to ensure rapid response to issues. Adherence to Drupal’s coding standards also safeguards against security risks.
Regarding performance and scalability, AEM works primarily with files, be they content, javascript, CSS, etc. AEM can thus take well-established performance and scalability measures such as caching, load balancing, and use of content delivery networks (CDNs). Adobe has written guidelines for optimizing performance for AEM, but they certainly can be applied to many other web solutions.
"Drupal has proven itself as highly scalable with such sites as The Weather Channel, GE, and the Grammy Awards."
Drupal can make use of these measures as well, but having the capacity to manage more highly-structured data introduces scenarios that require frequent database interactions, like user-generated content on a high traffic site. Without proper planning, excessive database activity introduces performance bottlenecks and can limit scalability. The Drupal community has written guidelines for managing this, and indeed, Drupal has proven itself as highly scalable with such sites as The Weather Channel, GE, and the Grammy Awards.
Community Perspective
Though some of AEM's components are open source, in the end it is a proprietary product. Though there are user forums for AEM developers to support one another, support is best delivered by Adobe itself. Some clients like to know that there's someone "at the other end of the phone" should something go wrong. However, at Mediacurrent, we're seeing less of this because of the now widespread acceptance and success of Drupal in the enterprise space.
An open source project with a community as large as Drupal's ensures the platform’s long term viability. Drupal’s community is enormous, with over one million participants worldwide from all skills and backgrounds, having contributing thousands of modules implementing almost any functionality one might want. With its depth and breadth of global engagement, Drupal is not going away anytime soon.
Drupal’s enormous, thriving community ensures a top tier platform for years to come. (From the Drupal Association)
Another benefit of having a large community is that the project is constantly undergoing a vast peer review, with countless independent developers working on the project worldwide. The community also supports a dedicated Drupal security team to immediately respond to new threats to keep the project safe. Also importantly, the community's ethos of teamwork and volunteerism drives constant innovation, keeping Drupal on the vanguard of Web CMSs and keeping it likely to integrate with whatever new trending technologies emerge.
Finally, a word about the people themselves. Those who would volunteer their time to contribute to the project tend to give of themselves in other areas of society as well, be it participating in their community or giving time and energy to nonprofits. And that's a special group of people to be around.
Conclusion
I've compared Drupal and AEM from several perspectives, including content authoring, marketing, business, IT, and community. There are some similarities between the two, but each has its differentiators. AEM provides an excellent user experience for content authors and marketers, whereas Drupal is more powerful and flexible in its ability to manage complex, structured content. Drupal and its contributed modules are free, whereas AEM has a substantial licensing cost and forces the buyer into vendor lock-in. AEM’s configuration management and scalability approaches are simpler, though Drupal has more than proven itself at scale. A tremendous advantage for Drupal is its community, which provides almost any extension imaginable, provides instant mutual support, and immediately responds to any new security threat. Despite my pro-Drupal bias, I hope this two-part blog post has compared these technologies in an even-minded way. I encourage the reader to explore and evaluate both of these further and to reach out to Mediacurrent when exploring Drupal particularly.