Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Scaling a Startup with a 21st Century Programmi...

Scaling a Startup with a 21st Century Programming Language

Velocity, London 2017

Christopher Meiklejohn

October 19, 2017
Tweet

More Decks by Christopher Meiklejohn

Other Decks in Research

Transcript

  1. SCALING A STARTUP WITH A 21ST CENTURY PROGRAMMING LANGUAGE Christopher

    S. Meiklejohn Instituto Superior Técnico Université catholique de Louvain Velocity, London 2017
  2. WHO AM I? Industry (1998 – 2016)  Telecommunications for

    8 years  Software Development Manager for Berklee College of Music online learning platform  Basho Technologies, developer of Riak database  Worked on roughly 6 different NoSQL databases Academia (2016+)  Ph.D. candidate based in Portugal & Belgium  Creator of the Lasp programming system for large- scale, asynchronous distributed computing  Contributor to Microsoft Orleans distributed computing framework  Co-founding a technical transfer startup in Paris, France on large-scale distributed application infrastructure Come talk to me!
  3. WINE: I’M A FAN Tried building a startup that would

    recommend people different types of wine  Wanted to alleviate the process of learning about wine using a computer  Typed in a lot of the “Wine Guide” into a database  Screen-scraped Gary’s “Cork’d” website extensively using a web spider I wrote Built on Ruby on Rails, using Riak and MapReduce  Use geo-location and other factors to identify similar climates, terroir, etc.  Recommend wine based on this and other factors Distributed computing is much cooler  Why do we write applications this way…  Why do we interact with databases this way… Joined Basho Technologies  Joined a European Union funded research group on CRDTs…
  4. NARRATIVE: WINE RECOMMENDER APP 1. Implement version 1.0 features using

    a traditional architecture. We demonstrate implementing features of our application using Martinelli with a traditional three-tier architecture. 2. Implement version 2.0 features using an ideal architecture. We demonstrate implementing features of our application using Martinelli with an ideal peer-to-peer highly-available architecture. 3. What is Martinelli? We present the principles behind Martinelli and the techniques and tools that Martinelli uses to achieve this. Martinelli is a fictional programming language demonstrating an “ideal” in distributed programming language design.
  5. V1.0 FEATURES Users upload photos of bottles of wine they

    enjoy through app Data is processed with ML/AI algorithm to identify and classify Recommendations are created using an iterative algorithm Our core feature set for our mobile application, designed using existing technologies and using a traditional data center focused design
  6. TRADITIONAL ARCHITECTURE • Communication through data center • Application servers

    run business logic • Clients must be online to operate Analysis • Application is easy to program • Exhibits high latency (non-native) • Exhibits low availability (DC-focused)
  7. CODE: PHOTO UPLOAD Server database :photos on_photo do |user_id, photo|

    photos[:user_id].add(photo) end Client database :photos on_photo do |photo| upload(user_id, photo) end Key-value store to store photos: in essence, a map. Every time a photo is taken, upload it to the server. Store each photo in a map indexed by user.
  8. CODE: RECOMMENDATIONS Server database :recs database :favorites process do |user_id

    in users| classify(photos[:user_id], favorites[:user_id]) end process do |user_id in users| recommend(favorites[:user_id], recs[:user_id]) end Client database :recs database :favorites process do refresh(user_id) end process do render(recs) end Key-value stores for recommendations and favorites. Process keyword defines a concurrent process that keeps executing. One process per user to classify photos into favorites. One process per user to recommend based on favorites.
  9. V2.0 FEATURES [Fully offline] Recommendations while offline  Use local

    information when offline  Augment information and refine recommendation when online using available local information; augment recommendations when online [Partially offline] Share and modify both favorites and recommendations with friends when offline [Online] Purchase wine off of your recommendation list with transactional guarantees Features we would like to add to our application in the near future to enable a better experience for our users
  10. IDEAL ARCHITECTURE • Application code at the edge • Peer-to-peer

    communication redundancy • Application is transactional Analysis • Application is hard to program • Exhibits low latency • Exhibits high availability
  11. CODE: OFFLINE WITH REPLICATION process do |user_id in users| refine(photos,

    favorites) end process do |user_id in users| refine(favorites, recs) end database :photos, :replicated => :user_id database :favorites, :replicated => true database :recs, :replicated => :user_id Fully replicated. Clients run same code as server, operates with available data. Partially replicated by user.
  12. MARTINELLI “While you’re at it, why don’t you try my

    Martinelli?” – Tom Frost, Naked Lunch
  13. WHY MARTINELLI? Techniques for v2.0 features exist only in isolation

     Systems, algorithms, etc. Development largely addressed from a systems composition perspective  Kafka, to Hadoop with Spark, etc. Programmers responsible for “gluing” services together at boundaries An ad-hoc programming model  Weak semantics  APIs define the “programming language” Why do we need a language like Martinelli? Underspecified, ad hoc, defined by implementation.
  14. HISTORICALLY [Well designed, no adoption] Pure approaches, new runtime and

    language  Argus (Liskov et al. 1986)  Transactional support, fault-tolerant handling of RPCs  Emerald (Black et al. 1986)  Objects with object migration; separation of typing/implementation [Poorly designed, high adoption] Retrofitting existing systems  CORBA (OMG, 1991)  Leverage existing language semantics, make distribution transparent to the user  Cross-language, cross-system, cross-architecture What can history tell us about distributed programming languages?
  15. MARTINELLI Language for building applications on top of composed systems

     Not possible to reimplement all existing systems into a new runtime  Composition, “glue” can be independently verified via existing techniques (LDFI 2015, etc.) Fault-tolerant, highly available infrastructure for application execution  Peer-to-peer, client-side application execution and data replication Programming model designed for distributed applications  Restricted language semantics depending on the network topology and environment the application is being deployed in What exactly is Martinelli?
  16. MARTINELLI ARCHITECTURE • Application code at the edge • Peer-to-peer

    communication redundancy • Application is transactional Analysis • Application is easy to program • Exhibits low latency • Exhibits high availability Meets all three of our criteria!
  17. PEER-TO-PEER INTERACTIONS Peer-to-peer topologies widely studied and successful, examples: 

    Kademlia (BitTorrent)  Lasp, Cassandra (HyParView) Provide greater redundancy and efficient management of state and communication links Eliminate the need for a central coordination point Peer-to-peer communication enables highly resilient communication when failures occur in large networks.
  18. APPLICATION MIGRATION Edge computing moves app to the device 

    Provides a better experience to user Today, this implementation must be duplicated, implemented twice Promising approaches:  Portable VMs  Architecture specific code targeting  Program slicing Applications (and their data) must be migrated to the edge to exploit local operation and low latency interactions.
  19. CONVERGENT COMPUTATION Concurrent operation may generate conflicts  How to

    pick “winning” update?  How to present conflicts to the end user? Edge introduces additional concurrency  False concurrency (efficient tracking, false positives)  Modifying stale data (conflicts from staleness) Specialized data structures:  Conflict-free Replicated Data Types  Operational Transformations  Cloud Types  Mergeable Data Structures Concurrency is problematic for large- scale distributed applications.
  20. ATOMIC OPERATIONS Transactions provide ACID  Atomicity (A): indivisible groups

     Isolation (I): sequentiality of groups Distribution makes it difficult  2PC: fault-tolerant atomic commitment  2PL: isolation (serializability), but locking problematic under partition Promising approaches:  Distributed Sagas: atomicity, no isolation  MSFT Orleans: 2PL/2PC at single-DC scale  Cure: causal, weak isolation, atomicity for geo-scale Transaction protocols typically provide both atomicity and isolation for groups of updates.
  21. EVOLVING LANDSCAPE Lasp connects Erlang systems together using a safe

    distributed programming model on very large P2P clusters (1024+ nodes) Legion provides P2P client interactions for vanilla JavaScript apps with CRDTs and Google AppEngine SwiftCloud provides causally consistent transactions at the client Erlang VM has been ported to extremely low- power computing devices enabling application migration to the edge MSFT Orleans provides 2PL/2PC transactions at geo-scale LDFI verifies fault-tolerance under composition; latter, for application invariants under weak ordering Independent solutions are evolving into Martinelli-like languages with peer-to- peer interactions, application code at the edge, transactional guarantees and convergent-by-design programming models. Research systems. Production systems that evolved from research systems.
  22. MOVING FORWARD We’ve seen new greenfield systems fail to gain

    adoption  CORBA vs. Argus, Emerald, etc. Therefore, we must strive to build research solutions that leverage existing tools  Orleans with Microsoft CLR, CRDTs in Riak, Legion with Google AppEngine However, the systems centric approach provides a weak foundation  Weak semantics, hard to make guarantees about composition correctness Therefore, strive for new distributed programming abstractions and models  Strong semantics, focus on writing applications and not gluing services together