One of the biggest reasons Magento stores prefer cloud-based hosting is the idea that the store can easily scale up during periods of heavy traffic, such as Cyber Monday or during a flash sale. Ideally, this scaling capability should perform automatically based on server load, without human intervention.
As we discovered during our research into building Webscale STRATUS, auto-scaling Magento is not simply increasing server resources, adding extra RAM and CPUs. Either would not necessarily be automatic.
To successfully scale Magento, it takes separating the various services into container pods, then selectively configuring those that deserve replicating onto additional servers and those that don’t or cannot replicate automatically.
It took Webscale over two years of intense, expensive R&D to create a fully automatic, scaling solution for both Magento 1 and Magento 2.
Auto-Scaling Defined
First, let’s decide what we mean by “auto-scaling.” For some in our industry, this means that the store owner may still be required to request the setting aside of additional resources based on a planned uptick in traffic. Then, the hosting provider will provision the resources and configure the system to take on the additional servers based either on some threshold of traffic or resources used and replicate the Magento installation onto the additional servers. Sometimes, this can result in momentary downtime, which, I feel, runs counter to the purpose of “auto-scaling.” After all, for a store owner who wishes to keep up with rising demand, having downtime in the midst of the traffic surge could be crippling to their brand.
For us, auto-scaling means that 1) the store merchant does not have to plan ahead in terms of needed resources, timing, or anything other than to simply indicate that, “yes,” they want auto-scaling capability; and 2) that the amount of additional resources employed should not be charged in addition to the client’s plan, as long as their hosting is priced on a resource-based plan. At Webscale, we charge based on the number of user sessions, regardless of how many resources are used to deliver the traffic. We also do not charge extra for “auto-scaling setup” or other configurations.
The Secret Sauce
Now, for anyone who is interested in creating their own cloud-based, auto-scaling configuration, the “secret sauce,” so to speak, is that the primary container that is replicated is the PHP-FPM service. Occasionally, we will configure a MySQL container to replicate, but that is only on the heaviest-trafficked sites.
When Magento is getting pounded by increased traffic, it is the PHP-FPM that begins slowing down. As long as your static content is being served by a fast CDN and all other services are contained in their own pods (e.g. Elasticsearch, Redis, etc.), then replicating PHP-FPM is pretty straightforward.
Now, please note that I didn’t say “easy” or “simple.” Although we found the secret sauce to auto-scaling, it still requires a tremendous amount of engineering to not only replicate the necessary containers without interrupting the storefront activity, but we do have to accommodate code updates, as well. We can’t simply ask all merchants who engage auto-scaling to simply give up any and all code changes.
One additional benefit to how we segregate the services in Webscale STRATUS is that the individual services run much faster and with fewer conflicts. And if one crashes or the merchant/developer mis-configures a setting, it doesn’t bring down the entire store hosting environment.
Someone recently asked me why I would disclose our “secret sauce.” Well, I suppose it’s confidence in our engineering team and the fact that during 2020, as e-commerce buying accelerated, all our merchant stores that were engaging Auto-Scaling did not suffer one minute of downtime or slow-down. Not one.
And that’s a record I know no one else in this industry can match.
