The problem with traditional hosting solutions for WooCommerce
When I started Woogo Store, the whole premise of the service was to offer incredible customer support to people wanting to own their e-commerce stores. I realized many problems stemmed from the fact that understanding and customizing an e-store is more complicated than it seems. I’ve seen many customers dissatisfied with their e-store solution but felt stuck with Shopify or their existing WooCommerce provider because they thought they didn’t have the tens of thousands of dollars to spend for an agency to deal with their requests.
One big problem of traditional WooCommerce hosting is that a server has a fixed capacity and can handle X number of requests depending on your plan and, of course, how much you pay. It makes no sense to pay $1000/m for a server if you’re going to use 1% of its capacity 99.99% of the time. This inefficiency leads to having servers that are smaller but can’t handle peak loads.
For example, a promotional newsletter goes out with a discount coupon, everybody clicks on it, and the server crumbles under load. It’s incredibly frustrating for customers and business owners alike Not only what should have been a great sales day becomes an IT nightmare, but on top of that it leaves a sour taste to customers. Capacity can be added, but it’s reactive, and it takes some time.
What’s really needed is the ability to instantly scale to the number of users, from 10 visitors to 10000 visitors, if needed.
Woogo Stores First Solution: Docker Swarm
I spent the better part of 2020 and 2021 engineering a solution around Docker Swarm. ( Actually went through K8S, Consul, and Swarm). It sank a lot of effort to get to an acceptable solution, but then again, scaling wasn’t instant. It could take a few minutes to react to the amount of load. The solution relied on a LOT of scripting, a lot of servers I needed to maintain, and a bunch of skills that, frankly, I only superficially had. For the solo-self-funded company that I am, I realized I was way too deep trying to maintain a tech stack VS actually focusing on developing my business.
Meanwhile, my good friend Carl was making progress on Ymir.
Ymir to the rescue with AWS serverless
Realizing I was losing way too many hours (days!) on this, I decided to check out Ymir in practice. As pointed out by Carl, I thought that serverless was the answer to the considerable variability in traffic for e-commerce. If AWS Lamba managed by Ymir could save me so much aggravation with infrastructure management, it’d be a win.
I wish I could say it was a complete slam dunk, but alas, like it wasn’t, as it often is in real life! At one point, both Carl and I thought the project would never work because everything was too slow. We realized no one actually ever scaled WooCommerce horizontally, or they would have hit the same problems as we did. It was terrible news for both of us, especially Carl, who started to doubt if his business could even make sense for WooCommerce.
Thankfully the bugs were squash, performance went up to on-par with regular servers and if not better in some cases. Huge thanks to Till Krüss as well for his support and making Relay (check it out!) and we were able to make it work! In fact, you’re reading this from AWS lambda response!
The future with Ymir
Ymir allows Woogo Stores to deploy with premade docker images, which is a huge win to maintain the same environment between all clients. Updates are easier to manage, and thankfully all the work poured into Docker Swarm isn’t completely lost. I’ve started migrating customers over to Ymir without them noticing any change, which is exactly what we want for our clients: a completely seamless experience.
Ymir will be an integral part of the future of Woogo Stores, and I’m super thrilled to be pushing the envelope of WooCommerce hosting with my good friend Carl.