“With traditional IT, it would take weeks or months to contend with hardware lead times to add more capacity. Using AWS, we can look at user metrics weekly or daily and react with new capacity in 30 seconds.” Richard Crowley Director of Operations
AWS Case Study: Slack
Slack provides a messaging platform that integrates with and unifies a wide range of communications services such as Twitter, Dropbox, Google Docs, Jira, GitHub, MailChimp, Trello, and Stripe. The San Francisco–based company, which launched its eponymous app in February 2014, was started by a small group of Silicon Valley entrepreneurs that include Flickr founder Stewart Butterfield. Privately-held Slack is on Fortune Magazine’s “Unicorn List” of startup firms worth $1 billion or more, with a $2.8 billion valuation supported by a five percent weekly user growth rate and major brand-name customers including Adobe, Samsung, Intuit, NASA, Dow Jones, eBay, and Expedia.
In the age of the unicorn startups, Slack has drawn attention for its meteoric rise and potential for disrupting traditional business communications tools, particularly email. By June 2015—less than 18 months after its launch—the company already had more than 1.1 million daily users, 300,000 paid seats, and more than 30 million messages flowing through Slack each week via integrations with other services.
Slack’s founders had already learned hard lessons from previous failed ventures. One of those was the importance of picking the right IT infrastructure to run the business. If Slack was to succeed in a fiercely competitive business-software marketplace, its founders knew they would need a lean staff, low costs, and above all an IT environment capable of supporting speed, agility, and innovation. Going to the cloud was the logical choice.
“The realities of physical space, hardware acquisition, replacement parts, running a server facility with all its costs—all the physical manifestations that can lead to breakages—made a traditional IT environment impractical for an Internet startup,” says Richard Crowley, Slack’s director of operations. “Plus we would have needed an extra layer of expertise just to run the infrastructure. We could have operated with that kind of IT infrastructure, but the cost and complexity would have made it much harder to launch the business.”
Why Amazon Web Services
Crowley says Slack turned to Amazon Web Services out of experience and because it was the best choice for the company going forward. Tiny Speck—the original company name for what became Slack Technologies—used AWS in 2009 when it was the only viable offering for public cloud services.
“Given their expertise and pains running a more traditional environment when Flickr was developed, Slack’s founders realized it was a no brainer to use AWS,” says Crowley. “During the development of Slack, the feeling was that AWS was good to us and would continually improve with more and better features. There was no need to leave.”
Slack has a relatively simple IT architecture that is based on a broad range of AWS services, including i2.xlarge Amazon Elastic Compute Cloud (Amazon EC2) instances for basic compute tasks; Amazon Simple Storage Service (Amazon S3) for users’ file uploads and static assets; and Elastic Load Balancing to balance workloads across Amazon EC2 instances.
For security, Slack uses Amazon Virtual Private Cloud (Amazon VPC) to control security groups and firewall rules and AWS Identity and Access Management (IAM) to control user credentials and roles. The company uses Amazon CloudTrail for monitoring logs related to Amazon EC2 instances, and Amazon Route 53 for DNS management.
Along with the AWS services, Slack is using the Redis data structure server, the Apache Solr search tool, the Squid caching proxy, and a MySQL database.