Building an Upload Microservice using AWS Lambda

One of Bodybuilding.com’s core missions is to help people transform their lives through the adoption of a healthy lifestyle and exercise. One way we motivate people to begin such a journey is through our yearly “transformation challenge.” Over the course of 12 weeks, participants in the challenge are encouraged to adopt a training plan and set new habits that will lead to a fitter, healthier body. Prizes are awarded to the people who make the most profound transformation over the course of the contest. 

In order to participate, contestants are required to upload photos of themselves before and after the challenge. As one might imagine, the time period shortly before and shortly after each challenge tends to produce a spike in photo-upload traffic to our servers. Historically, these periods have been problematic for the scalability of our backend systems. In order to improve our end-user experience (not to mention our own), we decided to re-architect our photo-upload system in late 2015.

This tech talk describes how we created a new microservice-based architecture using Amazon Web Services technologies as well as a Java/Spring stack. Our goal was to greatly improve our ability to handle spikes in image-upload traffic without manual intervention. As a result, we created autoscaling RESTful services using Spring Boot and AWS Elastic Beanstalk. Image-processing logic has been encapsulated into highly scalable Amazon Lambda functions.

We recently launched the 2016 transformation challenge. With our new image-upload infrastructure in place, we have been able to handle peak loads without a hitch.

Read More

Video: What is RESTful? (2.0.0)

Roughly two years ago, the Bodybuilding.com Commerce Engineering Team set out to deliver native mobile phone applications for iOS and Android that offered the same rich user experience that hundreds of thousands of customers enjoy within our web applications each day. We started with a couple of UI/UX mockups, a firm knowledge that we needed to develop an API, and a strong desire to make that API RESTful. A large, dedicated team spent 18 months of their lives learning and growing to achieve a soft launch of the applications in May of 2015 in the Google Play Store and iTunes. We believe a project of such magnitude must, beyond its primary goals, create useful and reusable assets to be considered a success. By that definition, this project was a huge success. We have a few libraries we plan to open source, a bunch of best practices to document and present, and a ton of knowledge and opinions to share with the development community.

Other than the applications themselves, the most valuable assets developed during the project have been our opinions on what defines a RESTful architecture. Even months into the project, we found ourselves in long debates that led to redefining our views of RESTful architecture. Each of these cycles triggered new breakthroughs and pitfalls in our implementation. Even now, months after the launch, we still find ourselves re-evaluating past decisions and making significant changes in our implementation to align with the newest visions. The pieces of that newest vision were collected together into a presentation named "What Is RESTful?" that was used multiple times internally to achieve a common base understanding from which the more interesting conversations around implementation grew. Even this presentation has gone under multiple revisions and has recently achieved the SemVer status of 2.0.0. This 2.0.0 version was recently presented at the Bodybuilding.com Fall 2015 Tech Talk and is now available for online viewing. We expect to use this presentation in future posts and presentations as a launching point to dive deep into the finer aspects of our implementation and the software technology that grew from our vision. It is certain that we have not gotten everything right, and we encourage feedback, both constructive and critical, in order to develop the 3.0.0 version of this vision.

Read More

Introducing Argos Dashboard

If you've seen our previous posts or tech talks, you know that we are huge fans of Hystrix, the resiliency library by Netflix. The Hystrix dashboard has been great for monitoring a single application or service, but as the number of applications and microservices increased, we found ourselves needing a more holistic view of our infrastructure. We currently trend all our Hystrix metrics into Graphite for correlation and forecasting, but we really needed something concise and real-time. Inspired by the usefulness of the Hystrix dashboard, we have created Argos Dashboard.

Argos Dashboard provides a real-time view of multiple Hystrix clusters by aggregating data for each cluster onto a single dashboard. The new dashboard has been extremely useful for monitoring how requests flow through the dependencies of each application. It also helps easily monitor what happens when we do performance and resiliency testing. Today, we are releasing Argos Dashboard on GitHub at http://www.github.com/bbcom/argos-dashboard. We hope you find Argos Dashboard valuable and look forward to feedback and pull requests.

Read More

Improving Fault and Latency Tolerance with Hystrix

The API for Bodybuilding.com serves more than a hundred million API calls everyday across hundreds of servers. In this video you will learn how we use Hystrix to build a distributed system that is both fault and latency tolerant. We will discuss the bulkhead and circuit breaker patterns used by Hystrix to provide a resilient and fast API.

Read More