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

Language Abstractions for Scalable and Resilient Architectures

Language Abstractions for Scalable and Resilient Architectures

Bucharest FP

April 29, 2015
Tweet

More Decks by Bucharest FP

Other Decks in Programming

Transcript

  1. Functional Programming
 Language abstractions for scalable and resilient architectures

  2. Modern architectures" • Complex interdependencies • Multiple layers of abstraction

    and indirection " Should be: • Resilient – able to scale up also down • Robust, antifragile " Antifragile: term coined by Nassim Nicholas Taleb. A system is antifragile if robust as a whole, regardless the failure of some of its individuals.
  3. It’s ok to fail" • Failure is just a normal

    event, like any other " • Failure is natural, successful systems have individuals’/components’ failure built into the design " • Some examples: " • In IT, the long standing and omnipresent proof of success for the “ok to fail” design : the TCP/IP stack • In real life: human specie, as a whole, is successful and robust " • Tools eg programming languages, where the focus is on actions and interactions (verbs in FP paradigm), are naturally fitted for building complex resilient systems.
  4. The legacy we live with - a part of it

    • The 70’s: C language. It’s design provided the first powerful, revolutionary abstractions that mapped efficiently to the typical machine instructions back then, as they still do, nowadays " • The 80’s: C++ came along, and the OO golden age began: data, actions and the desired result of actions upon data stay together conceptually, abstracted by classes and objects (encapsulated stateful interaction, designed strong coupling between actions/behavious and state). Other existing paradigms and supporting languages (eg functional) existed but were not mainstream (Lisp – created in 1958, Haskell etc). " • The 90’s – Java. First JVM. The machine becomes abstract (another layer of indirection). JVM as another layer of indirection lead to the creation of Java.next languages: • Clojure – functional and dynamically typed • Scala – multiparadigm, OO & functional, statically typed • Groovy, Clojure – Lisp implementation on JVM • Last but not least, Java 8 adopts functional programming and design patterns, with higher-order functions, streams etc.
  5. Standing on the shoulders of giants • Erlang " •

    Joe Armstrong – awesome engineer, and awful C programmer • http://youtu.be/HCwRGHj5jOE, so it’s ok to fail as C user and still design a revolutionary language with a virtual machine written in C, as long as you are part of an extraordinary team that compensates for the lack of C usage skills :) " • In Erlang the way components are able to interact ensures the key to system robustness. So we had the first software language designed with “individual failure is normal” in mind " • Design choices: • Processes – share no memory, are insulated and can interact only with each other by exchanging messages; managed by Erlang VM with lightweight memory footprint • Supervisor (OTP) • Process communication constructs: messages, links, signals, monitors
  6. Powerful abstractions" • Immutability and persistent data structures – Chris

    Okasaki's Purely Functional Data Structures http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf " • Sequences are immutable – just a way to consume a succession of data. • In Clojure are immutable and represent an abstraction over the underlying data structure per se (do not modify the storage structure of that data). They are only a view over the underlying data, unlike Java iterators " • Laziness – the value is not computed until actually required • As a design choice, FP languages have structures that are intentionally lazy (eg map, filter and so on) • Once a value is computed, it is cached so that any future reference need not re- compute it. The term for this caching is memoization.
  7. Three constructs for concurrency by design Erlang AKKA Clojure Design

    choice Process: " - Run inside Erlang VM (not OS process) - Lightweight - Use dynamically allocated stack -> memory allocation performance - Communicate by exchanging messages asynchronously Actor: " - Fully location transparent, decoupling between the running instance of the actor and the reference to the actor - Lightweight processes - Share-nothing, fully isolated - Non-blocking, asynchronous message communication; (mailbox, message queue) - Actors controlled by scheduler Agent: " - Also in Scala AKKA - Provide independent, asynchrono us change of individual locations - Bound to a single storage location for their lifetime (as opposed to actors), and only allow mutation of that location (to a new state) to occur as a result of an action - Actions are functions (may be polymorphic) that are asynchronously applied to an Agent's state and whose return value becomes the Agent's new state.
  8. Reactive Streams • http://www.reactive-streams.org/ " • Driven by industry (from

    companies with similar needs the reactive streams were born; a collaboration between Netflix, Pivotal, RedHat, Twitter, Typesafe and others) " • API for Stream-oriented libraries for the JVM that process a potentially unbounded (infinite) number of elements in sequence, asynchronously passing elements between components, with mandatory non-blocking backpressure (the receiving side is not forced to buffer arbitrary amounts of data), in a publisher-subscriber pattern. " • Inspired by the Reactive Manifesto (http://www.reactivemanifesto.org/)
  9. Vă mulțumesc. " " Întrebări și discuții ? " Let’s

    handle them asynchronously, in a message driven manner :)