Presentation: Help! I Accidentally Distributed My System!

Rachel: I work at Google on Firebase Security Rules and Google Cloud Policy. Firebase is a Backend As A Service. We provide tools for developers to keep their apps secure. Google Cloud Policy helps system administrators to ensure that all their apps have the same security policy.

Emily:  I manage the product engineering team at Honeycomb. We are building a product to help engineers understand complex systems by helping them visualize production data in new and helpful ways.

Rachel: There is a lot of work being done on building distributed systems. We have been discussing the different aspects of building distributed systems for some time. We felt that there was a need to focus on long-term goals while building systems while taking into account technical decisions that need to be made.

Emily: We are two people with slightly different expertise. Over the years, we have done many joint talks about the hard problems that we solved together. It’s been interesting to see our hardest problems shift from the frontend to the backend, and go from being architecture problems to debugging problems.

Rachel: This talk is for people who think they are building simple services one at a time and slowly realize that they have a complex distributed system instead. This could happen at both small and large companies.

Emily: People may be making good technology choices and taking the correct business decisions along the way, but they may still encounter problems when they reach a certain level of system complexity. This talk is for them.

Emily: We’ll present some examples of the most interesting distributed system bugs we have experienced. My favorite is a bug that at first glance appeared as though it might be a complex distributed systems bug based on its symptoms, but actually turned out to be quite straightforward — after we spent a long time debugging it. We’re going to dive into examples like this and show how we reason about the system, and how good instrumentation can help reduce the time to resolution.

Rachel: We want to make people aware of where the problems are most likely to be found.

Rachel: The talk is for people who make decisions about what their system will look like. In some companies, it could be the V.P.; at others, it could be the senior engineers.

Emily: We want to address senior software engineers, who own the system and the architectural decisions. We want to bring together mindsets from different areas of the stack.

Rachel: We want to give the attendees enough examples to understand that every decision has consequences so that when they are evaluating new software, they know what are the problems to be considered.

Emily: We also want to share the toolset that we found useful in debugging visibility problems in distributed systems. There will be conceptual as well as practical takeaways from the talk.

Emily: There are a lot of surprises distributed systems around us. Any system with a lot of complex app logic in the browser together with a server qualifies to be a distributed system.

Rachel: Distributed Systems is the most important trend because everyone is building services or building on the cloud, which means they are building distributed systems.