“I Slacked you” may still be a confusing phrase to many, but not for long. With its instant messaging convenience, Slack is designed to keep your attention within its confines, which sometimes comes at the expense of actually getting any work done. Slack has the primary form of workplace communication to many organisations, reducing the email traffic and connecting remote team.
While Slack’s track record is interesting, it is background history of Slack – and how the suite of tools offered by Slack – that makes the story so interesting. Let’s start from the beginning.
History
Slack was originally developed as a solution to a problem for game developers. In 2011, Tiny Speck was developing the online game ‘‘Glitch’’ and found that there wasn’t a team collaboration tool on the market that met their needs. So they created one! Through this, Slack was born. In the first 24 hours of its launch, 8,000 companies signed up for Slack in 2013.
The tool was called Slack, and it soon became the focus of the company after developers saw the potential. They renamed their company Slack Technologies, and began to market their new product. The core team was drawn from the founders of Flickr, leveraging their Silicon Valley network to build out the new venture. In 2014, Slack raised $120 million, giving the company a whopping valuation of $1.12 billion and Slack became the fastest company in history to achieve a billion dollar valuation.
In 2015, Slack acquires Screenhero (YC W13) to add screen sharing and voice chat to its work messaging platform. In the same year, they hit 1.1 million users and got over $25 million on the revenue. The next year, the platform exceeded 2.7 million daily active users, 800,000 of which were paid. In addition, it raised $200 million in funding, bringing the company valuation to over $3.8 billion. This came as both Facebook and Microsoft launched new workplace collaboration software to compete with Slack.
In 2017, Slack launched enterprise grid, a new set of tools focused on bringing in lucrative corporate clients. It raised even more money, bringing the valuation to $5.1 billion.
In 2018, the competition was heating up. As a result, Slack bought both HipChat and Stride from Atlassian and migrated users to its platform. While Slack’s user count had been explosive, it still wanted a boost to bring in enterprise clients.
The fast-growing company began trading on the New York Stock Exchange on April 26 2019 to grow the corporate chat platform into even more offices, let alone lexicons. The jury is out on whether Slack, reportedly used by 12 million people, is a good thing for productivity and communication.
To understand how this incredible venture was developed over the course of history, we look at three key components making up Slack that we know and love today:
- Slack Platform
- Slack Technology
- Slack Architecture
1. Slack Platform
Essentially, Slack aims to become the aforementioned digital office. At its core, it’s a rather simple messaging app. Slack offers organisations the use of public chat rooms organised by topic, private groups, and direct messaging. The accessibility of each user can be defined by an administrator, and set according to their role in the company. It includes public channels such as #random that allow a team to “chat over the watercooler”, offering a vital outlet for non-work discussion.
New users are invited into teams by being sent a simple URL. Although Slack was designed as an organisational interface, its use is slowly morphing into more and more of a social one, with niche groups creating their own teams where they can meet and talk with like-minded people. Slack simply aims to replace the mess of phone calls, texts and emails with a simple, centralised place for your organisation to collaborate. Everything on Slack is searchable, meaning less confusion and more efficiency.
Web App, Mobile Apps and Desktop Apps
Slack can be found everyone. You can access Slack on any mobile device, in the browser, and from standalone desktop applications.
For the Web, Slack is based on a mix of JavaScript/ES6 and React.js. When Slack created the Windows application, they couldn’t use the existing codebase. In order to make the platform is available on all the devices you can think of. Slack decided to use cross-platform development tools like Electron.
Slack’s desktop application is built using Electron AKA Atom shell, for a faster, frameless look with a host of background improvements for a superior Slack experience. The Electron framework lets Slack write cross-platform desktop applications using JavaScript, HTML and CSS. It is based on io.js and Chromium and is used in the Atom editor.
Slack’s original desktop app was written using the MacGap v1 framework using WebView to host web content within the native app frame. But it was difficult to upgrade with new features only available to Apple’s WKWebView and moving to this view called for a total application rewrite.
However, when Slack looked into how to modernize the Mac app, moving to a unified codebase across Mac, Windows, and Linux was an easy choice with Electron.
Although Slack Desktop takes a hybrid approach, most of their assets and code are loaded remotely, combining the rendering engine from Chromium and the Node.js runtime and module system. The new desktop app is now based on an ES6 + async/await React application, which is currently being moved gradually to TypeScript.
Electron functions on Chromium’s multi-process model, with each Slack team signed into a separate process and memory space. It also helps prevent remote content to directly access desktop features using a feature called WebView Element that creates a fresh Chromium renderer process and assigns rendering of content for its hosting renderer. Additional security can be ensured by preventing Node.js modules from leaking into the API surface and watching out for APIs with file paths.
Communication between processes on Electron is carried out via electron-remote, a pared-down, zippy version of Electron’s remote module, which makes implementing the web apps UI much easier.
Finally, for Android, Slack is built by a mix of Java and Kotlin, and for iOS it’s written in a mix of Objective-C and Swift.
Integrations
Where Slack separates itself from many other chat apps is the option for Slack integrations to other services. Major integrations include Google Drive, Trello, Dropbox, GitHub, Mailchimp and Zendesk, although there are hundreds in total.
Integrations with for example SocialWall has turned Slack from a private team collaboration service into a public team display service, with the #random channel or a channel devoted to important team announcements being able to be displayed on any web-connected screen, no matter how widely dispersed your team may be.
To construct Slack bot, there are different alternatives to pick in programming dialect. The decision will contrast by the support given by these stages. The main consideration in choosing the programming dialect will rely on upon the upheld APIs utilized by the stages.
Additionally, Slack gives support for various languages for creating bots on its stage including Node.js (JavaScript) and Python.
The programming language which are for the most part utilized as a part of building up the bots for Messenger, Telegram and Slack incorporate Python, PHP, Java, Node.js, C#, Objective-C, Swift, and Go.
2. Slack Technology
With the overview of all the different applications making up Slack’s platform, we now dive into the technology that powers all the messages, files and calls in Slack’s backend and database.
Slack’s team uses PHP and Java on the backend. Slack’s JavaScript framework is a homespun mixture of jQuery, pure JavaScript, and an in-house plugin called Monkey scroll.
They use Apache Lucene for searching and Fastly as their CDN. Their desktop apps are built with Electron AKA Atom shell.
Slack is built on PHP, using MySQL as the database, Smarty templating for the view side of things and everything is hosted on Ubuntu servers.
They help verify that the data remains intact and stored safely at all times. Yet, even with the best efforts to prevent errors, inconsistencies are bound to creep in at any stage. In order to test the code in a comprehensive manner, Slack developed a structure known as a consistency check framework based on PHP and MySQL.
This is a responsive and personalized framework that can meaningfully analyze and report on the data with a number of proactive and reactive benefits. This framework is important because it can help with repair and recovery from an outage or bug, it can help ensure effective data migration through scripts that test the code post-migration, and find bugs throughout the database. This framework helped prevent duplication and identifies the canonical code in each case, running as reusable code.
The framework was created by generating generic versions of the scanning and reporting code and an interface for checking code. The checks could be run from the command line and either a single Slack team could be scanned or the whole system. The process was improved over time to further customize the checks and make them more specific. In order to make this framework accessible to everyone, a GUI was added and connected to the internal administrative system. The framework was also modified to include code that can fix certain problems, while others are left for manual intervention.
For Slack, such a tool proved extremely beneficial in ensuring data integrity both internally and externally. Slack is inconceivably prominent nowadays. It’s a stage for in-organization correspondence through visit informing, and a naval force of outsider combinations. It’s so straightforward, and effective. It goes to show you that it doesn’t take the latest hype languages or frameworks to build a great product. PHP cops a lot of smack, but Slack have a great product and PHP doesn’t seem to have inhibited their success.
It’s ironic that the de facto demo app that shiny modern tools show off to prove their viability is an instant messaging app, but that the number one app for business messaging, Slack, is built of tools that are much older.
3. Slack Architecture
Slack needed to pick an infrastructure partner that could support the exponential growth they were experiencing. Amazon’s AWS is the cloud provider to supply i2.xlarge Amazon Elastic Compute Cloud (Amazon EC2) instances for their LAMP stack, Amazon Simple Storage Service (Amazon S3) for user’s file uploads and static assets, and ELB to Load Balance workloads across their EC2 instances.
For security, Slack went with Amazon Virtual Private Cloud (VPC) for controlling security groups and firewall rules and AWS Identity and Access Management (IAM) for controlling user credentials and roles.
In 2018, Slack signed an agreement with AWS to spend at least $50 million a year over five years, for a total of at least $250 million, according to the company’s filing with the SEC for a public stock listing.
Security
In order to protect applications such as Slack from malicious activity, it was crucial to monitor the infrastructure at all times. The best way to do this was through a centralized logging system and Slack enables the same through tools such as StreamStash, Elasticsearch, and ElastAlert.
StreamStash is a Node.js based service for log aggregating, filtering, and redirecting. It transmits outputs to ElasticSearch, which is an open source full-text search engine using an HTTP web interface and schema-free JSON documents. It provides an almost real-time and scalable search to the user.
This helps users retrieve any log file at its most updated state almost instantly. ElastAlert helps provide alerts for anomalies, spikes and other curious patterns for data available in ElasticSearch. This robust system together ensured all the data was processed and collected by the application and can be studied and retrieved at a moment’s notice for necessary action.
Communication
As the teams got bigger, the initial techniques for loading and maintaining data did not scale. To fix this, a system to lazy load data on demand and answer queries was developed. Some critical problems faced at this juncture were: connection times started to take longer, client memory footprint was large, reconnecting to Slack became expensive.
So then, Slack clients connected to Flannel, an application-level caching service developed in-house and deployed to their edge points-of-presence which in turn gathers the full client startup data opening a WebSocket connection to Slack’s servers in the AWS regions.
Flannel then returns a slimmed down version of this startup data to the client, allowing it to bootstrap thus ensuring the Slack client is ready to use. Flannel ran in Slack’s edge locations since January 2017 serving 4 million simultaneous connections at peak and 600k client queries per second. With Flannel, the payload size needed for client bootstrap reduced considerably. In all Flannel played quite a role in making Slack faster and more reliable.
In a video of the series “This is My Architecture”, Richard Crowley, Director of Slack Service Engineering shows us how they use Cloudfront, HAProxy, ELB, EC2, and Route 53 to make all of this happen.
Scaling
As of 2017, Slack was handling a peak of 1.4 billion jobs a day, (33,000 jobs every second). Until recently, Slack had continued to depend on their initial job queue implementation system based on Redis.
While it had allowed them to grow exponentially and diversify their services, they soon outgrew the existing system. Also, dequeuing jobs required memory that was unavailable. Allowing job workers to scale up further burdened Redis, slowing the entire system.
Slack decided to use Kafka to ease the process and allow them to scale up without getting rid of the existing architecture. To build on it, they added Kafka in front of Redis leaving the existing queuing interface in place.
A stateless service called Kafkagate was developed in Go to enqueue jobs to Kafka. It exposes an HTTP POST interface with each request comprising a topic, partition, and content. Kafkagate’s design reduces latency while writing jobs and allows greater flexibility in job queue design.
JQRelay, a stateless service, is used to relay jobs from a Kafka topic to Redis. It ensures only one relay process is assigned to each topic, failures are self-healing, and job-specific errors are corrected by re-enqueuing the job to Kafka.
The new system was rolled out by double writing all jobs to both Redis and Kafka, with JQRelay operating in ”shadow mode” – dropping all jobs after reading it from Kafka. Jobs were verified by being tracked at each part of the system through its lifetime.
By using durable storage and JQRelay, the enqueuing rate could be paused or adjusted to give Redis the necessary breathing room and make Slack a much more resilient service.
Conclusion
Slack has ascended to end up plainly the web’s most famous corporate talk customer. It’s adored for its exquisite, bubbly interface and huge amounts of delightful little co-operations all through the application. Clearly that level of users traction indicates something good is happening with this increasingly ubiquitous app bringing all the communication together in one virtual place.
There’s no arguing that Slack is a great product. Everyone seems to be raving about the magical team chat app that boosts productivity overnight. But it has got some criticisms. For example, continually checking in or switching on notifications on Slack can be damaging to your productive flow when doing an intensive piece of work.
However, the problem with Slack is not in the tool itself, but rather in the way people use it. No matter how powerful a tool is it will fail you unless you know when to use it. For many teams Slack has been hailed as the saving grace to their communication and productivity faults. Is it time that we start to rethink how and when we use Slack.
