Beware False Commerce Clouds

For the past decade, cloud has promised to revolutionize how organizations consume software. Investments in on premises software and the vendors that produce that software has completely dried up. The future and increasingly the present of commerce is clearly cloud. An astounding 88% of U.S.-based internet retailers are currently or will be re-platforming within the next two years, according to some fascinating research by Internet Retailer.

But just what is the “cloud” in many of the “Cloud Commerce” offerings? In the past few years, cloud has been redefined to encompass just about everything that we’ve done for years. Email is now even considered cloud by many. It’s simply ridiculous how far “cloudwashing” has gotten out of hand. No wonder then that many are confused by all of these new “Cloud Commerce” offerings on the market. They are not created equal.

Let’s start by defining cloud (courtesy of the National Institute of Standards and Technology) and mapping that back to commerce functionality.

How Do Cloud Principles Map to Commerce?

Broad Network Access

The most defining characteristic of cloud is the availability of resources (infrastructure or software) as a service over a network. As a consumer of the resource, you don’t care how that resource is made available. If you’re consuming an API, for example, you just need a URL that you can access. Behind that URL could be just about anything – there could be MS DOS scripts generating responses for all you know or care. What matters is that the resource is broadly available over a network.

Public cloud vendors like Microsoft, Google and Amazon have long made dozens and today, hundreds of discrete “building blocks” available as individually consumable services over the network. These services include functionality ranging from datatores, to machine learning, to distributed consensus. Their goal is to offer you a large toolbox of services that you can incorporate into your application.

We’re seeing the same trend in commerce, where discrete functionality (search, discounts, inventory, pricing, etc) is exposed to developers as discretely consumable APIs. Exposing an administrative console for business users doesn’t count. The more functionality that can be leveraged a la carte over APIs, the more inline the commerce platform is with this centrally defining characteristic of cloud.

These are the three questions you can ask your cloud commerce vendor to see how compliant their solution is with the broad network access mandate of cloud:

1. Is the commerce functionality accessible over a URL or other form of API? Or do you have to download some software and run it yourself?
2. Do you just get administrative console for business users or do you get access to discrete functionality, like the public cloud vendors offer?
3. Is the functionality offered in discrete, individually consumable pieces or do you have to use the entire application?

Rapid Elasticity

Elasticity refers to the ability to consume as much of a resource as you’d like, as quickly as you’d like. If you want (and have a valid credit card), you should be able to scale up from 10 virtual machines to 1,000 in just a few seconds. This is in stark contrast to the legacy on premises model of pre-provisioning infrastructure and software for peaks. Elasticity offers enormous cost savings by avoiding the need to pre-provision environments for traffic that may or may not come.

Many deploying legacy commerce platforms simply guess at what their peaks will be and then multiply that by five in order to size their production environments. Multiply that by two or three for redundant data centers in case of outages. Hardware is statically deployed, sitting idle except for the few hours of the year where it spikes up to 20% utilization in just one data center. That’s all before pre-production environments which can easily number into the dozens.

In my 2014 book, eCommerce in the Cloud, I found that most enterprise-scale on premises commerce deployments average 1% utilization. 

Cloud completely solves this by nearly perfectly matching the amount of resources requested with the amount of resources provisioned.

The more advanced commerce solutions don’t force you to provision anything. You simply consume the functionality through a URL and the provider of the resource manages auto-scaling for you behind the scenes. You just get a URL with an infinite amount of capacity behind it.

These are the two questions you can ask your cloud commerce vendor to see how compliant their solution is with the rapid elasticity mandate of cloud:

1. Can you consume as much as you want, whenever you want? For example, can you advertise a website or app during a Super Bowl and not tell your cloud commerce vendor?
2. Do you have to provision infrastructure or tell your cloud commerce vendor to provision infrastructure on your behalf?

Self-service

Consumers of cloud services expect to be able to interface with the services directly, without having to talk to someone. All of the large public cloud providers work this way – simply show up with a credit card and you can have instant access to all of the cloud services.

In the commerce space, this means that you should be able to provision yourself a demo account, interact with APIs and business user consoles, build and deploy a proof of concept, and even launch to production without notifying your vendor. Most important, you should be able to load test and have special events (Super Bowl commercials, etc) without having to notify your vendor. Again – you should just be dealing with a URL. It’s up to the vendor to scale the infrastructure and software behind the scenes to meet the quality of service you’ve agreed to. Public cloud vendors could care less about your launches in the same way that your utility company doesn’t care if you have a party at your house and use 5x the electricity you normally do. Your commerce cloud vendors should have the same attitude.

These are the two questions you can ask your cloud commerce vendor to see how compliant their solution is with the self-service mandate of cloud:

1. Can you provision yourself a demo account, interact with APIs and business user consoles, build and deploy a proof of concept, and even launch to production without notifying your cloud commerce vendor?
2. Can you load test and have special events (Super Bowl commercials) without having to notify your vendor?

Metering

Metering is the financial part of cloud and is why cloud computing is often called utility computing. Like electricity or water, you pay only for what you use. The same should apply to resources, whether hardware or software. Metering is completely revolutionary to organizations, as it allows expenses to be shifted from capital expenditures to operational expenditures while dramatically reducing IT spend. For example - if you use 1 core, you should only pay for one core – not the other 32 cores on the same machine.

Commerce also benefits greatly through the use of metering, allowing costs to be incurred as business value is realized. If your company buys a week-long advertising blitz, you should just pay for the incremental traffic, not the hugely capital intensive costs of adding more physical capacity to data centers which will go unused the remaining 51 weeks out of the year. Outside of infrastructure, organizations shouldn’t be forced into multi-year, multi-million dollar purchases of enterprise software to support spikes.

These is the simple question you can ask your cloud commerce vendor to see how compliant their solution is with the metering mandate of cloud:

1. Do you pay only for the resources you use?

What Are the Commerce-specific Questions to Ask?

In addition to the four more basic cloud questions, there are three additional criteria to evaluate your cloud commerce vendors against: customizability, granularity and tenancy.

Customizability

At the low-end of the commerce market, organizations want a website and mobile app in a box. They want to spend $50 or $100/month and have a drag & drop experience, with no coding and limited customizations. They want to load in their data, customize the UI, and get going in a week or two.

At the high-end of the commerce market, organizations want complete control over their platform because the platform is at the core of their business.

They want to build parts of their platform from scratch. They want to heavily customize packaged solutions that they buy, whether cloud or on premises models.

What is the customization model? Are the customizations limited to data and configuration changes only, as is common down-market? Can you add modules? Can you download some binaries from your vendor, wrap them in your application and then deploy the libraries and your customizations to a public cloud? Or do you extend your cloud commerce vendors’ APIs using an SDK or similar? Where do you deploy your customizations?

To summarize, here are three questions to ask your cloud commerce vendor to find out where their solution sits on the customizability spectrum:

1. Is the solution meant to be used off the shelf as an entire solution, or is it meant to be a starting point for further customization?
2. Are changes limited to data and configuration, modules, or are you allowed to customize more extensively through the use of custom code?
3. Is the solution meant to power your business (as an omnichannel solution) or is it meant to serve a specific channel, like a website or an app?

Granularity

Closely related to the customizability question, how granular is the business functionality you can consume? For example, can you just buy pricing and promotions as individual pieces of functionality, in the same way that you can buy load balancing and DNS as discrete services from public cloud vendors?

Many commerce solutions are monolithic by their very definition. I’ve written extensively on why monolithic commerce applications are difficult to build and deploy, especially at scale. In the world of cloud, those issues are largely the providence of the vendor to deal with, but monolithic applications do require ownership of all commerce data, including orders, customers, products, etc. Because of the inner complexity of these applications, pieces cannot be consumed independently, which makes it hard to support a model where you build some functionality (say customers and orders) but you want to get other functionality from a cloud commerce vendor (say product catalog and search).

Aside from offering more flexibility, the ability to purchase granular bits of functionality can offer substantial cost savings. If you’re just buying a product catalog and search, for example, your costs would be small fraction than if you had to buy 100% of your required functionality from a vendor.

To summarize, here are two questions to ask your cloud commerce vendor to find out where their solution sits on the granularity spectrum:

1. Can you use individual pieces of functionality (search, discounts, inventory, pricing, etc) or do you have to use the entire stack?
2. Do you pay just for the pieces you use or do you have to pay for the entire stack?

Tenancy

Finally, there’s the question of tenancy. Tenancy refers to whether the provider of the resource supports multiple customers using the same underlying software and infrastructure.

Commerce used to be single-tenant by definition. An organization would buy infrastructure and run it in a data center they controlled or had a relationship with. Nobody else’s commerce traffic would pass through it.

Cloud changed this prescience entirely. Running multiple tenants on the same physical infrastructure and software instances is what makes public cloud and software-as-a-services business work. Over-subscription not only saves money in infrastructure costs, but it also reduces ongoing operational expenses for the vendor. Rather than supporting 1 million individual deployments of AWS’s Elastic Load Balancer, they can run one large multi-tenanted implementation of it for their 1 million customers. It’s easier for the vendor and it’s easier for the consumer because they always have the most up-to-date functionality and don’t have to deal with upgrades. Public cloud and SaaS vendors continually push new functionality on a regular basis.

Cloud Commerce vendors have the same issue – do you run one large environment with all of your customers or do you have isolated environments (including infrastructure) for each customer? Security used to be the obvious concern with multi-tenancy, but public cloud has proven that multi-tenancy works and can be even more secure than single-tenancy. Not a single customer can bully public cloud vendors, for example, into giving them their own single tenancy. Their whole business model would fall apart. And again, it’s just not necessary. Public cloud proves that multi-tenancy works well.

To summarize, here are three questions to ask your cloud commerce vendor to find out whether their solution is single or multi-tenant:

1. Do running instances of your platform serve traffic for more than one customer?
2. Does the infrastructure on which your platform run serve traffic for more than one public cloud tenant?
3. Do your data stores store and process data from more than one customer?

Summary

We at commercetools have a market leading cloud commerce offering that easily meets all seven of the above criteria. Have a look if you're interested in learning more.

In my next blog post, I'll build a taxonomy of the different commerce cloud solutions. Follow me or commercetools to get the next installment of this two-part post.