We recently sat down for a chat with Bill Curtis, a co-founder and the CTO of Sweet Tooth (Now Smile.io), a points and rewards app for online stores worldwide.
What has been your greatest challenge?
We’re serving way more data today than we ever have, so scaling is mission-critical. In the past, we’ve struggled with traffic spikes. For example, there are seasonal spikes, like Black Friday or Cyber Monday. There are also spikes from merchant activity, such as load testing stores or importing a large number of orders.
I recently tweeted our requests-per-hour graph. It showed that during the huge spikes for this year’s Black Friday and Cyber Monday, our product availability was seamless on Heroku. That would not have been the case on our old infrastructure.
We've been serving 150k requests / hour since 11am this cyber monday. @heroku dynos ain't even sweating 💪💪💪 pic.twitter.com/rvhYQESqWm
— Bill Curtis (@billcurtis_) November 30, 2015
How do you manage those high traffic days?
We use Librato, which is a really nice minute-by-minute analytics/metrics system, to monitor the load on our servers. We also have alerts connected to our Slack channel. This will get hit if there are certain fluctuations, such as too many errors in a certain time period or an increase in our queues. With Heroku, all we need to do is go in and crank up some dynos so there are no bottlenecks.
Walk us through your stack
We’re running Rails on the server, which powers our API. There’s no view level logic in our Rails app; it’s just serving JSON through REST API endpoints. We have a front-end app written in Ember.js that serves static content and allows merchants to manage their points program. Then the app boots and hits the API to grab the merchant and customers data.
Heroku Postgres is our database, which has been a hugely positive change for us. We moved from MySQL to Heroku Postgres, and the difference has been night and day. It would be worth switching to Heroku just for their Postgres offering! It’s awesome. Postgres is a much more modern database with better data types than we had before. We especially love its automatic backups. Although we haven’t used its forking and following features that much yet, as soon as we scale to multiple testing environments, it will be super useful.
We also have about 15 or so different background workers that are crunching data every day and running stuff in the background. Heroku makes it super easy to get those set up and know which ones are running.
Why Ruby?
We used to be a PHP shop through and through. We switched to Rails two years ago, and a few members on the team had some experience with it. For us, Rails felt like a much more mature platform. It provided a very nice package to build an API that serves multiple clients.
Does your stack include any other Heroku Add-Ons beside Librato and Heroku Postgres?
We’ve integrated lots of Heroku Add-ons, including Deploy Hooks, Rollbar, Heroku Redis, and SSL encryption. Rollbar’s error tracking is great—in one click you can have it running in a new environment. It also lets you create multiple accounts for each of your apps, which makes managing passwords simple.
We use Heroku Redis for caching and queuing. Sidekiq uses Redis for memory queuing storage, which is how we calculate metrics for our merchants or how we process different events or points in the background. I’ve used the other Redis add-ons, but I trust the Heroku team and brand, and if they put their resources behind a specific product, then I’m going to chose that one.
What does your continuous delivery pipeline look like on Heroku?
With Heroku, our staging and production are in high parity. It’s something we missed in our prior infrastructure solutions. Staging environments are expensive to run. Heroku allows us to have almost the same environment but scaled down. It gives us confidence that we can catch any bugs or differences before they go out to production.
Why did you move from infrastructure and operations as a service to PaaS?
We had experience creating software that deployed on other systems, so we never had to do any operations stuff. We never had to manage servers except for our website. All of a sudden we found ourselves with a SaaS company, so naturally operations became a much bigger deal.
We first turned to AWS and their suite of products, only to realize that it’s a very raw infrastructure, and you have to know what you’re doing to make that work. Then, we hired an operations-as-a-service company to manage our infrastructure.
As we became more mature as a company, we started deploying more often and realized that our operations needs had changed. Our team needed more visibility into how our apps were running and more fine-tuned control, which wasn’t possible through the external company. It got to the point where we had a wish list of about ten things we wanted built into our operations, and adding them up together would put us in a much better place.
Heroku offered us the ease and control we were looking for to take our product to the next level. We liked how Heroku empowers developers to manage and scale apps without needing to know every sort of server configuration. With all the Heroku Add-ons, in one click we could have an error reporting or logging system, deploy web hooks, integrate with GitHub, or tail logs from the command line. It also scales very affordably. Heroku made total sense for Sweet Tooth.
Any final thoughts?
Ultimately, Heroku has helped us better grow the product and focus on our purpose at Sweet Tooth, which is to help merchants. The more we can do that, and not focus on technical overhead, the happier we can make our customers.
Thank’s for your time, Bill!
Thank you!
Read our Smile.io Customer Story to learn more.