Performance demands placed on the web applications we build have drastically increased over the past few years. The Reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. Speed is everything.
Reactive applications and Reactive programming are an alternative to the standard thread-based imperative programming model that can result in flexible, concise code. However, it can be difficult to shift one’s mind to think in Reactive terms. It doesn’t help that the descriptions around the web can be contradictory and the library documentation can be obscure.
In this talk, we’ll explore the concepts of Reactive and Reactive Programming. We’ll demonstrate some of the useful Reactive functions and examine some practical implementations – including how we’re currently using Reactive libraries in production code. Most importantly, we’ll look at some of the open source options available to us in the Groovy community, including Reactor, RxJava, and the Java 8 stream API. If Reactive is new to you, this should be an excellent introduction.
Springone2gx 2015 Reactive Options for GroovySteve Pember
Reactive applications and Reactive programming are an alternative to the standard thread-based imperative programming model that can result in flexible, concise code. The Reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in Reactive terms. It doesn’t help that the descriptions around the web can be contradictory and the library documentation can be obscure. In this talk, we’ll explore the concepts of Reactive and Reactive Programming. We’ll demonstrate some of the useful Reactive functions and examine some practical implementations - including how we’re currently using Reactive libraries in production code. Most importantly, we’ll look at some of the open source options available to us in the Groovy community, including Reactor, RxJava, and Ratpack. If Reactive is new to you, this should be an excellent introduction.
Gr8conf US 2015: Reactive Options for GroovySteve Pember
Reactive applications and Reactive programming are an alternative to the standard thread-based imperative programming model that can result in flexible, concise code. The Reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in Reactive terms. It doesn’t help that the descriptions around the web can be contradictory and the library documentation can be obscure.
In this talk, we’ll explore the concepts of Reactive and Reactive Programming. We’ll demonstrate some of the useful Reactive functions and examine some practical implementations - including how we’re currently using Reactive libraries in production code. Most importantly, we’ll look at some of the open source options available to us in the Groovy community, including Reactor, RxJava, and the Java 8 stream API. If Reactive is new to you, this should be an excellent introduction.
An introduction to Reactive applications, Reactive Streams, and options for t...Steve Pember
The term “reactive” has lately become a buzzword, with a variety of definitions around the Web. When you hear “reactive,” what do you think of? Reactive Streams? The Reactive Manifesto? ReactJS? These terms may seem unrelated, but they share a common core concept.
Reactive applications and Reactive programming result in flexible, concise, performant code and are a superior alternative to the old, standard thread-based imperative programming model. The Reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in Reactive terms due to how accustomed we’ve become to the imperative style.
Stephen Pember explores the various definitions of Reactive and Reactive programming with the goal of providing techniques for building efficient, scalable applications. Steve dives into the key concepts of Reactive Streams and examines some sample implementations—including how ThirdChannel is currently using reactive libraries in production code. Steve looks at some of the open source options available in the JVM—including Reactor, RxJava, and Ratpack—giving you an idea of where to begin with the reactive ecosystem. If Reactive is new to you, this should be an excellent introduction.
Reactive Streams and the Wide World of GroovySteve Pember
The concept of Reactive Streams (aka Reactive Extensions, Reactive Functional Programming, or simply Rx) has become increasingly popular recently, and with good reason. The Reactive Streams specification provides a universal abstraction for asynchronously processing data received across multiple sources (e.g. database, user input, third-party services), and includes mechanisms for controlling the rate at which data is received. This makes it a powerful tool within a Microservice platform. And did we mention that the Groovy lang community is quite involved?
In this talk we’ll explore the various features and concepts of Reactive Streams. We’ll talk about some typical use cases for Rx and more importantly, how to implement them. We’ll focus primarily on RxGroovy and Ratpack, then provide example implementations that show you how to get started with this powerful technique.
An Introduction to Reactive Application, Reactive Streams, and options for JVMSteve Pember
The term “reactive” has lately become a buzzword, with a variety of definitions around the Web. When you hear reactive, what do you think of? Reactive Streams? The Reactive Manifesto? ReactJS? These terms may seem unrelated, but they share a common core concept.
Reactive applications and reactive programming result in flexible, concise, performant code and are a superior alternative to the old standard thread-based imperative programming model. The reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in reactive terms due to how accustomed we’ve become to the imperative style.
Stephen Pember explores the various definitions of reactive and reactive programming with the goal of providing techniques for building efficient, scalable applications. Steve dives into the key concepts of Reactive Streams and examines some sample implementations—including how ThirdChannel is currently using reactive libraries in production code. Steve looks at some of the open source options available in the JVM—including Reactor, RxJava, and Ratpack—giving attendees an idea of where to begin with the reactive ecosystem. If reactive is new to you, this should be an excellent introduction.
Are you tired of Hibernate? Is GORM is too heavy for your current project? Do you like having more control over your SQL? Do you like flexible DSLs? Try JOOQ!
JOOQ (Java Object Oriented Querying) is light-weight alternative to classic data access solutions or ORMs like Hibernate, JPA, JDBC, and GORM. JOOQ's goal is to give the developer a flexible DSL for building typesafe, database agnostic SQL queries, and attempts to convince the developer of a ‘database-first’ approach to building their application. In this talk we’ll quickly present an introduction to JOOQ from a high level, discuss its features, and see several examples of how we’re using JOOQ to great effect with many Spring Boot and Ratpack apps within our platform.
The basics you need to know to get up and running with Chaos Monkey in your Amazon Web Service's Cloud enviornment.
Links:
CloudFormation Template:
https://github.com/joehack3r/aws/blob/master/cloudformation/templates/chaosMonkey.json
Simian Army Quick Start Guide:
https://github.com/Netflix/SimianArmy/wiki/Quick-Start-Guide
Chaos Monkey Configuration:
https://github.com/Netflix/SimianArmy/wiki/Chaos-Settings
Chaos Monkey Army:
https://github.com/Netflix/SimianArmy/wiki/The-Chaos-Monkey-Army
Springone2gx 2015 Reactive Options for GroovySteve Pember
Reactive applications and Reactive programming are an alternative to the standard thread-based imperative programming model that can result in flexible, concise code. The Reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in Reactive terms. It doesn’t help that the descriptions around the web can be contradictory and the library documentation can be obscure. In this talk, we’ll explore the concepts of Reactive and Reactive Programming. We’ll demonstrate some of the useful Reactive functions and examine some practical implementations - including how we’re currently using Reactive libraries in production code. Most importantly, we’ll look at some of the open source options available to us in the Groovy community, including Reactor, RxJava, and Ratpack. If Reactive is new to you, this should be an excellent introduction.
Gr8conf US 2015: Reactive Options for GroovySteve Pember
Reactive applications and Reactive programming are an alternative to the standard thread-based imperative programming model that can result in flexible, concise code. The Reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in Reactive terms. It doesn’t help that the descriptions around the web can be contradictory and the library documentation can be obscure.
In this talk, we’ll explore the concepts of Reactive and Reactive Programming. We’ll demonstrate some of the useful Reactive functions and examine some practical implementations - including how we’re currently using Reactive libraries in production code. Most importantly, we’ll look at some of the open source options available to us in the Groovy community, including Reactor, RxJava, and the Java 8 stream API. If Reactive is new to you, this should be an excellent introduction.
An introduction to Reactive applications, Reactive Streams, and options for t...Steve Pember
The term “reactive” has lately become a buzzword, with a variety of definitions around the Web. When you hear “reactive,” what do you think of? Reactive Streams? The Reactive Manifesto? ReactJS? These terms may seem unrelated, but they share a common core concept.
Reactive applications and Reactive programming result in flexible, concise, performant code and are a superior alternative to the old, standard thread-based imperative programming model. The Reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in Reactive terms due to how accustomed we’ve become to the imperative style.
Stephen Pember explores the various definitions of Reactive and Reactive programming with the goal of providing techniques for building efficient, scalable applications. Steve dives into the key concepts of Reactive Streams and examines some sample implementations—including how ThirdChannel is currently using reactive libraries in production code. Steve looks at some of the open source options available in the JVM—including Reactor, RxJava, and Ratpack—giving you an idea of where to begin with the reactive ecosystem. If Reactive is new to you, this should be an excellent introduction.
Reactive Streams and the Wide World of GroovySteve Pember
The concept of Reactive Streams (aka Reactive Extensions, Reactive Functional Programming, or simply Rx) has become increasingly popular recently, and with good reason. The Reactive Streams specification provides a universal abstraction for asynchronously processing data received across multiple sources (e.g. database, user input, third-party services), and includes mechanisms for controlling the rate at which data is received. This makes it a powerful tool within a Microservice platform. And did we mention that the Groovy lang community is quite involved?
In this talk we’ll explore the various features and concepts of Reactive Streams. We’ll talk about some typical use cases for Rx and more importantly, how to implement them. We’ll focus primarily on RxGroovy and Ratpack, then provide example implementations that show you how to get started with this powerful technique.
An Introduction to Reactive Application, Reactive Streams, and options for JVMSteve Pember
The term “reactive” has lately become a buzzword, with a variety of definitions around the Web. When you hear reactive, what do you think of? Reactive Streams? The Reactive Manifesto? ReactJS? These terms may seem unrelated, but they share a common core concept.
Reactive applications and reactive programming result in flexible, concise, performant code and are a superior alternative to the old standard thread-based imperative programming model. The reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in reactive terms due to how accustomed we’ve become to the imperative style.
Stephen Pember explores the various definitions of reactive and reactive programming with the goal of providing techniques for building efficient, scalable applications. Steve dives into the key concepts of Reactive Streams and examines some sample implementations—including how ThirdChannel is currently using reactive libraries in production code. Steve looks at some of the open source options available in the JVM—including Reactor, RxJava, and Ratpack—giving attendees an idea of where to begin with the reactive ecosystem. If reactive is new to you, this should be an excellent introduction.
Are you tired of Hibernate? Is GORM is too heavy for your current project? Do you like having more control over your SQL? Do you like flexible DSLs? Try JOOQ!
JOOQ (Java Object Oriented Querying) is light-weight alternative to classic data access solutions or ORMs like Hibernate, JPA, JDBC, and GORM. JOOQ's goal is to give the developer a flexible DSL for building typesafe, database agnostic SQL queries, and attempts to convince the developer of a ‘database-first’ approach to building their application. In this talk we’ll quickly present an introduction to JOOQ from a high level, discuss its features, and see several examples of how we’re using JOOQ to great effect with many Spring Boot and Ratpack apps within our platform.
The basics you need to know to get up and running with Chaos Monkey in your Amazon Web Service's Cloud enviornment.
Links:
CloudFormation Template:
https://github.com/joehack3r/aws/blob/master/cloudformation/templates/chaosMonkey.json
Simian Army Quick Start Guide:
https://github.com/Netflix/SimianArmy/wiki/Quick-Start-Guide
Chaos Monkey Configuration:
https://github.com/Netflix/SimianArmy/wiki/Chaos-Settings
Chaos Monkey Army:
https://github.com/Netflix/SimianArmy/wiki/The-Chaos-Monkey-Army
DevOps Pipelines and Metrics Driven Feedback LoopsAndreas Grabner
The goal behind devops is Faster Lead Times
What this really means for Software Delivery -> my Kodak/Smart Phone Analogy
How and Which Metrics to use along the Delivery Pipeline to make better decisions along the way.
Talk given at DevTeach Montreal on RxJS - The Basics & The Future.
Example repo: https://github.com/ladyleet/rxjs-test
Have questions? Find me on twitter http://twitter.com/ladyleet
One of the most common performance issues in serverless architectures is elevated latencies from external services, such as DynamoDB, ElasticSearch or Stripe.
In this webinar, we will show you how to quickly identify and debug these problems, and some best practices for dealing with poor performing 3rd party services.
Web and App Performance: Top Problems to avoid to keep you out of the NewsAndreas Grabner
As presented at Boston and NYC Web Perf Meetup.
Its time to level up Web Performance Optimization started by Steve Souders. We need to look beyond the rim of the browser as there are many problems happenig from browser to database.
In this presentation I showed how Browser Diagnostics needs to evolve into End-to-End Application Diagnostics and Monitoring. Showing 5 real life examples on why applications failed and the metrics to look at to identify these problems early on
OOP 2016 - Building Software That Eats The WorldAndreas Grabner
According to VC and web pioneer Marc Andreessen software is eating the world. Evidence proves he is right. Uber, the biggest taxi company, has no cars, AirBnB, the biggest hotel service, has no rooms and there are many more examples. Looking at these success stories there is a clear blueprint how to build software that eats the world. Just a quick heads up: It is not about building your typical web application any more.
Reactive programming and Hystrix fault tolerance by Max MyslyvtsevJavaDayUA
Reactive programming is a new paradigm that provides asynchronous event-based flow control. Java implementation is called rxJava and is being developed by Netfix. They have also released Hystrix — a non-functional layer that provides fault tolerance and latency features which also exposes reactive API.
OnAndroidConf 2013: Accelerating the Android Platform BuildDavid Rosen
Presented at the OnAndroidConf, October 22 2013, http://www.onandroidconf.com/sessions.html
Abstract:
Optimizing the Android build environment to perform at world-class level is a big challenge for many Android device and chipset makers today. Churning through thousands of platform builds per week requires laser-focus on high-performance infrastructure and tooling. If you’re looking at improving your overall engineering and developer productivity, the software build use case is an obvious area to prioritize.
This technical talk will focus on the following aspects of the Android platform build:
Common Android platform build challenges and opportunities with real-life production references
The various Android build use cases and their needs – full integration and release builds, developer incremental builds
Evolution of the Android build and codebase with trends and statistics
Detailed technical analysis of the Android platform build, highlighting opportunities for improvements
Proposed solutions and technical tricks to optimize an Android software build environment
On a Big Data project, validating a promising idea through a prototype is a crucial step. Moving from a prototype to a production-ready application is another one.
Discover how Capgemini has implemented Apache Spark to build People Analytics, a Big Data Analytics platform dedicated to human resources departments.
Learn from our experience, code and best practices to strengthen the reliability, performances and maintainability of your application.
How to keep you out of the News: Web and End-to-End Performance TipsAndreas Grabner
Too many websites make it too the news when they fail to deliver, e.g: eCommerce when they go down on Cyber Monday, Tax Software on Tax Day or Online Banking when people want to check on their latest pay check.
In this presentation - presented at several Web Performance, Java, .NET, ... Meetups I walk through the most common performance mistakes people made in recent history. I explain in technical detail what the problem was and how to find these problems earlier as you dont want to wait until your site crashes and you end up in the news.
Hugs instead of Bugs: Dreaming of Quality Tools for Devs and TestersAndreas Grabner
I have a Dream that Testers extend their horizon and toolsets and not only test for functional correctness but make a step towards what developers need in order to fix critical issues. I am talking about architectural, scalability and performance metrics such as # of JS Files on a page, Page Size, # of SQL Statements, # of Log Messages Written.
If Testers start to capture this information as well and share it with their bug description I am sure it will both increase the value of testers as well as reduce the total time it takes to fix problems.
This is from an invited talk I gave at the Pittsburgh Perl Workshop a few years back. It's not often that I get a chance to talk to developers, so I thought I'd take advantage of it and yell at them a bit ;-)
Boston DevOps Days 2016: Implementing Metrics Driven DevOps - Why and HowAndreas Grabner
How can we detect a bad deployment before it hits production? By automatically looking at the right architectural metrics in your CI/CD and stop a build before its too late. Lets hook up your test automation with app metrics and use them as quality gates to stop bad builds early!
Reactive applications & reactive programming result in flexible, concise, performant code and are a superior alternative to the old thread-based programming model. The reactive approach has gained popularity for a simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in reactive terms, particularly when one realizes that we must be Reactive up and down the entire programming stack.
In this talk we’ll explore what it means to be ‘Reactive’. We’ll examine some of the more interesting tools available to us, some of which come from the Groovy community. Specifically we’ll cover Ratpack, RxGroovy, React, and RabbitMq - along with examples and a sample implementation. We’ll demonstrate how effectively they can work together at each level of the stack - from the front end, to the back end, to handling http requests and message queue events - and how easy it can be to go Reactive all the way down.
DevOps Pipelines and Metrics Driven Feedback LoopsAndreas Grabner
The goal behind devops is Faster Lead Times
What this really means for Software Delivery -> my Kodak/Smart Phone Analogy
How and Which Metrics to use along the Delivery Pipeline to make better decisions along the way.
Talk given at DevTeach Montreal on RxJS - The Basics & The Future.
Example repo: https://github.com/ladyleet/rxjs-test
Have questions? Find me on twitter http://twitter.com/ladyleet
One of the most common performance issues in serverless architectures is elevated latencies from external services, such as DynamoDB, ElasticSearch or Stripe.
In this webinar, we will show you how to quickly identify and debug these problems, and some best practices for dealing with poor performing 3rd party services.
Web and App Performance: Top Problems to avoid to keep you out of the NewsAndreas Grabner
As presented at Boston and NYC Web Perf Meetup.
Its time to level up Web Performance Optimization started by Steve Souders. We need to look beyond the rim of the browser as there are many problems happenig from browser to database.
In this presentation I showed how Browser Diagnostics needs to evolve into End-to-End Application Diagnostics and Monitoring. Showing 5 real life examples on why applications failed and the metrics to look at to identify these problems early on
OOP 2016 - Building Software That Eats The WorldAndreas Grabner
According to VC and web pioneer Marc Andreessen software is eating the world. Evidence proves he is right. Uber, the biggest taxi company, has no cars, AirBnB, the biggest hotel service, has no rooms and there are many more examples. Looking at these success stories there is a clear blueprint how to build software that eats the world. Just a quick heads up: It is not about building your typical web application any more.
Reactive programming and Hystrix fault tolerance by Max MyslyvtsevJavaDayUA
Reactive programming is a new paradigm that provides asynchronous event-based flow control. Java implementation is called rxJava and is being developed by Netfix. They have also released Hystrix — a non-functional layer that provides fault tolerance and latency features which also exposes reactive API.
OnAndroidConf 2013: Accelerating the Android Platform BuildDavid Rosen
Presented at the OnAndroidConf, October 22 2013, http://www.onandroidconf.com/sessions.html
Abstract:
Optimizing the Android build environment to perform at world-class level is a big challenge for many Android device and chipset makers today. Churning through thousands of platform builds per week requires laser-focus on high-performance infrastructure and tooling. If you’re looking at improving your overall engineering and developer productivity, the software build use case is an obvious area to prioritize.
This technical talk will focus on the following aspects of the Android platform build:
Common Android platform build challenges and opportunities with real-life production references
The various Android build use cases and their needs – full integration and release builds, developer incremental builds
Evolution of the Android build and codebase with trends and statistics
Detailed technical analysis of the Android platform build, highlighting opportunities for improvements
Proposed solutions and technical tricks to optimize an Android software build environment
On a Big Data project, validating a promising idea through a prototype is a crucial step. Moving from a prototype to a production-ready application is another one.
Discover how Capgemini has implemented Apache Spark to build People Analytics, a Big Data Analytics platform dedicated to human resources departments.
Learn from our experience, code and best practices to strengthen the reliability, performances and maintainability of your application.
How to keep you out of the News: Web and End-to-End Performance TipsAndreas Grabner
Too many websites make it too the news when they fail to deliver, e.g: eCommerce when they go down on Cyber Monday, Tax Software on Tax Day or Online Banking when people want to check on their latest pay check.
In this presentation - presented at several Web Performance, Java, .NET, ... Meetups I walk through the most common performance mistakes people made in recent history. I explain in technical detail what the problem was and how to find these problems earlier as you dont want to wait until your site crashes and you end up in the news.
Hugs instead of Bugs: Dreaming of Quality Tools for Devs and TestersAndreas Grabner
I have a Dream that Testers extend their horizon and toolsets and not only test for functional correctness but make a step towards what developers need in order to fix critical issues. I am talking about architectural, scalability and performance metrics such as # of JS Files on a page, Page Size, # of SQL Statements, # of Log Messages Written.
If Testers start to capture this information as well and share it with their bug description I am sure it will both increase the value of testers as well as reduce the total time it takes to fix problems.
This is from an invited talk I gave at the Pittsburgh Perl Workshop a few years back. It's not often that I get a chance to talk to developers, so I thought I'd take advantage of it and yell at them a bit ;-)
Boston DevOps Days 2016: Implementing Metrics Driven DevOps - Why and HowAndreas Grabner
How can we detect a bad deployment before it hits production? By automatically looking at the right architectural metrics in your CI/CD and stop a build before its too late. Lets hook up your test automation with app metrics and use them as quality gates to stop bad builds early!
Reactive applications & reactive programming result in flexible, concise, performant code and are a superior alternative to the old thread-based programming model. The reactive approach has gained popularity for a simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in reactive terms, particularly when one realizes that we must be Reactive up and down the entire programming stack.
In this talk we’ll explore what it means to be ‘Reactive’. We’ll examine some of the more interesting tools available to us, some of which come from the Groovy community. Specifically we’ll cover Ratpack, RxGroovy, React, and RabbitMq - along with examples and a sample implementation. We’ll demonstrate how effectively they can work together at each level of the stack - from the front end, to the back end, to handling http requests and message queue events - and how easy it can be to go Reactive all the way down.
Patterns of the Lambda Architecture -- 2015 April - Hadoop Summit, EuropeFlip Kromer
This talk centers on two things: a set of patterns for the architecture of high-scale data systems; and a framework for understanding the tradeoffs we make in designing them.
Building Highly Available Apps on Cassandra (Robbie Strickland, Weather Compa...DataStax
Cassandra was built from the ground up to enable linearly scalable, always-on applications. But the path to high availability has many land mines that can mean failure for the inexperienced user. In this talk, I will offer practical advice on how to achieve 100% uptime on millions of transactions per second. I'll address all aspects of the topic, including deployment, configuration, application design, and operations.
About the Speaker
Robbie Strickland VP, Software Engineering, The Weather Company (IBM)
Robbie works for The Weather Company, leading the team that builds data analysis services for the digital business, serving the likes of weather.com, Weather Underground, and the TWC mobile apps. He has been involved in the Cassandra project since 2010 and has contributed in a variety of ways over the years, including work on drivers for Scala and C#, the Hadoop and Spark integrations, heading up the Atlanta Cassandra Users Group, and answering lots of Stack Overflow questions.
MODELS 2019: Querying and annotating model histories with time-aware patternsAntonio García-Domínguez
30 minute slides for our talk at the IEEE / ACM 22nd International Conference on Model Driven Engineering Languages and Systems conference, on our Eclipse Hawk model indexing tool.
The Reactive Extensions (Rx) is a library for composing asynchronous and event-based programs using observable sequences and LINQ-style query operators. Here is an overview of Rx with examples at the end.
Beyond fault tolerance with actor programming - Fabio Tiriticco - Codemotion ...Codemotion
The Actor model has been around for a while, but only the Reactive revolution is bringing it to trend. Find out how your application can benefit from Actors to achieve Resilience - the ability to spring back into shape from a failure state. Akka is a toolkit that brings Actors to the JVM - think Java or Scala - and that leverages on them to help you build concurrent, distributed and resilient applications.
Beyond Fault Tolerance with Actor ProgrammingFabio Tiriticco
Actor Programming is a software building approach that lets you can go beyond fault tolerance and achieve Resilience, which is the capacity of a system to self-heal and spring back into a fresh shape. First I'll introduce the difference between Reactive Programming and Reactive Systems, and then we'll go over a couple of implementation examples using Scala and Akka.
The coupled GitHub repository with the code is here: https://github.com/ticofab/ActorDemo
Patterns of the Lambda Architecture -- 2015 April -- Hadoop Summit, EuropeFlip Kromer
This talk centers on two things: a set of patterns for the architecture of high-scale data systems; and a framework for understanding the tradeoffs we make in designing them.
Mary Grygleski and myself, gave a very successful workshop to 51 attendees in NYC on April 15th - here is the updated presentation
https://www.linkedin.com/in/mary-grygleski/
https://www.linkedin.com/in/grant-steinfeld/
Go Reactive: Building Responsive, Resilient, Elastic & Message-Driven SystemsJonas Bonér
Abstract:
The demands and expectations for applications have changed dramatically in recent years. Applications today are deployed on a wide range of infrastructure; from mobile devices up to thousands of nodes running in the cloud—all powered by multi-core processors. They need to be rich and collaborative, have a real-time feel with millisecond response time and should never stop running. Additionally, modern applications are a mashup of external services that need to be consumed and composed to provide the features at hand.
We are seeing a new type of applications emerging to address these new challenges—these are being called Reactive Applications. In this talk we will discuss four key traits of Reactive; Responsive, Resilient, Elastic and Message-Driven—how they impact application design, how they interact, their supporting technologies and techniques, how to think when designing and building them—all to make it easier for you and your team to Go Reactive.
Intended Audience:
Programmers, architects, CIO/CTOs and everyone with a desire to challenge the status quo and expand their horizons on how to tackle the current and future challenges in the computing industry.
While developing distributed apps, most teams are focused in delivery of business value. Sometimes, after production deployment, a few moments later, we realize that exceptions arise, time-outs blow. The system need more fault tolerance. Presentations overviews a few patterns and principles of fault and latency tolerance for such systems.
Aim of this presentation is not to make you masters in Java 8 Concurrency, but to help you guide towards that goal. Sometimes it helps just to know that there is some API that might be suitable for a particular situation. Make use of the pointers given to search more and learn more on those topics. Refer to books, Java API Documentation, Blogs etc. to learn more. Examples and demos for all cases discussed will be added to my blog www.javajee.com.
Spring I_O 2024 - Flexible Spring with Event Sourcing.pptxSteve Pember
Event Sourcing is a modern but non-trivial data model for building scalable and powerful systems. Instead of mapping a single Entity to a single row in a datastore, in an Event Sourced system we persist all changes for an Entity in an append-only journal. This design provides a wealth of benefits: a built-in Audit Trail, Time-Based reporting, powerful Error Recovery, and more. It creates flexible, scalable systems and can easily evolve to meet changing organizational demands. That is, once you have some experience with it. Event Sourcing is straightforward in concept, but it does bring additional complexity and a learning curve that can be intimidating. People coming from traditional ORM systems often wonder: how does one model relations between Entities? How is Optimistic Locking handled? What about datastore constraints?
Based on over eight years of experience with building ES systems in Spring applications, we will demonstrate the basics of Event Sourcing and some of the common patterns. We will see how simple it can be to model events with available tools like Spring Data JPA, JOOQ, and the integration between Spring and Axon. We’ll walk through sample code in an application that demonstrates many of these techniques. However, it’s also not strictly about the code; we’ll see how a process called Event Modeling can be a powerful design tool to align Subject Matter Experts, Product, and Engineering. Attendees will leave with an understanding of the basic Event Sourcing patterns, and hopefully a desire to start creating their own Journals.
Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023Steve Pember
In this presentation we will present the general philosophy of Clean Architecture, Hexagonal Architecture, and Ports & Adapters: discussing why these approaches are useful and general guidelines for introducing them to your code. Chiefly, we will show how to implement these patterns within your Spring (Boot) Applications. Through a publicly available reference app, we will demonstrate what these concepts can look like within Spring and walkthrough a handful of scenarios: isolating core business logic, ease of testing, and adding a new feature or two.
SACon 2019 - Surviving in a Microservices EnvironmentSteve Pember
Many presentations on microservices offer a high-level view of the architecture; rarely do you hear what it’s like to work in such an environment. Stephen Pember shares his experience migrating from a monolith to microservices across several companies, highlighting the mistakes made along the way and offering advice.
Surviving in a Microservices environment -abridgedSteve Pember
Many presentations on Microservices offer a high-level view; rarely does one hear what it’s like to work in such an environment. Individual services are somewhat trivial to develop, but now you suddenly have countless others to track. You’ll become obsessed over how they communicate. You’ll have to start referring to the whole thing as “the Platform”. You will have to take on some considerable DevOps work and start learning about deployment pipelines, metrics, and logging.
Don’t panic. In this presentation we’ll discuss what we learned over the past four years by highlighting our mistakes. We’ll examine what a development lifecycle might look like for adding a new service, developing a feature, or fixing bugs. We’ll see how team communication is more important than one might realize. Most importantly, we’ll show how - while an individual service is simple - the infrastructure demands are now much more complicated: your organization will need to introduce and become increasingly dependent on various technologies, procedures, and tools - ranging from the ELK stack to Grafana to Kubernetes. Lastly, you’ll come away with the understanding that your resident SREs will become the most valued members of your team.
Over the past few years, Gradle has become a popular build tool in the JVM space. This is not surprising, considering the power and the features it brings, compared with its competitors. However, one thing Gradle lacks is history and the collective knowledge at the same level of other alternatives: how does one organize a Gradle project in an ‘idiomatic’ fashion?
We feel that we’ve put together a decent build pipeline for each of our microservices over the years, and each one starts with their build.gradle file(s). We’d like to share it, although we’re not sure if it’s the ‘correct’ way.
In this talk, we’ll walk through a sample project structure and build process. We’ll discuss the various checks and tools we use (e.g. Sonar, CodeNarc, Jenkins) at each step of the build. We’ll explain how each of the components in the process work for us, and share samples of our Groovy scripts. Most importantly, though, we’d like to hear what the audience are using in their builds!
Many presentations on Microservices offer a high level view; rarely does one hear what it’s like to work in such an environment. Individual services are somewhat trivial to develop, but now you suddenly have countless others to track. You’ll become obsessed over how they communicate. You’ll have to start referring to the whole thing as “the Platform”. You will have to take on some DevOps work and start learning about deployment pipelines, metrics, and logging.
Don’t panic. In this presentation we’ll discuss what we, at ThirdChannel, learned over the past four years. We’ll examine what a development lifecycle might look like for adding a new service, developing a feature, or fixing bugs. We’ll dive a bit into DevOps and see how one will become dependent on various metric and centralized logging tools, like Kubernetes and the ELK stack. Finally we’ll talk about team communication and organization… and how they are likely the most important tool for surviving a Microservices development team.
Event storage offers many practical benefits to distributed systems providing complete state changes over time, but there are a number of challenges when building an event store mechanism. Stephen Pember explores some of the problems you may encounter and shares real-world patterns for working with event storage.
Harnessing Spark and Cassandra with GroovySteve Pember
This talk is an introduction to a powerful combination in the big data space: Apache Spark and Cassandra. Spark is a cluster-computing framework that allows users to perform calculations against resilient in-memory datasets using a functional programming interface. Cassandra is a linearly scalable, fault tolerant, decentralized datastore. These two technologies are complicated, but integrate well and provide such a level of utility that whole companies have formed around them.
In this talk we’ll learn how Spark and Cassandra can be leveraged within your Groovy Application: Spark normally asks for a Scala environment. We’ll talk about Spark and Cassandra from a high level and walk through code examples. We’ll discuss the pitfalls of working with these technologies - like modeling your data appropriately to ensure even distribution in Cassandra and general packaging woes with Spark - and ways to avoid them. Finally, we’ll explore how we at ThirdChannel are using these technologies.
Surviving in a microservices environmentSteve Pember
Many presentations on Microservices offer a high level view; rarely does one hear what it’s like to work in such an environment. Individual services are somewhat trivial to develop, but now you suddenly have countless others to track. You’ll become obsessed over how they communicate. You’ll have to start referring to the whole thing as “the Platform”. You will have to take on some DevOps work and start learning about deployment pipelines, metrics, and logging.
Don’t panic. In this presentation we’ll discuss what we learned over the past three years. We’ll examine what a development lifecycle might look like for adding a new service, developing a feature, or fixing bugs. We’ll dive a bit into DevOps and see how one will become dependent on various metric and centralized logging tools, like Kubernetes and the ELK stack. Finally we’ll talk about team communication and organization... and how they are likely the most important tool for surviving a Microservices development team.
Surviving in a Microservices EnvironmentSteve Pember
Cloud Native Microservice architectures have become increasingly popular over the past few years, and for good reasons: smaller, efficient codebases, finely targeted scaling options, and the ability to do continuous deployment along with continuous integration, among others. All potentially very powerful features. However - as with most things - Microservices bring tradeoffs in terms of application complexity: working with an individual service is easy; overall application development becomes increasingly complex. Perhaps too complex for your average web application.
Many presentations on the Microservice phenomena offer either a high level view on what it is, compare and contrast it with the Monolith pattern, or discuss how to migrate from a Monolith to Microservices, but rarely does one hear what it’s like to actually work in such an environment. Frankly, it can be intimidating for someone accustomed to a traditional monolithic development experience. Individual services are somewhat trivial to develop, but now you suddenly have countless others to keep track of. You may become lost: with all these services, is anyone directing the overall development? You’ll become obsessed over how and when they communicate. You’ll have to start referring to the application on the whole as “the Platform”. It’ll soon become difficult or even impossible to run the whole Platform on a development laptop. You may even have to take on some DevOps work, and start learning about deployment pipelines, and whole new worlds of metrics and logging.
Don’t panic. In this presentation we’ll discuss what we learned working with a Microservice platform for the past three years. We’ll cover what to expect when joining a Microservice team and what the situation will look like as the team size grows. We’ll see how critical inter-service testing strategies are to the success of the team. We’ll examine what a development lifecycle might look like for adding a new service, developing a new feature, or fixing bugs. We’ll dive a bit into DevOps and see how one will become dependent and various metric and centralized logging tools, like Kubernetes and the ELK stack. Finally we’ll talk about communication, team organization strategies, and how they are likely the most important tool for surviving a Microservices development team.
As businesses grow, so does the complexity of their software. New features, new models, and new background processes all continue to be added. . .and developers struggle to make sense of it all. Yet the end user demands a swift and functional experience when interacting with your application. It is paramount to be open to alternative patterns that help tame complex, high-demand services. Two such patterns are command-query responsibility segregation (CQRS) and event sourcing (ES).
Command-query responsibility segregation is an architectural pattern for user-facing applications that extends from the now standard Model-View-Controller (MVC) pattern and is an alternative to the CRUD pattern. At its core, CQRS is about changing how we think of and work with our data by introducing two types of models: all user actions become commands, and a read-only query model powers our views. Commands and queries are logistically separated, providing additional decoupling of our application. CQRS also calls for changes in how we store and structure our data.
Enter event sourcing. Instead of persisting the current state of our domain objects or entities, we record historical events about our data. The key advantage is that we can examine our application data at any point in time, rather than just the current state. This pattern changes how we persist and process our data but is surprisingly efficient.
While each of the two patterns can be used exclusively, they complement each other beautifully and facilitate the construction of decoupled, scalable applications or individual services. Stephen Pember explores the fundamentals of each pattern and offers several examples and demonstration code to show how one might actually go about implementing CQRS and ES. Steve discusses task-based UIs and domain-driven design as he outlines some of the advantages—and challenges—that ThirdChannel has seen when developing systems using CQRS and ES over the past year.
Richer Data History with Event Sourcing (SpringOne 2GX 2015Steve Pember
A common pattern in application development is to build systems where the data is directly linked to the current state of the application; one row in the database equates to one entity’s current state. Only ever knowing the current state of the data is adequate for many systems, but imagine the possibilities if one had access to the state of the data at any point in time. Enter Event Sourcing: instead of persisting the current state of our Domain Objects or Entities, we record historical events about our data. This pattern changes how we persist and process our data, but is surprisingly lightweight. In this talk I will present the basic concepts of Event Sourcing and the positive effects it can have on analytics and performance. We’ll discuss how storing historical events provides extremely powerful views into our data at any point in time. We’ll see how naturally it couples with the Event-oriented world of modern Reactive systems, and how easily it can be implemented in Groovy. We’ll examine some practical use cases and example implementations in Ratpack. Event Sourcing will change how you think about your data.
Gr8conf US 2015 - Intro to Event Sourcing with GroovySteve Pember
As Grails developers we generally build systems where our data is directly linked to the current state of our application; one row in the database equates to one entity’s current state. Only ever knowing the current state of the data is adequate for many systems, but imagine the possibilities if one had access to the state of the data at any point in time.
Enter Event Sourcing: instead of persisting the current state of our Domain Objects, we store historical events about our data. This pattern changes how we store and process our data, but is surprisingly lightweight and performant. In this talk I will present the basic concepts of Event Sourcing and the positive effects it can have on analytics and performance. We’ll see how naturally it couples with the Event-oriented world of modern Reactive systems, and how easily it can be implemented in Groovy. We’ll examine some practical use cases and example implementations. Event Sourcing will change how you think about your data.
With the rise of opinionated, full-featured frameworks and Object-Relational Mappers, we – as software developers – will generally build systems where our data is directly linked to the current state of our application; one row in the database equates to one entity’s state within the system. Only ever knowing the current state of the data is adequate for many systems, but imagine the possibilities if one had access to the states of all entities at any given time, and how that state was reached. It is just as important to understand the current state as it is to understand the steps that it took to reach the current state.
Enter Event Sourcing: instead of persisting the current state of our entities, we store historical events about our data. This pattern changes how we store and process our data, but is surprisingly lightweight and performant. In this talk I will present the basic concepts behind Event Sourcing and the positive implications it has on usability, visualization, and analytics within our applications. We’ll see how naturally it couples with the Event-oriented world of Reactive systems. Finally, we’ll examine some practical use cases and when one should and should not consider implementing the pattern. Event Sourcing will completely change how you think about your data.
Managing a Microservices Development Team (And advanced Microservice concerns)Steve Pember
So you’re decided to make the transition to a Microservice Architecture. You’ve spent time doing the research. You’ve designed out the responsibilities of each service with your team. You’ve read and memorized the entire article Martin Fowler wrote on the subject. Now, you’re running a team that’s tasked with building some Microservices. You’re built or extracted your first services. You’ve been successfully transmitting data between these services. What next? What should you be aware of? What should keep you up at night?
In this talk we’ll begin with a brief introduction to the architecture pattern before covering some of the more advanced topics when developing Microservices, focusing primarily on team management and service design philosophy. We’ll discuss the CAP theorem and why it should be your obsession. We’ll look at how Conway’s Law should be taken seriously and how it can serve as a warning to facilitate better communication between teams. Finally we’ll examine some common pitfalls of Microservices architectures and how they can be mitigated.
Why Reactive Architecture Will Take Over The World (and why we should be wary...Steve Pember
The natural tendency for application developers is to construct their code in a procedural, monolithic pattern. Veteran Developers know that this leads to error prone, unscalable, slow software – yet it is alarmingly prevalent. There have been several architectural patterns that have risen over the years which have attempted to mitigate this problem. We’ve heard of Service Oriented Architecture, Integration Patterns, and Event-Driven Systems, but the Reactive pattern has the best chance for success.
In this talk I will discuss the tenants of the Reactive Pattern and the importance of moving away from Monolithic architectures into Reactive. We will examine Spring Integration and the Grails Async features (along with Netty and RabbitMQ) in order to show they can quickly and effectively help your application to become Reactive. Finally, I will argue that the JVM is the best foundation currently for this architecture – but that if we’re not careful, NodeJS may be the most popular.
Richer Data History in Groovy with Event SourcingSteve Pember
As Grails developers we reflexively lean on the default pattern for data storage: a single row represents the current state of a Domain Object. For most applications, only ever knowing the current state is just fine. However, understanding the manipulations that got your data to that state are just as important as the current state itself, especially in a large system with multiple users.
Enter Event Sourcing: instead of persisting the current state of our Domain Objects, we store historical events about our data. In this talk I will discuss the basic concepts of Event Sourcing. We will discuss the advantages – particularly around performance and analytics – and disadvantages of using this pattern. We will see how easily it can be implemented in Groovy and used within a Grails application. Finally, we’ll examine some practical use cases and when one would consider implementation.
Additionally, there's a code demo that is not covered in the slides, but can be found here:
https://github.com/spember/greach2014-es-demo
In software engineering, the right architecture is essential for robust, scalable platforms. Wix has undergone a pivotal shift from event sourcing to a CRUD-based model for its microservices. This talk will chart the course of this pivotal journey.
Event sourcing, which records state changes as immutable events, provided robust auditing and "time travel" debugging for Wix Stores' microservices. Despite its benefits, the complexity it introduced in state management slowed development. Wix responded by adopting a simpler, unified CRUD model. This talk will explore the challenges of event sourcing and the advantages of Wix's new "CRUD on steroids" approach, which streamlines API integration and domain event management while preserving data integrity and system resilience.
Participants will gain valuable insights into Wix's strategies for ensuring atomicity in database updates and event production, as well as caching, materialization, and performance optimization techniques within a distributed system.
Join us to discover how Wix has mastered the art of balancing simplicity and extensibility, and learn how the re-adoption of the modest CRUD has turbocharged their development velocity, resilience, and scalability in a high-growth environment.
Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...Mind IT Systems
Healthcare providers often struggle with the complexities of chronic conditions and remote patient monitoring, as each patient requires personalized care and ongoing monitoring. Off-the-shelf solutions may not meet these diverse needs, leading to inefficiencies and gaps in care. It’s here, custom healthcare software offers a tailored solution, ensuring improved care and effectiveness.
Cyaniclab : Software Development Agency Portfolio.pdfCyanic lab
CyanicLab, an offshore custom software development company based in Sweden,India, Finland, is your go-to partner for startup development and innovative web design solutions. Our expert team specializes in crafting cutting-edge software tailored to meet the unique needs of startups and established enterprises alike. From conceptualization to execution, we offer comprehensive services including web and mobile app development, UI/UX design, and ongoing software maintenance. Ready to elevate your business? Contact CyanicLab today and let us propel your vision to success with our top-notch IT solutions.
Innovating Inference - Remote Triggering of Large Language Models on HPC Clus...Globus
Large Language Models (LLMs) are currently the center of attention in the tech world, particularly for their potential to advance research. In this presentation, we'll explore a straightforward and effective method for quickly initiating inference runs on supercomputers using the vLLM tool with Globus Compute, specifically on the Polaris system at ALCF. We'll begin by briefly discussing the popularity and applications of LLMs in various fields. Following this, we will introduce the vLLM tool, and explain how it integrates with Globus Compute to efficiently manage LLM operations on Polaris. Attendees will learn the practical aspects of setting up and remotely triggering LLMs from local machines, focusing on ease of use and efficiency. This talk is ideal for researchers and practitioners looking to leverage the power of LLMs in their work, offering a clear guide to harnessing supercomputing resources for quick and effective LLM inference.
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...Juraj Vysvader
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I didn't get rich from it but it did have 63K downloads (powered possible tens of thousands of websites).
We describe the deployment and use of Globus Compute for remote computation. This content is aimed at researchers who wish to compute on remote resources using a unified programming interface, as well as system administrators who will deploy and operate Globus Compute services on their research computing infrastructure.
First Steps with Globus Compute Multi-User EndpointsGlobus
In this presentation we will share our experiences around getting started with the Globus Compute multi-user endpoint. Working with the Pharmacology group at the University of Auckland, we have previously written an application using Globus Compute that can offload computationally expensive steps in the researcher's workflows, which they wish to manage from their familiar Windows environments, onto the NeSI (New Zealand eScience Infrastructure) cluster. Some of the challenges we have encountered were that each researcher had to set up and manage their own single-user globus compute endpoint and that the workloads had varying resource requirements (CPUs, memory and wall time) between different runs. We hope that the multi-user endpoint will help to address these challenges and share an update on our progress here.
Into the Box Keynote Day 2: Unveiling amazing updates and announcements for modern CFML developers! Get ready for exciting releases and updates on Ortus tools and products. Stay tuned for cutting-edge innovations designed to boost your productivity.
Quarkus Hidden and Forbidden ExtensionsMax Andersen
Quarkus has a vast extension ecosystem and is known for its subsonic and subatomic feature set. Some of these features are not as well known, and some extensions are less talked about, but that does not make them less interesting - quite the opposite.
Come join this talk to see some tips and tricks for using Quarkus and some of the lesser known features, extensions and development techniques.
Globus Connect Server Deep Dive - GlobusWorld 2024Globus
We explore the Globus Connect Server (GCS) architecture and experiment with advanced configuration options and use cases. This content is targeted at system administrators who are familiar with GCS and currently operate—or are planning to operate—broader deployments at their institution.
Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...Globus
The Earth System Grid Federation (ESGF) is a global network of data servers that archives and distributes the planet’s largest collection of Earth system model output for thousands of climate and environmental scientists worldwide. Many of these petabyte-scale data archives are located in proximity to large high-performance computing (HPC) or cloud computing resources, but the primary workflow for data users consists of transferring data, and applying computations on a different system. As a part of the ESGF 2.0 US project (funded by the United States Department of Energy Office of Science), we developed pre-defined data workflows, which can be run on-demand, capable of applying many data reduction and data analysis to the large ESGF data archives, transferring only the resultant analysis (ex. visualizations, smaller data files). In this talk, we will showcase a few of these workflows, highlighting how Globus Flows can be used for petabyte-scale climate analysis.
Large Language Models and the End of ProgrammingMatt Welsh
Talk by Matt Welsh at Craft Conference 2024 on the impact that Large Language Models will have on the future of software development. In this talk, I discuss the ways in which LLMs will impact the software industry, from replacing human software developers with AI, to replacing conventional software with models that perform reasoning, computation, and problem-solving.
TROUBLESHOOTING 9 TYPES OF OUTOFMEMORYERRORTier1 app
Even though at surface level ‘java.lang.OutOfMemoryError’ appears as one single error; underlyingly there are 9 types of OutOfMemoryError. Each type of OutOfMemoryError has different causes, diagnosis approaches and solutions. This session equips you with the knowledge, tools, and techniques needed to troubleshoot and conquer OutOfMemoryError in all its forms, ensuring smoother, more efficient Java applications.
Developing Distributed High-performance Computing Capabilities of an Open Sci...Globus
COVID-19 had an unprecedented impact on scientific collaboration. The pandemic and its broad response from the scientific community has forged new relationships among public health practitioners, mathematical modelers, and scientific computing specialists, while revealing critical gaps in exploiting advanced computing systems to support urgent decision making. Informed by our team’s work in applying high-performance computing in support of public health decision makers during the COVID-19 pandemic, we present how Globus technologies are enabling the development of an open science platform for robust epidemic analysis, with the goal of collaborative, secure, distributed, on-demand, and fast time-to-solution analyses to support public health.
Experience our free, in-depth three-part Tendenci Platform Corporate Membership Management workshop series! In Session 1 on May 14th, 2024, we began with an Introduction and Setup, mastering the configuration of your Corporate Membership Module settings to establish membership types, applications, and more. Then, on May 16th, 2024, in Session 2, we focused on binding individual members to a Corporate Membership and Corporate Reps, teaching you how to add individual members and assign Corporate Representatives to manage dues, renewals, and associated members. Finally, on May 28th, 2024, in Session 3, we covered questions and concerns, addressing any queries or issues you may have.
For more Tendenci AMS events, check out www.tendenci.com/events
Check out the webinar slides to learn more about how XfilesPro transforms Salesforce document management by leveraging its world-class applications. For more details, please connect with sales@xfilespro.com
If you want to watch the on-demand webinar, please click here: https://www.xfilespro.com/webinars/salesforce-document-management-2-0-smarter-faster-better/
Unleash Unlimited Potential with One-Time Purchase
BoxLang is more than just a language; it's a community. By choosing a Visionary License, you're not just investing in your success, you're actively contributing to the ongoing development and support of BoxLang.
41. THIRDCHANNEL
Reactive Streams / Extensions
• Originally out of Microsoft
• Brought to JVM
• Designed to Handle Messages Asynchronously Across Boundaries
42. THIRDCHANNEL
Reactive Streams / Extensions
• Originally out of Microsoft
• Brought to JVM
• Designed to Handle Messages Asynchronously Across Boundaries
• Composable
43.
44. THIRDCHANNEL
Reactive Streams / Extensions
• Originally out of Microsoft
• Brought to JVM
• Designed to Handle Messages Asynchronously Across Boundaries
• Composable
• Hot / Cold
45. THIRDCHANNEL
Reactive Streams / Extensions
• Originally out of Microsoft
• Brought to JVM
• Designed to Handle Messages Asynchronously Across Boundaries
• Composable
• Hot / Cold
• Backpressure
66. THIRDCHANNEL
Java 8 Streams
• Built into the language
• Meant for Finite Iterables
• Observables -> potentially infinite items, with back pressure
• “Pulling” vs “Pushing”
69. Image Credits
• 1000ms Time To glass:
https://docs.google.com/presentation/d/1IRHyU7_crIiCjl0Gvue0WY3eY_eYvFQvSfwQouW9368/present?slide=id.g1e697bbb_0_7
• internet users in the world: http://www.internetlivestats.com/internet-users/
• internet users vs Facebook: https://medium.com/reactive-programming/what-is-reactive-programming-bc9fa7f4a7fc
• reactivex logo: https://www.stickermule.com/marketplace/2223-rx-reactive-extensions-logo-4
• cheetah: www.livescience.com/21944-usain-bolt-vs-cheetah-animal-olympics.html
• dominoes: https://www.flickr.com/photos/louish/5611657857/sizes/l/in/photostream/
• 300 / Spartans: http://www.300themovie.com/
• latop punch: http://walls4joy.com/wallpaper/730566-angry-laptops-punch
• mailman: http://thebrandtstandard.com/2013/02/09/u-s-post-office-to-end-saturday-letter-delivery-this-summer/
• actor system: http://letitcrash.com/post/30585282971/discovering-message-flows-in-actor-systems-with
• slow down: http://forthefamily.org/reminder-slow/
Editor's Notes
Let’s talk about asynchronous data.
When we say ‘Reactive’, what exactly do we mean? There’s several definitions floating around the internet, all with different meanings.
To me, when I hear the term ‘reactive’ I think of 3 things:
first, ‘reactive programming’
Reactive Programming is different from Imperative programming. In Imperative…
In reactive…
We’ve been working with Reactive programming for years now, even if you don’t know it.
especially if you work at all with User Interfaces (e.g. Javascript).
UIs are all about reacting to user input.
Second: Reactive Systems.
Third: Reactive Streams or Reactive Extensions
I’ll explain more about these in a moment.
while all 3 of these definitions are different they are related.
however, today is about reactive systems and RX
I think these concepts are the most exciting and they’re gathering quite a bit of traction
agenda for today:
talk about reactive systems
go over reactive streams
cover a short list of options available to us when working with Groovy
To begin, let’s talk about the need for reactive… straight out of a document called the Reactive Manifesto
<pause>
The internet is growing. The number of users on the internet has estimated to grow from 750 million to nearly 3 billion in just 11 years,
Even with this increased demand, users expect their browsing experiences to respond immediately.
And they get angry and impatient when sites are slow
Borrowed this slide from ilya grigorik, who introduced (I think) the idea of the 1000ms time to glass challenge… which basically states that your site should render to the screen (or glass) within 1 second of a user interaction.
The reason for this is that studies have been done that show that users’s focus and mental concentration goes away when waiting for more than 1 second.
Furthermore, the Scale of the internet is growing tremendously
The number of users in 2012 of just one site is equal to the entire internet user base just 6 years before that in 2006.
The site is facebook, but still. Just shows you that web sites are facing increasing scaling problems
Applications need to handle as many users as possible… as efficiently as possible
Many frameworks and server technologies still use technology and patterns since the beginning of web development.
E.g. a thread based approach, where one request consumes one thread for the duration of the request. This is especially a problem in a distributed system environment, where that request may need to communicate with other systems.
Reactive systems have 4 main principles
The source of reactive systems can be traced to a document known as the reactive manifesto, which has gone through several revisions over the past few years… most recent edition is from this past september
In it, the Manifesto declares that there are 4 principles that any application must meet in order to meet customer demand.
First: the application must be responsive
This comes right off of the previous point about speed.
Your application, in general, should respond to user interaction as quickly as possible.
A more ‘responsive’ application is a pleasing experience to your end user. The faster your application responds to their input, the less time they sit staring at your app, and the happier they’ll be.
Also, it’s just important to be fast.
Several years ago, an engineer with Amazon named Greg Linden revealed that the company ran experiment where they intentionally slowed down site performance
100ms delay resulted in 1 percent drop in sales. In other words, slowing down their site by a tenth of a second resulted in a considerable loss in revenue.
Which makes sense, right? The faster you can take customer’s orders, the more money you make
Next up: you must be resilient
The resilient principle says that we, as software developers, should have the mindset that at any given moment, your code is going to break.
Think to yourself: How coupled is my code?
-How many of your systems are held together by quick hacks? (I know I’m guilty of this one)
- How dependent on other services, domain objects, third party services, etc is my application?
- What happens to my system if any one of those go down?
The resilient principle says that we shouldn’t be scared of our application failing… instead we should *embrace* failure
-A Reactive application is resilient to failure. If one component breaks down, the others should be able to take up the slack. if a third party service is unavailable, your app should handle it
-Your system should be able to suffer damage and still operate.
-For example, imagine an ecommerce application. if the ability to place orders goes down.. while your team is scrambling to fix, the end user should still be able to browse the products and add items to the cart.
-They should just see a message that says “Sorry, order placement will be right back”…
Your resilient mantra should be “Independent things fail independently”
third:
Your application should stay responsive under load
it should react to changes in workload by increasing or decreasing resources
lastly, Reactive applications are message driven asynchronously
This calls for building and using highly concurrent systems
However, we humans are not good at Concurrency. Things like Thread safety are very hard.
Thus, Reactive systems call for using techniques to abstract the concurrent procedures
Recommended to do this in one of two ways:
Event
-Communication within the system should be done via done via asynchronous immutable events, rather than long procedural code.
-This naturally promotes highly decoupled code. Sender and recipient can be constructed without having to know - or care - about implementation details of the others.
- I think this is a very important point… and is perhaps the most important facet of Reactive programming as the others may come naturally from adopting this single step
Actor system is highly recommended
very complicated
Each actor is a small code block that knows to do a specific action
actors == function ?
actors are not accessed directly, instead actors exist within an ‘Actor System’. you interact with the system instead of the actors directly. The system abstracts the concurrency techniques
Actor systems are very scalable. Can be distributed across threads or even additional systems
With an Actor model you do not talk to the actors directly. Instead, you send messages into the system.
Actors each have a ‘mailbox’, and know how to address messages to other actors or actor types. The actor system than delivers these messages asynchronously
Both patterns have a few things in common, especially that they are asynchronous. They
Key Take away: In a Reactive Application, you must NEVER BLOCK YOUR RESOURCES
pause
next up is Reactive streams
- I’m going to refer to them as Streams, but I think Extensions is also valid.
The idea of reactive extensions came out of Microsoft’s “Cloud Programability team” sometime before 2010. It was designed as an interface for integrating multiple asynchronous data sources in the cloud.
Github used it for everything within their GH for Windows app, and decided to build their own version for Mac because they loved the pattern so much
Microsoft open sourced it in 2012… perhaps to thwart Github?
a couple years later, several heavy hitters in the JVM area decided to bring Reactive Streams to us.
People from Netflix, Typesafe, Twitter, and many others came together.
They made a spec, found at reactive-streams.org to flesh out further how Rx should work.
As of a few days ago, we have several libraries which fully adhere to the spec.
This is a tricky one
both of the subscribers on the branch variable are receiving the same data
Can be a bit intimidating at first
Infamous for having colorful, but often confusing diagrams
and the descriptions can be a little odd, too.
I know english, and even that doesn’t help to decipher what that means
… So it’s a Reactive -Stream Based web server.
I think there’s a talk on Ratpack at this conf. You all should attend.
lmax ring buffer: LMAX is a financial trading company that is trying to build the fastest trading platform in the world. They open sourced key piece of their technology, called the Disrupter which is based on a ring buffer pattern.
Suppose we had an E-commerce app which included a service which created and processed orders.
In this version, we use several additional service collaborators to do things like verifying that we have inventory, charge the user, and send emails if successful or not.
Each of those service calls could take a while (checking inventory, sending email, money), which blocks the thread while we wait for each service call. This slows down the request not only for the end user but for any rampaging hordes trying to access our app
Here’s that same method. Where did the rest of the code go?
First, note the ‘notify’ with a String-based event
On order:created, we execute the first services job
Then we check the inventory for holding, and broadcast a new event based on those results
The moneyService will bill the client if the inventory is good,
While the email service will respond either way.
-Now, some of might be saying, “But Steve, that code is spread across 3 different slides!”. While, true, which of these would you rather use? Which version do you think is more decoupled? Which would be easier to test?
-(Imagine having to mock all these services as collaborators, versus simply creating events)
All this talk about streams and java…
you might be wondering “Why didn’t Steve talk about Java 8 Streams?”
Java 8 Streams API
-at first seems great
- built into the language!
- streams api meant for finite iterable objects to pull from
- observables deal with potentially infinite streams the subscribers receive and can offer backpressure
It’s Demo Time
(for those of you viewing this later, the url for sample code is: https://github.com/spember/greach2015-reactive-demos/)