JVMCon - Reacting to the future of application architecture

Editor's Notes

• #5: A single website may now handle as much traffic as the entire internet did a decade ago!! Distribute out different services Easily add features, deploy small part of application Isolate failure New problems --> users have new ever-demanding expectations Doesn't expect an application to fail or have no access Expect responses as soon as they click Shopping cart example How can we tackle these new demands and expectations user's put on applications? Where do we go in our evolution? Biology background inspiration --> nature inspire our apps Bees = system of individuals, independent but common goal
• #6: The 100 million-year-old fossil was found in a mine in the Hukawng Valley of Myanmar (Burma) and preserved in amber. Discovered in 2006
• #7: Independant Observers Act as soon as possible - quick to respond
• #8: Colony Independently continues Impact of Queen being lost is managed Has the potential to be catastrophic but isn’t
• #9: Guards recruit more bees to defend hive Limited number of bees - so switch roles to make up numbers and go back to original role after Dynamically increase number of guards
• #10: Creation of the Reactive Manifesto in 2013, by Jonas Bonér to collaborate and solidify what the core principles were for building reactive applications and systems REACT to users (Responsive)- user click a button REACT to load (Elastic) - black friday and login/book table REACT to failure (Resilient) - monitor, replace service REACT to events (event-driven) - achieve other 3 principles how do we achieve this? same way bees do async comm - dancer bee, guard bee recruiting Let’s say that our system should: . Be responsive to interactions with its users . Handle failure and remain available during outages . Strive under varying load conditions . Be able to send, receive, and route messages in varying network conditions These answers actually convey the core reactive traits as defined in the manifesto. It is important to realize that reactive traits not only set you up for success right now, but also play very well with where the industry is headed, toward location-transparent, ops-less distributed services.
• #11: bees = sophisticated system, appear simplistic, actually complicated efficient society of independent individuals acting as a whole We want to mimic what bees have achieved - tall ask, bees have had millennia, but by implementing reactive architecture we can start to achieve this
• #12: If it’s our goal to build responsive applications in an event-driven world, we need to be making sure we are getting the most out of the hardware on which we’re running. We do this through concurrency and parallelism. Reactive programming is one tool which aims to try and tackle this. Reactive programming is a great technique for managing internal logic and dataflow transformation, locally within the components, as a way of optimizing code clarity, performance and resource efficiency. Reactive systems puts the emphasis on distributed communication and gives us tools to tackle resilience and elasticity in distributed systems. Reactive programming is a paradigm in which declarative code is used in order to construct asynchronous processing pipelines. Translated, this is essentially the same process our minds perform when we try to multitask. Rather than true parallel tasking, we actually switch tasks and split those tasks efficiently during their duration. This method of switching tasks enables us to efficiently use our time instead of having to wait for the previous task to complete. This is exactly what reactive programming was created to enable and is an event-based model in which data is pushed to a consumer, as it becomes available turning it into an asynchronous sequences of events. Reactive programming is a very useful implementation technique for managing internal logic and dataflow transformation, locally within components. However, once there are multiple nodes, there is a need to start thinking hard about things like data consitency, cross-node communication, orchestration, failure management, separation of concerns and responsibilities, etc, i.e. there is a need to think about system architecture. Reactive programming cannot address these issues or address the need for resilience and elasticity within a system. So, instead, to maximize the value of reactive programming, it’s recommended to use it as a tool to build a reactive system.
• #13: Architectural tools – enable reactive behaviours
• #14: Sphere of knowledge or activity Subject area on which the application is intended to apply Development approach as opposed to a physical tool Aims to ease the creation of complex applications – divides up large systems into bounded contexts A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An aggregate will have one aggregate root. DDD = independent areas of a problem as bounded contexts, emphasises a common language to talk Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole. How do we achieve efficient communication across these bounded contexts/services? Focus on the core domain and domain logic. Base complex designs on models of the domain. Constantly collaborate with domain experts, in order to improve the application model and resolve any emerging domain-related issues. Message-driven Lagom framework
• #15: Communication between Microservices needs to be based on Asynchronous Message-Passing An asynchronous boundary between services is necessary in order to decouple them, and their communication flow, in time—allowing concurrency—and in space—allowing distribution and mobility. Without this decoupling it is impossible to reach the level of compartmentalization and containment needed for isolation and resilience. Asynchronous and non-blocking execution = more cost-efficient through more efficient use of resources, minimizes contention (congestion) on shared resources in the system, which is one of the biggest hurdles to scalability, low latency, and high throughput. It’s best illustrated with an example… bees queuing = wasted resource, equivalent to threads But why is blocking so bad? The fundamental shift is that we’ve moved from "data at rest" to "data in motion. Applications today need to react to changes in data in close to real time—when it happens First Wave = data at rest, batch processing, hours of latency, overnight Second Wave = hybrid architecture, lambda architecture, 2 layers (batch and speed layers), added needless complexity – 2 data pipelines and need to merge them afterwards Third Wave – fully embrace data in motion, stream processing architecture, event logging/sourcing….. Lagom framework Message-driven / responsiveness
• #16: Event Sourcing ensures that all changes to application state are stored as a sequence of events (e.g. business objects is persisted by storing a sequence of state changing events) Command Query Responsibility Segregation --> disassociate writes (commands) and reads (queries) Applying event sourcing on top of CQRS means persisting each event on the write part of the application. Read part is derived from the sequence of events. Bees brains = local databases Dance floor – write to bees brains Bees can query their own brains (read) May not be most up to date but that’s ok Responsiveness Lagom framework
• #17: Tradeoff Dance floor  bees assume the food is still available until another bee comes back and says otherwise More representative of the way the world works Given enough time, all nodes will become consistent Not perfect  sharding to help improve consistency Lagom framework CAP Theorum
• #18: Form of Database partitioning, separates very large databases into smaller, faster, more manageable parts called data shards Shard = small parts of a whole Meant to make v. large databases more manageable Greater parallelism, without collisions Two bees at the same cell – fill up multiple cells (sharding) Finite space in the hive – sharding out the hive into cells – operate in parallel across cells, reducing contention Imagine one huge cell, only one bee can fill up at a time Resiliency/elasticity Lagom framework
• #19: Form of feedback/flow control Without feedback, a distributed system can easily become unstable and fail. Any component that cannot support the worst possible case of loading in the system can become a bottleneck. BLOCKING Without Feedback, other components will continue to increase the load until they are in turn congested, resulting in the ultimate collapse! When one component is struggling to keep-up, the system as a whole needs to respond in a sensible way. It is unacceptable for the component under stress to fail catastrophically or to drop messages in an uncontrolled fashion. Since it can’t cope and it can’t fail it should communicate the fact that it is under stress to upstream components and so get them to reduce the load. This back-pressure is an important feedback mechanism that allows systems to gracefully respond to load rather than collapse under it. this mechanism helps ensure that the system is resilient under load, and will provide information that may allow the system itself to apply other resources to help distribute the load, see Elasticity. Backpressure = built wherever the publisher is faster than the subscriber Honeycomb vs nectar ratio Resiliency / responsiveness
• #20: Builhead use in industry to partition a ship into segments, so that sections can be sealed off if the hull is breeched. --> concept can be applied in software development to segregate resources Protect limited resources from being exhausted. Dancer communicating how many bees should go to food source Resiliency/responsiveness Akka
• #21: Bees are intelligent actors, software isn’t so we have to program to imitate it Protect resources and help them recover Circuit breaker opens when a particular type of error occurs multiple times in a short period. An open circuit breaker prevents further requests to be made. They usually close after a certain amount of time, giving enough space for underlying services to recover. Resiliency Akka
• #22: third party libraries RxJava is a Java VM implementation of Reactive Extensions: a library for composing asynchronous and event-based programs by using observable sequences. Microprofile Reactive Streams is an integration SPI - it allows two different libraries that provide asynchronous streaming to be able to stream data to and from each other. Play Framework is a web development framework that empowers developers to build highly scalable, lightning-fast applications with an ease unparalleled on the JVM. Play is built on top of Akka and Akka HTTP Lagom is an opinionated microservices framework that builds on top of Akka and Play
• #23: For the actor model it's relatively fine-grained, in that an actor tends to represent the equivalent of one object in Object Orientated Programming. For micro-services it's relatively coarse-grained, in that a single micro-service may consist of a large number of actors or objects. An actor is the thing that receives a message and does some kind of computation based on it. When you hear of an actor, think of it as a computer process or a function - you're going to pass a message to, kind of like calling a function. Basically you send the actor instructions and it returns some information back to you. The idea is very similar to what we have in object-oriented languages: An object receives a message (a method call) and does something depending on which message it receives (which method we are calling). The main difference is that actors are completely isolated from each other and they will never share memory. Actors are part of an actor system and can be arranged in a hierarchy. This means they can split up and delegate tasks to child actors. The child actor is supervised and delegate their failure back to their parent actor. In the actor model everything is an actor and they need to have addresses so one actor can send a message to another. You can also assign one address to multiple actors. This way you can scale your application to meet traffic demands if one actor is not enough. Actors communicate with each other by sending asynchronous messages. Those messages are stored in other actors' mailboxes until they're processed. Actors are not suitable when you need a sequential order of things to happen. If you find yourself sending multiple messages and then needing to rollback those processes if one fails, you might want to reconsider using the Actor Model. A common example of this is a bank account. If you are building an application that handles tasks asynchronously, using the Actor Model can help simplify your code. It will allow you to scale your application and process tasks in parallel.
• #24: Vert.x is based on a flat hierarchy and does not implement the actor model. Instead, it is based on the event loop model. The unit of execution in Vert.x is known as a Verticle. It processes incoming events over event-loops, which are typical in asynchronous programming models. Verticle is a class whose state is totally inaccessible from outside except through event bus. So messages come, queued, and popped sequentially in a single thread manner. The idea is to create a thread-safe environment without having to deal with Java’s locking mechanism. Similar to Akka, Vert.x also supports point-to-point and a publish-subscribe pattern. A difference is the message passing of Vert.x is language agnostic and uses JSON to pass data, whereas Akka uses specific objects from either Scala or Java. Akka provides an additional component known as Akka Persistence that can be used to store the internal state of an actor. This enables the state of an actor to be recovered if it crashes. Currently, Vert.x does not provide out-of-the-box recovery capabilities. People argue that due to its complexity, Akka tends to have a much larger learning curve than Vert.x. it’s said that Akka needs more understanding and mastery of the actor model and async architectures in order to use it effectively. However, Akka is more mature, had more features (Akka streams, Akka perstistence, Akka clusters). Your choice…
• #25: Switch off bits of system to deal with load of customers trying to buy new phones – reactive solved this Google: “faster page loads, the more successful it will be”, people don’t want to wait Performance plays a major role in the success of any online venture. Case studies that show how high-performing sites engage and retain users better than low-performing ones: Pinterest increased search engine traffic and sign-ups by 15% when they reduced perceived wait times by 40%. COOK increased conversions by 7%, decreased bounce rates by 7%, and increased pages per session by 10% when they reduced average page load time by 850 milliseconds (14.2 secs). Here are a couple case studies where low performance had a negative impact on business goals: The BBC found they lost an additional 10% of users for every additional second their site took to load. DoubleClick by Google found 53% of mobile site visits were abandoned if a page took longer than 3 seconds to load.
• #26: Lagom and Play
• #27: LinkedIn – Green online indicators to show who’s online, 500+ million users, used the Play Framework and the Akka Actor Model to build the massive infrastructure that keeps track of the online status of millions of members at any given moment, distributes thousands of changes per second in the online status of these members to millions of other connected members in real time Walmart - After rebuilding its web application and mobile stack with Scala, Akka and Play, Walmart Canada experiences faster development and improved scalability, Boosts Conversions By 20% William Hill - quickly building a set of tools at the data layer, to create a foundation for long term success in personalization features and functionality. Hootsuite – 2.2 Billion Clicks And Beyond: How Hootsuite Modernized Its URL Shortener To Scala/Akka Using The Lightbend Reactive Platform Groupon - How Groupon Scales Personalized Offers To 48 Million Customers On Time