Shopify Plus: The Last E-Commerce Monolith
Headless commerce technology has received $1.6 billion in funding and is powering cutting-edge e-commerce applications. With headless commerce, separating the frontend of an application from the backend gives brands and retailers greater flexibility in how they create digital shopping experiences. Platforms like Shopify Plus offer headless capabilities, but the real magic is in modular commerce technology.
Commerce modules, also called commerce microservices, are dedicated pieces of commerce functionality including cart, pricing, promotions, items, orders, shipping, payments, and more. These are what Amazon used to grow from a simple online bookstore to a massive online marketplace. But before adopting modular commerce, Amazon had to break down its monolithic bookstore application into distinct modules, also known as a service-oriented architecture.
When I joined Amazon in 2002, this initiative was well underway. But Amazon developers had to create these modules in-house. There was no commerce platform back then that could support Amazon’s new approach to architecture. IBM Websphere, Oracle ATG, and other enterprise commerce platforms were all monolithic. They were good platforms at the time, but rigid and hard to customize.
Shopify Plus emerges
A few years later, Shopify emerged from private beta with an all-in-one e-commerce platform for SMBs in 2006. Up until this point, e-commerce platforms only existed for enterprises as on-premise software. With Shopify, anyone could market and sell products online. It was truly revolutionary. But then Shopify wanted more. It aimed to take a slice of the enterprise pie with Shopify Plus in 2014.
Shopify Plus offered higher levels of support, increased API access, the ability to customize templated checkouts, a script editor, and more. This was a nice idea for upselling and diversifying revenue streams, but it failed to solve the big problem: scale. At the end of the day, Shopify Plus was—and still is—Shopify with some window dressing. It’s a monolithic platform like the legacy platforms that came before it.
Shopify Plus plateaus
People are starting to see through the facade of Shopify Plus and it shows in the numbers. Since Shopify Plus’s contribution of 17% to total MRR in 2017, growth has stagnated. In 2018, Shopify Plus contributed to 25% of MRR. In 2019, it contributed to 27% MRR. And in 2020 it contributed to 25% MRR. Shopify equates this dip to a “significantly higher number of merchants on standard plans joining the platform in 2020.” But there’s more to it than that.
One reason it’s plateauing is that Shopify does not support modern commerce architectures. In early 2017, Shopify had to make a similar decision as Amazon: keep its monolith or move to microservices. Unlike Amazon, Shopify decided to keep its monolith. This was easier for the engineering team but provided no value to customers. Shopify Plus customers would continue on the track of technical debt, vendor lock-in, and an unscalable, Shopify-dependent future.
Using Hacks to Remain Relevant
Shopify is trying to dress the platform up as a “modular monolith,” but all one has to do is look at the Isolating Dependencies section of this article to see that it’s hacked together. It’s hacked together like Shopify Plus. For instance, the Scripts feature hacks around the problem of dependencies within pricing, promo, and cart services.
In the end, a monolith is a monolith and limits growth. The same goes for BigCommerce Enterprise that’s hiding behind headless commerce, trying to make a case like Shopify against microservices.
As the former CTO of Staples where we moved from a monolithic commerce platform to a service-oriented architecture to scale, I can tell you first-hand that monolithic commerce platforms and hacking around technical debt does not work. When I joined Staples, we were using IBM Websphere. Creating short-term hacks would have been easier but would not have let us scale from 200,000 to over one million SKUs and completely own the buying experience.
Hacks limit growth
The technical limitations of Shopify Plus have real implications for brands needing to grow. Shopify Plus’ ease of use is great for getting started, but these limitations become critical as a brand grows and needs customization and innovation to make the next step. Below are some of the biggest restrictions for brands and retailers that want to scale.
Headless hacks
I see Shopify’s headless offering at its last stand to remain relevant. Shopify Plus is merely doing what all commerce platforms do, even the legacy platforms like Oracle ATG: exposing APIs. This hack allows retailers to customize the frontend, but the backend is still problematic. Store owners need to use rigid code integrations from the Shopify App Store to add backend functionality and integrating backend tools can cause problems for the Shopify Plus API.
Multi-location mismanagement
Whether you’re working with national stores and locations or international expansion, Shopify Plus is too restrictive. Although linking multiple domains is easy, Shopify Plus is restrictive in the way store owners can manage storefronts at different locations. This means that running different brands or catalogs from one backend is almost impossible. Shopify Plus doesn’t allow for configurable tenancy options because it’s rooted in the same principles as Shopify of being multitenant. This is great for small businesses but not so much for mid-market and enterprise.
Payment gateway nightmares
Although small-scale merchants find Shopify Plus’ payment delays a necessary evil for managing payments online, SMEs will struggle with Shopify controlling when and how they get paid. This is a prime example of vendor lock-in. When you sign up to use this monolithic platform, you have to use their payment gateway. Payment delays lead to delays in service delivery and store owners will face similar problems with frontend functionality, backend customization, and overall growth control.
Hacks and limitations in the wild
A good way to see the results of Shopify Plus hacks and limitations is to compare Shopify Plus’s flagship customer, Staples CA, with Staples US which uses a service-oriented architecture. Because Staples CA has thrown its hat in with Shopify Plus, they are hostages to a monolithic platform in the same way.
When comparing the digital storefronts, you’ll notice that Staples US is dynamic and escapes Staples CA’s standard grid layout. The Staples US checkout is also customized to include custom delivery options: delivery time, assembly options, and purchase protection. Meanwhile, Staples CA is locked into Shopify’s standard checkout offering. But the most alarming difference is the difference in page speed.
According to PageSpeed Insights, Staples CA receives a 43 PSI score:
Staples US receives a 99 PSI score:
Given what we know about page speed’s impact on e-commerce conversions, using Shopify Plus for an enterprise like Staples is simply irresponsible. Of course, Staples CA could try to hack around CMS limitations with the commodity page builder offered by Shogun or hack around Shopify API limitations with the shim layer of APIs offered by Nacelle. But at the end of the day, these are just hacks, not scalable solutions.
E-Commerce Monoliths are Fated
Monolithic commerce platforms become single points of failure because they are closed systems requiring specialized knowledge to program a process or business logic inside of them, whether that’s through RPC (IBM) or other procedural code required by SAP and Oracle. This creates dependencies that are not necessary and hinder product growth.
Shopify Plus is similar to legacy monoliths like Oracle ATG and Salesforce Commerce Cloud but, again, dressed up to look prettier. In the case of Shopify Plus, the specialized knowledge comes in the form of Ruby on Rails and the Liquid templating language. And because they can’t fix these technical requirements, they have hopped on the headless bandwagon.
Despite Shopify pushing monolithic rigidity as innovation, a monolith is a monolith and Shopify Plus is the last attempt a big company will make at building an enterprise e-commerce monolith. The question “Remember Shopify Plus?” will soon join the ranks of: Remember IBM Websphere? Remember Oracle ATG? Remember Amazon Webstore?
How to sniff a monolith
That said, other commerce platforms will hit the market. And with more commerce platforms emerging it will get harder to determine whether a platform is a monolith and positioned for helping you grow. To identify whether a commerce platform is monolithic and disguised as modular, modern, API-first, composable, or any of the other buzzwords, ask the following questions:
- Does the platform let you configure your business variables outside of code?
- Can services inside the platform function and be deployed independently?
- How easy is it to integrate these services with outside platforms or services?
- How easy is it to customize your data and business rules?
- Are you able to configure your own data stores or are you tied in with what is provided?
- How easy is it to change a frontend concern without interrupting the backend?
- How easy is it to extend your functionality for different use cases across industries or domains?
If you are a mid-market or enterprise business, the answer to all of these should be Yes or Easy. If there are unclear answers to these questions, tread lightly. While the platform may serve your immediate needs you’ll run into trouble down the road.
Scaling with Microservices
A monolithic commerce platform like Shopify Plus might have been a good starting point for the sake of simplicity. But to evolve commerce you need more flexibility, security, and speed. This is what a service-oriented architecture offers.
The good news is that you don’t need to build all your microservices in-house like Amazon did and like we did at Staples. While building your differentiating services in-house is a good idea, you can use core commerce services and APIs from fabric that enable growth through a service-oriented architecture.
Our service-oriented platform
The different parts of fabric include:
- Experience platform: fabric XM lets you continue using your monolith or break down your monolith while taking control of frontend shopping experiences across channels. A headless CMS makes this possible. Any service with an API can communicate with the headless CMS.
- Headless commerce platform: fabric commerce APIs make up the commerce platform. But unlike traditional platforms, you can select the APIs and services you want to use. Each API is connected to a service (payments, pricing, promos, subscriptions, cart, etc) and each service is self-contained yet extensible.
- Co-Pilot applications: Applications with user interfaces let business users access the same datastores and functionality as developers do with APIs.
Even with these cloud-native services and APIs, moving from a monolith may still seem daunting. But there’s even more good news: you can make changes to your existing commerce architecture in small increments. This is what we refer to as The End of Replatforming at fabric and we can support you in this initiative as well.
Board of Directors @ fabric. Previously @ Google, Amazon, Staples, eBay, and Groupon.
