Skip to main content

React conference in San Francisco 2014

Last week I attended the React conference in San Francisco. The conference is a two day event where speakers share their experiences on building reactive systems: ones that are resilient, elastic, responsive, and message driven. The reactive manifesto web page  has more detailed information about reactive systems, and why they are useful.

This year the conference was at Cobb's Comedy Club, a cozy venue for the roughly 300 people that attended the conference. Because of the tight space, power plugs were non existent, but the organizers were extremely thoughtful and provided every attendee with a rechargeable battery with iPhone and Android connectors.

The sessions in the conference were great, but a couple stood out. The first was Netflix's presentation "Resilient by Design", where the speaker talked about how Netflix designs and deploys their services: from using microservices that do one thing and do it very well with well defined interfaces, to cloud services everywhere, and thinking about failures and how to degrade gracefully when they happen. The speaker gave an example of the Netflix homepage, where every component from the movie recommendations, to the most popular movies, to the video bookmarking functionality is a service, and that when one of them fails, there is always a meaningful fallback that still allows the user to have a decent experience.

The second was the talk by Gil Tene from Azule systems about "Understanding Latency." The speaker gave great examples of how myopic statistics are deceiving, and how timing measurements in general suffer from mistakes of omission, especially when one request stalls and takes a long time to finish.

The third was the talk by Leslie Lamport about how to specify systems formally through TLA+. The talk was both entertaining and informational at the same time. Lamport admitted that engineers and their managers are allergic to formal specifications, and that they don't see value in them. He then gave a taste of what formal systems are, what they can help with, and  proceeded with counter examples to debunk the myth that formal specs are not useful. Some of the counter examples were discovering design problems that would have been very costly to fix in  Chord, dynamoDB and other Amazon web services, cache coherence in the alpha chip, and the XBox 360 memory model.

Hopefully the conference talks will be online on youtube for others to enjoy the talks as much as the conference attendees did.





Comments

Popular posts from this blog

Kindle Paperwhite

I have always been allergic to buying specialized electronic devices that do only one thing, such as the Kindle, the iPod, and fitness trackers. Why buy these when technology evolves so fast that a multi-purpose device such as the phone or a smart watch can eventually do the same thing, but with the convenience of updates that fix bugs and add functionality? So, I was shocked when this weekend I made an impulse buy and got the newest Kindle Paperwhite—a special purpose device for reading eBooks. I was walking past the Amazon store in the mall and saw that the newest Kindle Paperwhites were marked down by $40 for the holidays. The device looked good in the display, so I went in to look at it closely. The Paperwhite is small and light, with a 6” screen that is backlit and waterproof.   The text was crisp and readable, and in the ambient light, it felt like I am reading a printed book. I was sold and bought it on the spot. At home I have struggled to put it down. The bo...

A paper a day keeps the doctor away: NoDB

In most database systems, the user defines the shape of the data that is stored and queried using concepts such as entities and relations. The database system takes care of translating that shape into physical storage, and managing its lifecycle. Most of the systems store data in the form of tuples, either in row format, or broken down into columns and stored in columnar format. The system also stores metadata associated with the data, that helps with speedy retrieval and processing. Defining the shape of the data a priori, and transforming it from the raw or ingestion format to the storage format is a cost that database systems incur to make queries faster. What if we can have fast queries without incurring that initial cost? In the paper " NoDB: Efficient Query Execution on Raw Data Files ", the authors examine that question, and advocate a system (NoDB) that answers it. The authors start with the motivation for such a system. With the recent explosion of data...

A paper a day keeps the dr away: Dapper a Large-Scale Distributed Systems Tracing Infrastructure

Modern Internet scale applications are a challenge to monitor and diagnose. The applications are usually comprised of complex distributed systems that are built by multiple teams, sometimes using different languages and technologies. When one component fails or misbehaves, it becomes a nightmare to figure out what went wrong and where. Monitoring and tracing systems aim to make that problem a bit more tractable, and Dapper, a system by Google for large scale distributed systems tracing is one such system. The paper starts by setting the context for Dapper through the use of a real service: "universal search". In universal search, the user types in a query that gets federated to multiple search backends such as web search, image search, local search, video search, news search, as well as advertising systems to display ads. The results are then combined and presented back to the user. Thousands of machines could be involved in returning that result, and any poor p...