I was reading an interesting article from Digital Commerce 360, “Heard at NRF: Contradictory conversation from ecommerce tech vendors”. One of the topics that came up was inconsistent definitions of what headless ecommerce is. I thought I would share my thoughts on the topic and article in general.
Inconsistency and Change
The first remark that leapt out at me was “even these very savvy business leaders are frustrated by the constant onslaught of contradictory and changing mandates”. This rings so true to me. I must admit it is also why I find ecommerce so fascinating! It is a field of constant innovation and change. There is a stable common base (product catalogs, inventory management, shipping, payments, …) but there is also a lot of innovation as new ideas are explored.
Personally I don’t see this changing any time soon, if ever. Merchants are always looking for an edge to increase profits – that is core to their existence! This is why I think flexibility and openness of platforms is important, particularly for larger businesses. Your business can benefit from being ready to take advantage of future changes without a major overhaul of the whole platform.
On the other hand, having to piece together too many diverse systems can be expensive. This is why complete (pre-integrated) solutions are attractive. You get breadth of functionality without the cost of integration. This is a benefit of platforms supporting extension models. You get a core with an ecosystem of extensions that reduce the integration costs.
This leads into the comment “these tech vendors are in a tough spot right now, as the API-first trend nudges retailer expectations toward openness and flexibility, rather than locked-in, preconnected solutions”. I agree completely with this. Platforms that support more of a pre-connected solution can significantly reduce deployment costs for merchants … if the end result meets their needs. Platforms, however, also needs to be open so merchants can integrate with other systems. I see this problem as only getting worse for vendors, it will not go away. But I will also say I have not seen any vendors shying away from the problem. The ones I have talked to understand this as a business reality and are tackling the problem head on.
So what is headless commerce? Definitions offered up in the article include:
- “Commerce platform without a UI” – yes! But the article goes on to ask if it is the storefront or backoffice UI that is separated. My personal answer: the storefront. Yes, backoffice functionality should also have APIs to allow integration with external systems, but to me headless commerce is about enabling new creative consumer experiences, by not being locked to only the storefront experience provided by the vendor.
- “Decoupled or atomized bits of the full solution that may be deployed independently.” I (personally) don’t consider this a definition of headless. It is a fine architectural decision, but headless and independent deployment are orthogonal topics. You can have a headless solution with a monolithic backend. SaaS providers for example typically hide the exact service breakdown behind public APIs from it’s customers, allowing the provider to change internal architecture as needed without merchants being impacted.
- “API-first set of microservices”. This is not the definition of headless. It again is a fine architectural design pattern, but orthogonal to headless.
- “Categorized chunks of services…” going on to say some vendors had really implemented “macroservices”. Again, to me, not relevant to the discussion of headless.
So to summarize, headless commerce is about the separation of consumer experiences from the backend. It allows new, tailored, consumer experiences to be built while having a single product information management, inventory management, shipping, discounting, pricing, returns, etc backend. Consumers should see a business as a single business with multiple customer touch points. Prices and inventory should be the same no matter what the consumer touchpoint is (in store, online, over the phone, or via a pop-up kiosk). This is the point of headless – multiple consumer experiences, but one business.
I have written before on the topic of microservices. They have their strengths and weaknesses. But hopefully my definition above makes it clear it does not matter how back office functionality is implemented or deployed. It can be important when selecting a platform, but it is orthogonal to the term “headless”. Microservices can be thought of as taking the concept of separation for headless and pushing it to an extreme – everything should be disconnected and so more easily replaced, not just consumer experiences.
This approach offers a lot of flexibility. It becomes much easier to replace more parts of a system without disrupting the whole. The larger the business, the more useful microservice architectures are likely to be.
But microservice architectures come with increased operational costs. There are more moving parts. You need better deployment practices as there are more parts to deploy, in particular deployment orders due to potentially complex versioning dependencies. You need more advanced monitoring systems. Testing can be harder. The list goes on. I have built systems where I would not consider any architecture other than microservice based. But I think it is wrong to say monolithic architectures are always bad. You can still have good separation of functionality internally within the code base through good object-oriented programming practices. The main difference is in deployment. A monolith you deploy fewer independent services. This greatly simplifies deployment and monitoring, which can reduce operational costs.
Put simply, understand the pros and cons of any technology and use it when appropriate. I do not believe microservices are always better than monoliths.
I found it an interesting article. Terminology can always get muddled when marketing gets involved. If a term becomes an industry buzzword (potentially blown out of proportion), marketing departments kick into gear. Changing the product architecture itself can take time, so it is much easier to “stretch” the definition of terms so an existing product can get that checkbox of conforming to a new buzzword. This is not a criticism by the way – often the platform does solve the same requirement and that is what really matters. It is solutions to problems that matters more, not the technology used to do it.
From a technical perspective, I see “headless commerce” and “microservice architectures” as two separate concepts. The connection is microservice architectures are more naturally disposed towards supporting headless commerce as they have clearly defined API surfaces, mandated by the architecture. But headless commerce can certainly be implemented using a monolithic backend, if sufficient APIs are exposed.
I totally agree with you about the difference of headless and microservice.
And what about multi tenant headless commerce? It is something reusing some microservice tactics to solve the consistency of the whole platform?
Multi-tenant and headless again I think are different concepts that can be used together. Multi-tenant just means the backend is supporting multiple tenants. E.g. Shopify as a SaaS service probably has lots of small stores running from a single machine (I am simplifying here for discussion purposes). As such, it is multi-tenant. This often offers economy of scale. E.g. If the small stores only need 1/10th of a machine each, then Shopify can save money compared to someone allocating one machine per store because they can put 10 stores on one machine (multiple tenants). In reality, Shopify probably has a microservice architecture with multiple clusters for different purposes (different services), so a single store is more likely to be 1/100th of a machine in 10 different microservice clusters. Multi-tenancy is normally done for cost efficiency.
Oh, tenant = store in previous discussion if not clear. So multi-tenancy is about how many different stores a backend supports. Headless is about separating the frontend from the backend, allowing you to have multiple store experiences backed by your single catalog/inventory/orders/…
Normally tenant means customer. Magento you deploy per customer, but it can support multiple domain names (so it looks like different stores). I would not consider this multi-tenant because it is owned by one merchant – but I think its grey and could be argued that this is an example of multi-tenancy as the one server is supporting multiple stores. But Magento shares the inventory between the stores in this case – they are not completely isolated. Hence I don’t consider Magento multi-tenant. The stores should never be able to see each other or share any data etc for true multi-tenancy.
I agree with the frustration of shifting definitions of headless. You certainly hit the nail on the head with the complexity tradeoff. I believe that organizations should have the flexibility to use the pieces of a platform they like but replace other pieces. I recently wrote an article about implementing headless on BigCommerce with WordPress and found that even in this single case developing a common vernacular was a challenge. https://www.razoyo.com/2019/12/11/bigcommerce-wordpress-headless-implementation-3-options/
I would encourage you to check this article out. It really sums up Headless Commerce Architecture for eCommerce business owners who have decided to take the next steps to decouple their front and back end architectures but haven’t yet figured out what comes next. Explained in a simple, non-tech-savvy way to help your business move from traditional to headless commerce: http://bit.ly/3btd0YX