Speaker
Abstract
Over time, the architectural assumptions underpinning a software application may diverge further and further from that application's product requirements. When this happens, engineers are faced with a choice: soldier on with the existing architecture, accepting maintainability and performance issues, or take a step back and consider a different approach.
At Slack, we recently rethought one of the core assumptions underlying our architecture: that all activity occurs within a specific workspace. When Slack launched in 2013, each workspace was a closed system representing a single customer and containing users, channels, messages and files. With our enterprise solution—launched in 2017—this assumption was weakened to allow bundling multiple workspaces under a single organization, but it still held at a high level. As usage grew, we began to run up against the limits of this workspace-centric architecture, which led to frustrating context switching, duplicate API calls and consistency bugs.
As such, we decided to take a step back and ask: what would happen if users could view all their channels, messages, files, etc (within a single enterprise) in one place? With this, the Unified Grid project was born.
But while we strongly believed that Unified Grid was a superior architecture and product experience, getting there was no small feat. This presentation will describe the evolution of Slack's architecture and how it motivated Unified Grid, as well as the tactics we used to go from prototype to production.
Interview
My work at Slack focuses on greenfield projects which do not yet have dedicated ownership. I see my role as growing these projects to a point where they can be handed off to a dedicated team via prototyping and working cross-functionally to establish product direction. Some projects I have worked on are Unified Grid (this talk) and Salesforce channels.
My talk is motivated by a desire to share the inside scoop regarding one of the most ambitious projects Slack has undertaken, and certainly the most ambitious project I've been a part of. People say that engineers should rarely, or even never, attempt huge architectural overhauls—well, this is one example where we tried it and it worked. I think that's interesting and that there may be some lessons that are more widely applicable.
Software practitioners who work with large, legacy software applications and are considering how best to graft a legacy architecture onto evolving product needs.
I'd love for attendees to come away from my presentation feeling empowered to dream big with respect to the changes they might make to a legacy software application. Simultaneously, I'd like them to be encouraged that real change is possible using the concrete tactics outlined in my talk.
While generative AI has already changed how developers write software, it hasn't made large inroads at more established organizations (at least, not that I'm aware of) partly because of its difficulty in handling idiosyncratic legacy codebases. I think that's going to change.
Topics
QCon San Francisco 2024 is a three day conference for senior software engineers, architects and team leads. An international program committee of working engineers selects every session. Patterns and practices, not products and pitches.
Part of the track
Architectures You've Always Wondered About Hosted by Thomas Betts Senior Laureate Software Architect @BlackbaudFrom the same track
Monday 18 November
10:35 Ballroom A Session MLOps Supporting Diverse ML Systems at Netflix David Berg, Romain Cledat Netflix uses data science and machine learning across all facets of the company, powering a wide range of business applications. 11:45 Ballroom A Session Architecture Optimizing Search at Uber Eats Janani Narayanan, Karthik Ramasamy Uber has an in-house search engine called Search In Action (SIA). As the backbone behind the feed and search capabilities of Uber's Delivery business, SIA plays a crucial role in expanding selection seamlessly for customers which is a strategic advantage to the business. 13:35 Ballroom A Session Architecture Changing the Model: Why and How We Re-Architected Slack Ian Hoffman Staff Software Engineer @Slack, Previously @Chairish Over time, the architectural assumptions underpinning a software application may diverge further and further from that application's product requirements. 14:45 Seacliff D Unconference Unconference: Architectures You've Always Wondered About 15:55 Ballroom A Session HTTP How GitHub Copilot Serves 400 Million Completion Requests a Day David Cheney Lead, Copilot Proxy @GitHub, Open Source Contributor and Project Member for Go Programming Language, Previously @VMware GitHub Copilot is the largest LLM powered Code Completion service in the world, serving hundreds of millions of requests per day with an average response time of under 200ms. This is the story of the architecture which powers this product. 17:05 Ballroom A Session Legacy Modernization: Architecting Real-Time Systems Around a Mainframe Jason Roberts, Sonia Mathew Designing systems that take advantage of modern platforms, tools, and techniques is critical for building scalable, evolvable applications that underpin businesses of all stripes. Leveraging those when your data is captured in a mainframe, which does not scale well, is challenging.