Today, Acquia announced a partnership with Elastic Path, a headless commerce platform. In this post, I want to explore the advantages of headless commerce and the opportunity it holds for both Drupal and Acquia.
The advantages of headless commerce
In a headless commerce approach, the front-end shopping experience is decoupled from the commerce business layer. Headless commerce platforms provide a clean separation between the front end and back end; the shopping experience is provided by Drupal and the commerce business logic is provided by the commerce platform. This decoupling provides advantages for the developer, merchant and shopping experience.
For developers, it means that you can decouple both the development and the architecture. This allows you to build an innovative shopping experience without having to worry about impacting a system as critical as your commerce backend. For instance, you can add ratings and reviews to your shopping experience without having to redeploy your commerce platform.
For merchants, it can provide a better experience for administering the shop. Traditional commerce solution usually ship with a lightweight content management system. This means that there can be competition over which system provides the experience layer (i.e. the "glass"). This can introduce overlap in functionality; both systems offer ways to manage URLs, create landing pages, manage user access rights, theming systems, etc. Because headless commerce systems are designed from the ground up to integrate with other systems, there is less duplication of functionality. This provides a streamlined experience for merchants.
And last but not least, there is the shopping experience for end-users or consumers. Consumers are demanding better experiences when they shop online; they want editorials, lookbooks, tutorials, product demonstration videos, testimonials, and more. They desire the content-rich experiences that a comprehensive content management system can provide.
All this is why Acquia is excited about our partnership with Elastic Path. I believe the partnership is a win-win-win. It's a win for Acquia because we are now better equipped than ever to offer personal, unique and delightful shopping experiences. It is a win for Elastic Path as they have the opportunity to provide contextual commerce solutions to any Acquia customer. Last but not least, it's a win for Drupal because it will introduce more organizations to the project.
Note that many of the above integration challenges don't apply to native solutions like Drupal Commerce for Drupal or WooCommerce for WordPress. It only applies when you have to integrate two entirely different systems. Integrating two different systems is a common use case, because customers either already have a commerce platforms in place that they don't want to replace, or because native solutions don't meet their needs.
Acquia's commitment to best of breed
Acquia remains committed to a best-of-breed strategy for commerce. There isn't a single commerce platform that meets the needs of all our customers. This belief comes from years of experience in the field. Acquia's customers want to integrate with a variety of commerce systems such as Elastic Path, SAP Hybris, Salesforce Commerce Cloud (Demandware), Magento, BigCommerce, Reaction Commerce, Oracle ATG, Moltin, and more. Our customers also want to use Drupal Commerce, Drupal's native commerce solution. We believe customers should be able to integrate Drupal with their commerce management solutions of choice.
Configuration management is an important feature of any modern content management system. Those following modern development best-practices use a development workflow that involves some sort of development and staging environment that is separate from the production environment.
Given such a development workflow, you need to push configuration changes from development to production (similar to how you need to push code or content between environments). Drupal's configuration management system helps you do that in a powerful yet elegant way.
Since I announced the original Configuration Management Initiative over seven years ago, we've developed and shipped a strong configuration management API in Drupal 8. Drupal 8's configuration management system is a huge step forward from where we were in Drupal 7, and a much more robust solution than what is offered by many of our competitors.
All configuration in a Drupal 8 site — from one-off settings such as site name to content types and field definitions — can be seamlessly moved between environments, allowing for quick and easy deployment between development, staging and production environments.
However, now that we have a couple of years of building Drupal 8 sites behind us, various limitations have surfaced. While these limitations usually have solutions via contributed modules, it has become clear that we would benefit from extending Drupal core's built-in configuration management APIs. This way, we can establish best practices and standard approaches that work for all.
I first talked about this need in my DrupalCon Nashville keynote, where I announced the Configuration Management 2.0 initiative. The goal of this initiative is to extend Drupal's built-in configuration management so we can support more common workflows out-of-the-box without the need of contributed modules.
What is an example workflow that is not currently supported out-of-the-box? Support for different configurations by environment. This is a valuable use case because some settings are undesirable to have enabled in all environments. For example, you most likely don't want to enable debugging tools in production.
The contributed module Config Filter extends Drupal core's built-in configuration management capabilities by providing an API to support different workflows which filter out or transform certain configuration changes as they are being pushed to production. Config Split, another contributed module, builds on top of Config Filter to allow for differences in configuration between various environments.
While the initiative team is working on executing on these long-term improvements, they are also focused on delivering incremental improvements with each new version of Drupal 8, and have distilled the most high-priority items into a configuration management roadmap.
For Drupal 8.7, we're planning on shipping an experimental module for dealing with environment specific configuration, moving the capabilities of Config Filter and the basic capabilities of Config Split to Drupal core through the addition of a Configuration Transformer API.
For Drupal 8.8, the focus is on supporting configuration updates across different sites. We want to allow both sites and distributions to package configuration (similar to the well-known Features module) so they can easily be deployed across other sites.
How to get involved
There are many opportunities to contribute to this initiative and we'd love your help.
MacOS Mojave, Apple's newest operating system, now features a Dark Mode interface. In Dark Mode, the entire system adopts a darker color palette. Many third-party desktop applications have already been updated to support Dark Mode.
Today, more and more organizations rely on cloud-based web applications to support their workforce; from Gmail to Google Docs, SalesForce, Drupal, WordPress, GitHub, Trello and Jira. Unlike native desktop applications, web applications aren't able to adopt the Dark Mode interface. I personally spend more time using web applications than desktop applications, so not having web applications support Dark Mode defeats its purpose.
I learned about the prefers-color-scheme media query on Jeff Geerling's blog, so I decided to give it a try on my own website. Because I use CSS variables to set the colors of my site, it took less than 30 minutes to add Dark Mode support on dri.es. Here is all the code it took:
If you use MacOS Mojave, Safari 12.1 or later, and have Dark Mode enabled, my site will be shown in black:
It will be interesting to see if any of the large web applications, like Gmail or Google Docs will adopt Dark Mode. I bet they will, because it adds a level of polish that will be expected in the future.
I remember taking the bus to the local bookstore to buy the Red Hat Linux 5.2 CD-ROMs. It must have been 1998. Ten years later, Red Hat acted as an inspiration for starting my own Open Source business.
While it's a bit sad to see the largest, independent Open Source company get acquired, it's also great news for Open Source. IBM has been a strong proponent and contributor to Open Source, and its acquisition of Red Hat should help accelerate Open Source even more. IBM has the ability to introduce Open Source to more organizations in a way that Red Hat never could.
Just a few weeks ago, I wrote that 2018 is a breakout year for Open Source businesses. The acquisition of Red Hat truly cements that, as this is one of the largest acquisitions in the history of technology. It's very exciting to see that the largest technology companies in the world are getting comfortable with Open Source as part of their mainstream business.
Thirty-four billion is a lot of money, but IBM had to do something big to get back into the game. Public cloud gets all the attention, but hybrid cloud is just now setting up for growth. It was only last year that both Amazon Web Services and Google partnered with VMware on hybrid cloud offerings, so IBM isn't necessarily late to the hybrid cloud game. Both IBM and Red Hat are big believers in hybrid cloud, so this acquisition makes sense and helps IBM compete with Amazon, Google and Microsoft in terms of hybrid cloud.
In short, this should be great for Open Source, it should be good for IBM, and it should be healthy for the cloud wars.
PS: I predict that Jim Whitehurst becomes IBM's CEO in less than five years.