Technology Enhancements

We’ve introduced several changes into our cloud infrastructure as we prepare for a push to grow to 10K users and beyond.  Some of these changes were implemented to gain scaleability, others used to improve user experience.  After years of technology consulting it’s fun to take my own advice!

1. Our front end (Web and Mobile) applications have always leveraged a scale out model using AWS Elastic Load Balancing (ELB) across multiple nodes.  This is the first area we had to add scale to once we moved to Strava and Garmin Push interfaces given they drive several thousand hits to our website and api each day.
   

   ---

2. We moved our RDBMS (yes we’re old school) to Amazon Relational Database Service (RDS) last summer when we realized how much simpler it made managing a high availability database.  We have 100GB database that holds your performance data.
   

   ---

3. We moved our batch processing to a scale out model this month by leveraging Amazon’s Simple Queue Service (SQS).  This has enabled us to now run multiple machines to process your Strava Activities, Garmin Files and New User Conversions.  Now we can test changes on one node before turning it on for everyone and add/remove nodes based on volume.
   

   ---

4. We moved our sending of Push Notifications and Emails to Amazon Simple Notification Service (SNS) and Simple Email Service (SES).  We moved to SNS in December 2017 to eliminate a problem that hung our batch process intermittently when sending Push Notifications to mobile users.  We moved to SES this week to begin to handle bounced emails and maintain a blacklist.
   

   ---

5. We’ve been using Amazon Simple Cloud Storage (S3) to store map images and now we’ve added a bucket for your Garmin files.  We did this change to control costs as storing this unstructured data in our DB was causing our highest cost resource to grow way too fast.
   

   ---

6. We’ve added custom metrics to Amazon Cloud Watch in anticipation of leveraging their Auto Scale Groups to dynamically add front end and batch processing nodes real time based on key metrics (e.g. Strava Queue Depth).  Right now we get an alarm if the strava sync queue goes above 75 athletes.
   

   ---

7. Our plan is to consider leveraging Amazon Elastic Container Service in the near future in hopes of simplifying our move to Auto Scaling Groups.  We may also evaluate Amazon’s Data Science tools once our scale moved past 10K user base and we start to evaluate algorithms that learn from all of our data as opposed to our per athlete, per segment models today.

We’ve been leveraging Sentry.io for our error / crash management across all of our solutions.  We use this to get notified when bad things happen!  We’re leveraging their iOS and Python bindings.  Their iOS is pretty raw but the Python integration is fantastic.

We’re in the process of evaluating Microsoft Azure services for data exploration and analysis.  They have some fantastic tools for exploring datasets, training algorithms and tuning hyper parameters.  Click on the image above to watch a nice demonstration of their interactive exploration tools.  Much better than Python Notebooks!  The idea is to explore, test and tune new algorithms here before putting them into our application.