Metadata

My advice to you has 4 parts: Publish or perish, Work hard, Understand the philosophy of research, and Manage your time well. (A nice complement to this post is my advice to my undergraduate students .) PUBLISH OR PERISH Be goal-oriented Always know the criteria needed for the next step, and focus on addressing these criteria. Your next step after PhD is, ideally, to get a faculty job. And this requires you to have both good quality and quantity of publications. Aim to have 10 publications, half of them at top conferences. So publish or perish. 4.0 GPA is not your goal. Taking a lot of classes is not your goal. Get your first paper out very fast This will give you the confidence to write other papers. This will teach you that research is not an exotic thing that only professors do. This will shave off couple of years from your PhD. Your first paper does not need to be very good. Get it out fast. Write well, write a lot, revise a lot Writing clearly and communica

This paper (by Ramalingam and Vaswani) proposes a generic/automatic way to use idempotence---which requires the system to tolerate duplicate requests--- for handling communication and process failures in a software system efficiently. Using idempotence for dealing with process and communication failures has been investigated also in the " Idempotence is not a medical condition ", but there no (generic) solution for achieving idempotence was provided. Automating idempotence For automatically ensuring idempotence for a system, the paper makes use of the monad idea , and designs & implements the idempotence monad. The idea underlying the idempotence monad is simple: "Given a unique identifier associated with a computation, the monad adds logging and checking to each effectful step in the workflow to ensure idempotance". Armed with this idempotence monad, the paper shows that idempotence, when coupled with a simple retry mechanism, provides a solution to t

Our department moved into a brand-new beautiful building last year. My new office at this building has a nice side-view of the lake, and also a bird-view of the pedestrian crosswalk on the road in front of the building. I spend a good fraction of my time in the office on my makeshift standing desk in front of the window. So I get to watch (from my peripheral vision) the pedestrians crossing the crosswalk. This makes for a surprisingly suspenseful and distracting pastime. It turns out that crossing the crosswalk is not a trivial task, but rather a complex process. Below I talk about the crosswalk scenarios I observed, and how these relate to some fundamental impossibility results in distributed systems. The crosswalk This crosswalk does not have any traffic lights as it is on a low-traffic/in-campus road. According to the crosswalk protocol, the pedestrian has the right-of-way on the crosswalk: the car needs to stop if the pedestrian shows "intent to cross" (which is un

This is a master's thesis from the CRDT group , presenting the design and implementation of a key-value CRDT store, named SwiftCloud. SwiftCloud extends the Riak Key-Value store in to a Key-CRDT store by incorporating CRDTs in the system's data-model, namely in the value of the key-value tuple. (By the way, Riak---by Basho inc.--- is a NoSQL database implementing the principles from Amazon's Dynamo paper. Enjoy the brief singing of Riak description here!) SwiftCloud achieves automatic conflict resolution relying on properties of CRDTs, and provides strong eventual consistency. (This post will make more sense if you read this first ) SwiftCloud uses state based replication. Strong eventual consistency between replicas is achieved by merging the states of the replicas. SwiftCloud employs versioned CRDTs to support transactions. Transactions never abort due to write/write conflicts, as the system leverages CRDT properties to merge concurrent transactions. The Key-Value

Below are my notes summarizing the paper "Conflict-free Replicated Data Types" by Marc Shapiro, Nuno Preguica, Carlos Baquero, and Marek Zawirski. The paper is available here. Replicated state machines (RSMs) are a basic and important tool for distributed systems. The idea in RSMs is if the replicas start from the same initial state and perform the same updates with the same order, then their end states are the same. The "strong consistency" approach provides this guarantee by serializing updates to the replicas in a global total order. However, the down side to strong consistency approach is that it is a performance & scalability bottleneck, and it also conflicts with availability and partition-tolerance ( due to the CAP theorem ). Replicating data under Eventual Consistency (EC) allows any replica to accept updates without remote synchronization. However, published EC approaches are ad-hoc and error-prone (they come without a formal proof of corrrectness

In the afternoon of day 2, there were breakout sessions. Below are summaries from the ones that I found useful. There was also an expo on day 2, and my notes on the expo are towards the end of this post. Building web-scale applications with AWS This presentation opened with a customer anectode. As you may know, Reddit runs on AWS. When President Obama did an "Ask Me Anything" on Reddit recently, Reddit called AWS a day in advanced to give heads up. There were 3 million pageviews on Reddit that day, 500K of which was for the President's AMA. Reddit has added 60 dedicated instances and handled the extra traffic smoothly. The presenter gave the takehome message in advance for his talk: While you scale, architect for failure, and architect with security. The rest of the presentation talked about these (mostly the first point) in more detail. Architecting for failure.  AWS has 9 regions around the world, and supports within each region different availability zones (AZ

In the morning of day 2, we were led into the very large room for the keynote. There were probably 1000-1500 people in the hall, sitting in tight packed formation. Amazon VP & CTO Werner Vogels entered the stage with fanfare (the hall darkened, upbeat music blasting from the speakers). Werner gave a superb, clear, and engaging talk. You can read my notes of it below, or watch the keynote here (around 2 hours long). The AWS summit series kickstarted in NYC, because there is a good tech crowd here, and more importantly many AWS customers are in NYC. AWS summit series this year will be in 13 cities, for which a total of 20K people registered. It is hard to believe that AWS S3 launched only in 2006. There has been amazing progress in 7 years in AWS. Now there are a total of 33 services running, which span compute, storage, database and application management. 100,000 businesses are using AWS This list includes even an extraterrestrial client: NASA JPL is a good customer, and Curio

I attended AWS summit NYC on Wednesday and Thursday. As an academician, this was a little unconventional conference for me to attend. I regularly attend ACM, IEEE research conferences on focused areas (wireless networks, distributed systems, self-stabilization), but I wanted to go out of my comfort zone to learn about the problems AWS and the AWS ecosystem are working on. Today AWS is leading the cloud computing market, and the AWS infrastructure and platform is an amazing feat of engineering, to say the least. Jeff Bezos, Amazon CEO, has not received a fraction of the genius CEO status alloted to Steve Jobs, but by all accounts Jeff Bezos is not any less deserving. (Read Steve Yegge's platforms rants to see how in 2002 Amazon started an enormous concerted effort for building up its platforms to become what they are today.) I arrived at 2pm on Wednesday to attend the " cloud kata for start-ups ". The name sounds exciting, right? And, they promised powerpoint free pre