Egraphs Uses CloudBees Platform to Connect Sports Fans and Stars
For sports fans, an egraph is a unique opportunity to capture a shared moment between them and their favorite star. An egraph is an authenticated personalized voice message and written note from the star to the fan that can be shared with the world. To create an egraph, a fan begins at egraphs.com by writing a message to a sports hero. The star then uses the Egraphs iPad app to create a unique written and audio message, personalized based on the fan’s request. The fan—and their friends—can view the egraph online or have it printed and framed for display.
Egraphs developers built the web application that enables this process using Scala and the Play framework. They deployed it using CloudBees RUN@cloud™ deployment services to take advantage of the scalability, dependability and openness of the CloudBees Platform as a Service (PaaS) solution and its partner ecosystem. “The core functionality necessary to run a web-based business is provided to us by RUN@cloud,” says Erem Boto, Egraphs co-founder. “And the benefits available with a single click from the CloudBees ecosystem of integrated services are astonishing.” Co-founder William Chan adds, “RUN@cloud represents the entire production infrastructure that we would otherwise have had to build piece by piece ourselves to achieve the level of scalability, productivity, reliability and ease-of deployment we need.”
Meet an Aggressive Launch Date While Preparing for Unpredictable Demand
For its initial offering, Egraphs focused on professional baseball players as their first set of stars. A successful launch depended on having Egraphs.com fully ready at least two months before the end of the baseball season. “From the day we wrote our first line of code, we had fewer than nine months to our target launch date. If we missed that date by even a few weeks we would not receive the momentum we needed from the baseball playoffs,” says Chan. In fact, a private version of the software had to be deployed and stable well before that so the company could begin signing up stars and demonstrating to partners. Productivity, therefore, was a top priority and factored heavily in the decision to use Scala, the Play framework and a no-hassle deployment platform that supported both.
For Egraphs, setting up and running their own deployment infrastructure was not feasible because of the high up-front costs and the ongoing maintenance that would be required. Difficulty in accurately estimating customer demand and the anticipation of spikes in traffic also led Egraphs to seek a scalable, cloud-based solution. “We expected our traffic to come in bursts, and our application needed to be able to handle the load when the league sent out announcements for egraphs.com to people on its ten-million member email list,” says Boto.
Lastly, Egraphs was looking for an open solution that would enable them to deploy privately in preparation for a widespread public launch. “We wanted to avoid vendor lock-in that comes with proprietary APIs for persistence, caching and other functionality,” Boto adds.
Meet Pre-launch, Launch and Post-Launch Needs
Egraphs accelerated and streamlined the development and deployment of its egraphs.com back end with the CloudBees Platform. After struggling to get their application deployed on another cloud PaaS solution for almost a week, Egraphs developers tried RUN@cloud and had it deployed within the hour. “Our application relies on the Scala runtime and the Play framework, and the first option we tried did not work well with those technologies and the large application slug we had. We threw our WAR at RUN@cloud, and it just worked,” says Boto.
Working with the Play framework and RUN@cloud, Egraphs adopted a workflow that enabled rapid progress while reducing coding errors. “We would write code and refresh the browser, which would trigger a compile. Scala’s compiler eliminates whole classes of errors from our codebase, and furthermore being able to use this change-reload workflow was an important advantage for us,” Chan explains.
Throughout development, the team used multiple application instances—including one for demonstrations, one for internal testing, and another slated for launch—all with the RUN@cloud security mode set to private. Prospective partners and stars could access the application via a login ID and password, but it was otherwise inaccessible to the public. When Egraphs was ready for launch, the team simply set the launch instance’s mode to public with a click, and the site was live.
Following the launch, Egraphs worked with CloudBees engineers to improve performance during traffic spikes. The developers also used an application performance monitoring tool from New Relic, a CloudBees Ecosystem Partner, to identify performance bottlenecks in running virtual machines.
To inspect log files and track down issues, the development team initially used commands from the CloudBees SDK to tail logs. After the site went live, the team switched to the Papertrail log management solution, also available via the CloudBees ecosystem, which enabled them to better manage the increased volume of messages being logged.
After launching with version 1.0 of the Play framework, Egraphs wanted to upgrade to Play 2.0 to take advantage of its improved performance, reliability, Scala support and compile times. Egraphs developers used the CloudBees open source plugin for Play 2 to better integrate deployment with their build system.
The developers made a change to the plugin that enabled them to specify which CloudBees application a configuration should be deployed to by default. This change has since been included in the plugin release version.
“Our setup will now build the entire application, run all the tests and deploy the app to RUN@cloud with the correct configuration and with all of the right bread crumbs so we know exactly what we’re dealing with, if we identify an issue. Support for Play 2 has really been phenomenal in all aspects of development,” says Boto.
Egraphs currently has plans to offer higher-bandwidth connections between fans and stars and is preparing to add stars from other sports, including those with a worldwide audience. For example, Egraphs has since launched professional basketball stars. “With CloudBees, we are well-positioned to expand our offering in several directions using the same underlying infrastructure,” says Chan.
- Initial deployment completed in an hour. “We worked with support personnel from another PaaS provider for the better part of a week, but their platform could not handle our app,” says Boto. “We were up and running with RUN@cloud in an hour, which was vital because it enabled us to meet a deadline for demonstrating a private version of our app to partners and stars in advance of the public launch.”
- Launched on time in less than nine months. “We hit our launch date in just eight-and-a-half months because of the decision we made to use RUN@cloud,” says Chan. “If we had tried to build our own infrastructure or even set up and manage an Infrastructure as a Service solution we would have missed our target by at least a month, and missed a great opportunity in our first market.”
- Post-launch tasks streamlined with CloudBees Ecosystem Partner offerings. “We’re already using New Relic and Papertrail to track down performance bottlenecks and “heisenbugs”—particularly hard-to-find bugs,” says Chan. “Those services along with other CloudBees ecosystem services are going to be increasingly valuable to us as we continue to grow.”