Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reactive Web-Applications @ LambdaDays

5,438 views

Published on

Over the past few years, web-applications have started to play an increasingly important role in our lives. We expect them to be always available and the data to be always fresh. This shift into the realm of real-time data processing is now transitioning to physical devices, and Gartner predicts that the Internet of Things will grow to an installed base of 26 billion units by 2020.

Reactive web-applications are an answer to the new requirements of high-availability and resource efficiency brought by this rapid evolution. On the JVM, a set of new languages and tools has emerged that enable the development of entirely asynchronous request and data handling pipelines. At the same time, container-less application frameworks are gaining increasing popularity over traditional deployment mechanisms.

This talk is going to give you an introduction into one of the most trending reactive web-application stack on the JVM, involving the Scala programming language, the concurrency toolkit Akka and the web-application framework Play. It will show you how functional programming techniques enable asynchronous programming, and how those technologies help to build robust and resilient web-applications.

Published in: Engineering
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Reactive Web-Applications @ LambdaDays

  1. 1. Scala, Akka, Play The why and how of reactive web-applications on the JVM Lambda Days 2015 Manuel Bernhardt - @elmanu
  2. 2. Agenda 1. The Why 2. The How
  3. 3. Who is speaking? • freelance software consultant based in Vienna • Vienna Scala User Group • web, web, web
  4. 4. Who is speaking? • freelance software consultant based in Vienna • Vienna Scala User Group • web, web, web • writing a book on reactive web- applications http://www.manning.com/ bernhardt
  5. 5. The Why
  6. 6. The Why The Whys
  7. 7. 1st Why: it's 2015, the year of...
  8. 8. 2015! Flying cars? Hoverboards? Self-lacing shoes?
  9. 9. 2015: many-core CPUs • End of the single-core multi-core era • Many players in the space • Tilera, Cavium • Adapteva Parallela • Xeon PHI • It's happening!
  10. 10. Too many cores? • 1981 "640 kb ought to be enough for anybody" ~ Bill Gates
  11. 11. Too many cores? • 1981 "640 kb ought to be enough for anybody" ~ Bill Gates • 2014 "4 cores ought to be enough for anybody" ~ Linus Torvalds1 1 http://highscalability.com/blog/2014/12/31/linus-the-whole-parallel- computing-is-the-future-is-a-bunch.html
  12. 12. 2nd Why: distribution is the norm, not the exception
  13. 13. It's all in the cloud • divide & conquer: specialized services that do one thing well • storage: S3 • emails: MailChimp • monitoring: New Relic, Plumbr • etc. etc. etc.
  14. 14. This is not the cloud
  15. 15. That's more like the cloud • scaling out to handle large loads • scaling out / replication to handle node failure
  16. 16. Yes! That's the cloud! • networks, networks, networks • they fail all the time • Jepsen series3 3 http://aphyr.com
  17. 17. The cloud is hard • CAP theorem • 8 fallacies of distributed computing • hard problem, no easy solution • PAXOS, CQRS, CRDTs
  18. 18. 3rd Why: Winter is coming
  19. 19. Side note: Internet of Lost Things Prediction: "By 2020, everyone will have a bunch of online things lost in their appartment"
  20. 20. 4th Why: Houston, we have a problem
  21. 21. Our traditional programming tools don't work in this setting
  22. 22. We have been brainwashed to use: 1. imperative programming with mutable state 2. locks, locks, locks
  23. 23. The problem with mutable state car.setPosition(0); car.setPosition(10);
  24. 24. The problem with mutable state
  25. 25. The problem with locks • solution workaround for a broken conceptual model • hard to reason about • performance hit
  26. 26. The problem with object-orientation in Java • there is no notion of time, only an illusion thereof • changes to a mutable model only make sense locally if nobody is watching • the larger the scope, the harder it gets to prevent inconsistencies
  27. 27. The Whys 1. many-core CPUs are here 2. everything is distributed 3. IoT around the corner with 26 billions devices 4. our traditional approach does not work here
  28. 28. The How
  29. 29. The How The Hows
  30. 30. In theory • Functional Programming • The Actor Model • Evented Server Model • Stateless architecture • Event Sourcing • Reactive Streams
  31. 31. In practice • Functional Programming Scala • The Actor Model Akka • Evented Server Model Play • Stateless architecture Play • Event Sourcing Akka Persistence • Reactive Streams Akka Streams
  32. 32. 1st How: Functional Programming Scala
  33. 33. Short Scala history • Martin Odersky, EPFL • first release in 2003 • Typesafe Inc.
  34. 34. Design goals • Full interoperability with Java • Cut down boilerplate • Pure object orientation & functional programming • Move away from null • Many-core programming
  35. 35. Core concepts of Functional Programming • immutability • functions • transforming data with functions
  36. 36. Immutability case class Car(brand: String, position: Int) val car = Car(brand = "DeLorean", position = 0) val movedCar = car.copy(position = 10) val movedCarLaterOn = car.copy(position = 30)
  37. 37. Immutability case class Car(brand: String, position: Int) val car = Car(brand = "DeLorean", position = 0) val movedCar = car.copy(position = 10) val movedCarLaterOn = car.copy(position = 30) Work with snapshots of state
  38. 38. Higher-order functions val (minors, majors) = users.partition(_.age < 18)
  39. 39. Higher-order functions val isMinor = (age: Int) => age < 18 val (minors, majors) = users.partition(isMinor)
  40. 40. Higher-order functions val isMinor = (age: Int) => age < 18 val (minors, majors) = users.partition(isMinor) Moving behaviour around instead of moving data around
  41. 41. Transforming data val addresses = users.filter(_.age > 18) .map(_.address) .sortBy(_.city) Goal: To build increasingly complex behaviour through a series of transformations / by composing functions
  42. 42. Composition def fetchUser(id: Long): Option[User] = ... def fetchCar(id: Long): Option[Car] = ... val insuranceCost: Option[BigDecimal] = for { user <- fetchUser(42) car <- fetchCar(23) } yield { car.price / 10 - user.age }
  43. 43. Composition def fetchUser(id: Long): Future[User] = ... def fetchCar(id: Long): Future[Car] = ... val insuranceCost: Future[BigDecimal] = for { user <- fetchUser(42) car <- fetchCar(23) } yield { car.price / 10 - user.age }
  44. 44. Composition def fetchUser(id: Long): Try[User] = ... def fetchCar(id: Long): Try[Car] = ... val insuranceCost: Try[BigDecimal] = for { user <- fetchUser(42) car <- fetchCar(23) } yield { car.price / 10 - user.age }
  45. 45. Composition def fetchUser(id: Long): [User] = ... def fetchCar(id: Long): [Car] = ... val insuranceCost: [BigDecimal] = for { user <- (42) car <- (23) } yield { car.price / 10 - user.age }
  46. 46. Composition! Option Future Try ...
  47. 47. Functional composition • Option, Future, Try all implement monadic operations • set of data structures following the same laws • know one, know them all • keeping things DRY • also, it's not that scary
  48. 48. 2nd how: Actor model Akka
  49. 49. History • 1973 "A Universal Modular Actor Formalism for Artificial Intelligence", Carl Hewitt, Peter Bishop and Richard Steiger • based on physics (quantum physics and relativistic physics) • 1986 First release of Erlang (Joe Armstrong) • 1998 Ericsson reports that the AXD301 switch achieves an availability of 99.9999999%
  50. 50. History • 2010 First release of Akka (Jonas Bonér) • inspired by Erlang and the Actor Model • message-based asynchronous concurrency toolkit • object-oriented programming done right
  51. 51. History • 2010 First release of Akka (Jonas Bonér) • inspired by Erlang and the Actor Model • message-based asynchronous concurrency toolkit • object-oriented programming done right • Akka is also a mountain in Sweden
  52. 52. Actors • lightweight objects • send and receive messages (mailbox) • can have children (supervision)
  53. 53. Sending and receiving messages case object RevelationOfFathership class Luke extends Actor { def receive = { case RevelationOfFathership => System.err.println("Noooooooooo") } }
  54. 54. Sending and receiving messages case object RevelationOfFathership class Luke extends Actor { def receive = { case RevelationOfFathership => System.err.println("Noooooooooo") } } val luke = ActorSystem.actorOf(Props[Luke]) luke ! RevelationOfFathership
  55. 55. Supervision class Vader extends Actor { val troopers: ActorRef = context .actorOf[StromTrooper] .withRouter( RoundRobinRouter(nrOfInstances = 8) ) }
  56. 56. Supervision class Vader extends Actor { val troopers: ActorRef = context .actorOf[StromTrooper] .withRouter( RoundRobinRouter(nrOfInstances = 8) ) }
  57. 57. Supervision class Vader extends Actor { val troopers: ActorRef = context .actorOf[StromTrooper] .withRouter( RoundRobinRouter(nrOfInstances = 8) ) override def supervisorStrategy = OneForOneStrategy(maxNrOfRetries = 3) { case t: Throwable => log.error("StormTrooper down!", t) Restart } }
  58. 58. 3rd How: Evented servers & statless architecture Play
  59. 59. Play history • MVC framework, inspired by RoR, Django, Symfony • Zenexity • first version released in 2009 • version 2.0 released in 2012, core rewritten in Scala
  60. 60. Design Principles • everything is compiled • non-blocking I/O • controller actions are functions (request => response) • "share nothing" => horizontal scalability
  61. 61. Threaded servers • like a train station with multiple tracks • station chief decides which trains go on which platform • if there are more trains than platforms, trains queue up • if too many trains are queuing up, huge delays occur and passengers go home
  62. 62. Evented servers • like a waiter in a restaurant • runs back and forth between tables and the kitchen • does only small tasks that do not take much time • one server can each serve many tables at once
  63. 63. Advantages of the evented approach • less threads means less memory • better CPU utilization (reduced context switching) • (much) higher throughputs than threaded servers
  64. 64. The Hows 1. functional programming (immutability, functions, composition) 2. actor model 3. evented servers & stateless architecture 4. event-sourcing & reactive streams
  65. 65. Summary • many-core & distributed systems around the corner and there to stay • get ready and adopt some of the "new" tools
  66. 66. Thank you http://www.manning.com/bernhardt code ctwlambdad 41% discount @elmanu / manuel@bernhardt.io Questions?

×