Ethan Jackson - Specifying Cloud Applications

Play Ethan Jackson - Specifying Cloud Applications
Sign in to queue


Today we talk with Ethan Jackson about Cloud applications. 

Cloud applications are web-based distributed systems deployed over a fluctuating set of computing nodes and services. The design of cloud applications is particularly challenging because few assumptions can be made about the connectivity of nodes, the availability of services, and the long-term evolution of the computing fabric. Ethan describes a new approach to architecting cloud applications. His approach gives developers a powerful set of abstractions that they can use to engineer systems beyond a client-server architecture, while understanding the behavior of their applications in a cloud environment. This is part 1, where we introduce the basic concepts on the whiteboard.

  • BAM project home page 

The Research in Software Engineering team (RiSE) coordinates Microsoft's research in Software Engineering in Redmond, USA.



Right click to download this episode

The Discussion

  • User profile image
    cool stuff Smiley but i dont quite get how it works when data in one clique is is needed by a client in another clique?
    or if some state is updated in clique A and a client that happens to be in clique B lisents to that state?
  • User profile image
    Ethan Jackson
    Hi aL_,

    That's an interesting question. The idea is this: In one "logical step" of the system nodes can only interact with their neighbors. If node A wants data to reach node B, which is in another clique, then A interacts with one of its neighbors A' that is closer to B. In the next step, A' can interact with one of its neighbors B', which is also a neighbor of B. In the third step, B' interacts directly with B. The only trick is to add the operations enabling these steps. A realistic system will almost certainly have these multi-step operations. However, in our approach we want to avoid operations that identify specific nodes (e.g. A and B) since we don't know how reliable they are or how they will be connected. Instead, we partition that data across different types of nodes (e.g. Type A nodes and Type B nodes) in the hope that we can always find a node of the proper type in the cloud. Please let me know if that answers your question?


Add Your 2 Cents