Please note, this is a personal opinion piece.

Serverless computing offers multiple appealing benefits:

• You only pay for the compute you use, which is appealing to both small (low budget) and large (cost efficient) merchants
• It takes away much of the pain of autoscaling and high availability
• Developers can focus more on business logic, less on infrastructure and scaling

So when do I think we will start to see successful open source e-commerce platforms emerging on serverless architectures?

Well, one answer is you can use existing platforms in a simple serverless way today. For example, load your PHP application onto Google App Engine and run it there. It is basically running a monolithic application that is horizontally scaled for you.

But if you want performance benefits from background processing, then greater architectural changes will be required required. For example, if an order is placed, do you have to decide which warehouse the order is going to be shipped from before responding to the user placing an order? Or can you just reserve the stock and let another background engine make that decision later? Serverless architectures can simplify the process to break large code bases into smaller independent sections of code, where each section of code can scale automatically with demand.

For example, if once a year you apply a bulk 25% discount to every product in your catalog, if you have a single machine making the changes this can become the bottleneck. If the job can be accelerated by spinning up multiple servers to make the change (that is, assuming the database is not the bottleneck), serverless programming can make the auto-scaling here frictionless meaning you don’t have to spin up special hardware just for the occasional event, and you don’t have to pay for resources the rest of the year.

But I am personally not expecting a new serverless e-commerce platform emerging in the short term. (Well, not a successful one.) Why not?

• A new platform needs an ecosystem to be successful – they just take time to emerge.
• Small businesses may benefit from not paying for CPU when not being used, but the increased operational overheads for managing a site can outweigh the hardware cost benefits.
• Large businesses may benefit more from cost efficient auto-scaling, but need to be careful as serverless platforms may charge higher rates – if their load is stable, serverless may cost more than the savings.
• To get the most of out serverless you really want good integrations with technologies like durable queues for message passing between serverless functions, and database event triggers – which for now means the processing is still somewhat tied to a particular cloud vendor. Vendor tie in is less appealing for open source projects. (I am sure this will improve over time.)
• Having multiple smaller cloud functions increases the number of moving parts, making installation and upgrades more complicated. Tooling will improve here over time, but it is an issue for now.
• You still have to worry about caching for performance. Serverless has issues such as cold start delays and how to cache data in memory between requests.

In summary, operational overheads for serverless architectures (with multiple functions) are higher than LAMP because of the number of moving parts. PHP running on a web server with MySQL behind it is still easier to manage. That means its more relevant to larger organizations, less for small merchants to run themselves.

So how to overcome these problems?

• It will get easier as tooling improves for deployment and upgrade of graphs of cloud functions. Merchants love one click installs and upgrades.
• It may be that the best approach is for existing platforms to also be able to be run on a serverless backend, and then separate out functionality over time. That is, don’t develop a new platform but rather refactor an existing platform.

Wrapping up, I do believe that serverless e-commerce platforms will emerge, but while they solve some operational problems around scale, they introduce other operational overheads due to the increased number of distributed components. The end result is it is not yet clear there is an automatic win.

What I personally would like to see is more standardization around interoperability of individual services. That is, separation of the cart from order management and inventory management. This may be a pipe dream due to lack of standardization, but it allows sites to pick and choose frontend and backend services with features appropriate to their needs. (You see some of this with projects such as VueStorefront.io, which implements a shopping experience storefront without backend logic.)

The other area of development that will help in this area is the ongoing improvements around standardization of deployments, monitoring, and logging. Once such tools are better standardized, you will be able to build a code base as a series of functions and not have to worry so much about deployment strategies which are still the responsibility of whoever is installing the application. (If you have an architecture with 10+ cooperating serverless functions there is more you need to worry about in terms of coordination and sequencing for upgrades – as well as testing thereof.)

What appeals about serverless programming to me personally? It is the ability to decompose a large code base into smaller units of functionality with guaranteed boundaries between them. You can then reason about a system more easily. You can upgrade parts of a system more easily. You can scale a system more easily. But these points to me are not compelling arguments for most customers of a platform – they are more compelling for the developers of a platform. Solving the customer painpoints for serverless programming I think is the precursor before open source serverless commerce platforms will become mainstream.