�ݺ�ߣshows by User: Reactivesummit

�ݺ�ߣshows by User: Reactivesummit / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: Reactivesummit / Wed, 19 Oct 2016 07:12:33 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: Reactivesummit Distributed stream processing with Apache Kafka /Reactivesummit/distributed-stream-processing-with-apache-kafka kafka-streams-reactive-summit-161019071233
https://reactivesummit2016.sched.org/event/8B6K/distributed-stream-processing-with-apache-kafka]]>
https://reactivesummit2016.sched.org/event/8B6K/distributed-stream-processing-with-apache-kafka]]> Wed, 19 Oct 2016 07:12:33 GMT /Reactivesummit/distributed-stream-processing-with-apache-kafka Reactivesummit@slideshare.net(Reactivesummit) Distributed stream processing with Apache Kafka Reactivesummit https://reactivesummit2016.sched.org/event/8B6K/distributed-stream-processing-with-apache-kafka <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/kafka-streams-reactive-summit-161019071233-thumbnail.jpg?width=120&height=120&fit=bounds" /> https://reactivesummit2016.sched.org/event/8B6K/distributed-stream-processing-with-apache-kafka

Distributed stream processing with Apache Kafka from Reactivesummit

]]> 760 3 https://cdn.slidesharecdn.com/ss_thumbnails/kafka-streams-reactive-summit-161019071233-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Reactive Polyglot Microservices with OpenShift and Vert.x /slideshow/reactive-polyglot-microservices-with-openshift-and-vertx/67033115 vertx-openshift-slides-161011223413
Vert.x is a framework to create reactive distributed and polyglot applications on the Java Virtual Machine. Vert.x takes the JVM to new levels of performance yet having a small API. It lets you build scalable microservice-based applications transparently distributed and packaged as a single jar file. Due to this simplicity, deploying and managing Vert.x applications on OpenShift is a breeze, upload your jar and Vert.x internal cluster manager will connect all your pods in single distributed network. Several examples are shown during the talk and demonstrate how Vert.x can simplify DevOps daily job when working together with OpenShift such as deployment, rolling updates, monitoring, metrics...]]>
Vert.x is a framework to create reactive distributed and polyglot applications on the Java Virtual Machine. Vert.x takes the JVM to new levels of performance yet having a small API. It lets you build scalable microservice-based applications transparently distributed and packaged as a single jar file. Due to this simplicity, deploying and managing Vert.x applications on OpenShift is a breeze, upload your jar and Vert.x internal cluster manager will connect all your pods in single distributed network. Several examples are shown during the talk and demonstrate how Vert.x can simplify DevOps daily job when working together with OpenShift such as deployment, rolling updates, monitoring, metrics...]]> Tue, 11 Oct 2016 22:34:13 GMT /slideshow/reactive-polyglot-microservices-with-openshift-and-vertx/67033115 Reactivesummit@slideshare.net(Reactivesummit) Reactive Polyglot Microservices with OpenShift and Vert.x Reactivesummit Vert.x is a framework to create reactive distributed and polyglot applications on the Java Virtual Machine. Vert.x takes the JVM to new levels of performance yet having a small API. It lets you build scalable microservice-based applications transparently distributed and packaged as a single jar file. Due to this simplicity, deploying and managing Vert.x applications on OpenShift is a breeze, upload your jar and Vert.x internal cluster manager will connect all your pods in single distributed network. Several examples are shown during the talk and demonstrate how Vert.x can simplify DevOps daily job when working together with OpenShift such as deployment, rolling updates, monitoring, metrics... <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/vertx-openshift-slides-161011223413-thumbnail.jpg?width=120&height=120&fit=bounds" /> Vert.x is a framework to create reactive distributed and polyglot applications on the Java Virtual Machine. Vert.x takes the JVM to new levels of performance yet having a small API. It lets you build scalable microservice-based applications transparently distributed and packaged as a single jar file. Due to this simplicity, deploying and managing Vert.x applications on OpenShift is a breeze, upload your jar and Vert.x internal cluster manager will connect all your pods in single distributed network. Several examples are shown during the talk and demonstrate how Vert.x can simplify DevOps daily job when working together with OpenShift such as deployment, rolling updates, monitoring, metrics...

Reactive Polyglot Microservices with OpenShift and Vert.x from Reactivesummit

]]> 786 3 https://cdn.slidesharecdn.com/ss_thumbnails/vertx-openshift-slides-161011223413-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Microservices: The danger of overhype and importance of checklists /slideshow/microservices-the-danger-of-overhype-and-importance-of-checklists/67033092 microservices-and-checklistsreactive-summit-20161-161011223256
It is a hard to argue that microservices is a new hotness in the world of software. Technical teams in seemingly all new startups are planning to develop their product using microservices, while architects in Fortune 500 are managing tireless conversations about which microservices technology is best to use for their next generation platform. The overhype of microservices is here and with that comes a danger to loose the true meaning of the word, which soon might be labeled as overrated. Before it happens, let's talk about what microservices architecture is, what it can offer, what it gets us into, what its price tag and how to create a checklist for choosing right tools that would help solve the complexity instead of sugarcoating it. ]]>
It is a hard to argue that microservices is a new hotness in the world of software. Technical teams in seemingly all new startups are planning to develop their product using microservices, while architects in Fortune 500 are managing tireless conversations about which microservices technology is best to use for their next generation platform. The overhype of microservices is here and with that comes a danger to loose the true meaning of the word, which soon might be labeled as overrated. Before it happens, let's talk about what microservices architecture is, what it can offer, what it gets us into, what its price tag and how to create a checklist for choosing right tools that would help solve the complexity instead of sugarcoating it. ]]> Tue, 11 Oct 2016 22:32:56 GMT /slideshow/microservices-the-danger-of-overhype-and-importance-of-checklists/67033092 Reactivesummit@slideshare.net(Reactivesummit) Microservices: The danger of overhype and importance of checklists Reactivesummit It is a hard to argue that microservices is a new hotness in the world of software. Technical teams in seemingly all new startups are planning to develop their product using microservices, while architects in Fortune 500 are managing tireless conversations about which microservices technology is best to use for their next generation platform. The overhype of microservices is here and with that comes a danger to loose the true meaning of the word, which soon might be labeled as overrated. Before it happens, let's talk about what microservices architecture is, what it can offer, what it gets us into, what its price tag and how to create a checklist for choosing right tools that would help solve the complexity instead of sugarcoating it. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/microservices-and-checklistsreactive-summit-20161-161011223256-thumbnail.jpg?width=120&height=120&fit=bounds" /> It is a hard to argue that microservices is a new hotness in the world of software. Technical teams in seemingly all new startups are planning to develop their product using microservices, while architects in Fortune 500 are managing tireless conversations about which microservices technology is best to use for their next generation platform. The overhype of microservices is here and with that comes a danger to loose the true meaning of the word, which soon might be labeled as overrated. Before it happens, let's talk about what microservices architecture is, what it can offer, what it gets us into, what its price tag and how to create a checklist for choosing right tools that would help solve the complexity instead of sugarcoating it.

Microservices: The danger of overhype and importance of checklists from Reactivesummit

]]> 401 5 https://cdn.slidesharecdn.com/ss_thumbnails/microservices-and-checklistsreactive-summit-20161-161011223256-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Orchestrated Chaos: Applying Failure Testing Research at Scale. /Reactivesummit/orchestrated-chaos-applying-failure-testing-research-at-scale orchestratedchaosreactivesummit-161011223037
Large-scale distributed systems must be built to anticipate and mitigate a variety of hardware and software failures. In order to build confidence that fault-tolerant systems are correctly implemented, an increasing number of large-scale sites practice Chaos Engineering, running regular failure drills in which faults are deliberately injected in their production system. While fault injection infrastructures are becoming relatively mature, existing approaches either explore the space of potential failures randomly or exploit the “hunches” of domain experts to guide the search—the combinatorial space of failure scenarios is too large to search exhaustively. Random strategies waste resources testing “uninteresting” faults, while programmer-guided approaches are only as good as the intuition of a programmer and only scale with human effort. In this talk, I will present intuition, experience and research directions related to lineage-driven fault injection (LDFI), a novel approach to automating failure testing. LDFI utilizes existing tracing or logging infrastructures to work backwards from good outcomes, identifying redundant computations that allow it to aggressively prune the space of faults that must be explored via fault injection. I will describe LDFI’s theoretical roots in the database research notion of provenance, present results from the lab as well as the field, and present a call to arms for the reliability community to improve our understanding of when and how our fault-tolerant systems actually tolerate faults. ]]>
Large-scale distributed systems must be built to anticipate and mitigate a variety of hardware and software failures. In order to build confidence that fault-tolerant systems are correctly implemented, an increasing number of large-scale sites practice Chaos Engineering, running regular failure drills in which faults are deliberately injected in their production system. While fault injection infrastructures are becoming relatively mature, existing approaches either explore the space of potential failures randomly or exploit the “hunches” of domain experts to guide the search—the combinatorial space of failure scenarios is too large to search exhaustively. Random strategies waste resources testing “uninteresting” faults, while programmer-guided approaches are only as good as the intuition of a programmer and only scale with human effort. In this talk, I will present intuition, experience and research directions related to lineage-driven fault injection (LDFI), a novel approach to automating failure testing. LDFI utilizes existing tracing or logging infrastructures to work backwards from good outcomes, identifying redundant computations that allow it to aggressively prune the space of faults that must be explored via fault injection. I will describe LDFI’s theoretical roots in the database research notion of provenance, present results from the lab as well as the field, and present a call to arms for the reliability community to improve our understanding of when and how our fault-tolerant systems actually tolerate faults. ]]> Tue, 11 Oct 2016 22:30:37 GMT /Reactivesummit/orchestrated-chaos-applying-failure-testing-research-at-scale Reactivesummit@slideshare.net(Reactivesummit) Orchestrated Chaos: Applying Failure Testing Research at Scale. Reactivesummit Large-scale distributed systems must be built to anticipate and mitigate a variety of hardware and software failures. In order to build confidence that fault-tolerant systems are correctly implemented, an increasing number of large-scale sites practice Chaos Engineering, running regular failure drills in which faults are deliberately injected in their production system. While fault injection infrastructures are becoming relatively mature, existing approaches either explore the space of potential failures randomly or exploit the “hunches” of domain experts to guide the search—the combinatorial space of failure scenarios is too large to search exhaustively. Random strategies waste resources testing “uninteresting” faults, while programmer-guided approaches are only as good as the intuition of a programmer and only scale with human effort. In this talk, I will present intuition, experience and research directions related to lineage-driven fault injection (LDFI), a novel approach to automating failure testing. LDFI utilizes existing tracing or logging infrastructures to work backwards from good outcomes, identifying redundant computations that allow it to aggressively prune the space of faults that must be explored via fault injection. I will describe LDFI’s theoretical roots in the database research notion of provenance, present results from the lab as well as the field, and present a call to arms for the reliability community to improve our understanding of when and how our fault-tolerant systems actually tolerate faults. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/orchestratedchaosreactivesummit-161011223037-thumbnail.jpg?width=120&height=120&fit=bounds" /> Large-scale distributed systems must be built to anticipate and mitigate a variety of hardware and software failures. In order to build confidence that fault-tolerant systems are correctly implemented, an increasing number of large-scale sites practice Chaos Engineering, running regular failure drills in which faults are deliberately injected in their production system. While fault injection infrastructures are becoming relatively mature, existing approaches either explore the space of potential failures randomly or exploit the “hunches” of domain experts to guide the search—the combinatorial space of failure scenarios is too large to search exhaustively. Random strategies waste resources testing “uninteresting” faults, while programmer-guided approaches are only as good as the intuition of a programmer and only scale with human effort. In this talk, I will present intuition, experience and research directions related to lineage-driven fault injection (LDFI), a novel approach to automating failure testing. LDFI utilizes existing tracing or logging infrastructures to work backwards from good outcomes, identifying redundant computations that allow it to aggressively prune the space of faults that must be explored via fault injection. I will describe LDFI’s theoretical roots in the database research notion of provenance, present results from the lab as well as the field, and present a call to arms for the reliability community to improve our understanding of when and how our fault-tolerant systems actually tolerate faults.

Orchestrated Chaos: Applying Failure Testing Research at Scale. from Reactivesummit

]]> 925 5 https://cdn.slidesharecdn.com/ss_thumbnails/orchestratedchaosreactivesummit-161011223037-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 The Zen Of Erlang /slideshow/the-zen-of-erlang/67032880 zen-of-erlang-wide-reslide-light-161011222414
A code-free presentation about the core principles and philosophies of Erlang, explaining how the whole is greater than the sum of its parts. This presentation takes a perspective rooted in showing the reasoning between each of the building blocks (message-passing, isolated processes, links and monitors, and so on), and shows how they can be assembled together to create larger systems where interactions between subsystems take a front seat in defining the fault tolerance of these systems.]]>
A code-free presentation about the core principles and philosophies of Erlang, explaining how the whole is greater than the sum of its parts. This presentation takes a perspective rooted in showing the reasoning between each of the building blocks (message-passing, isolated processes, links and monitors, and so on), and shows how they can be assembled together to create larger systems where interactions between subsystems take a front seat in defining the fault tolerance of these systems.]]> Tue, 11 Oct 2016 22:24:14 GMT /slideshow/the-zen-of-erlang/67032880 Reactivesummit@slideshare.net(Reactivesummit) The Zen Of Erlang Reactivesummit A code-free presentation about the core principles and philosophies of Erlang, explaining how the whole is greater than the sum of its parts. This presentation takes a perspective rooted in showing the reasoning between each of the building blocks (message-passing, isolated processes, links and monitors, and so on), and shows how they can be assembled together to create larger systems where interactions between subsystems take a front seat in defining the fault tolerance of these systems. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/zen-of-erlang-wide-reslide-light-161011222414-thumbnail.jpg?width=120&height=120&fit=bounds" /> A code-free presentation about the core principles and philosophies of Erlang, explaining how the whole is greater than the sum of its parts. This presentation takes a perspective rooted in showing the reasoning between each of the building blocks (message-passing, isolated processes, links and monitors, and so on), and shows how they can be assembled together to create larger systems where interactions between subsystems take a front seat in defining the fault tolerance of these systems.

The Zen Of Erlang from Reactivesummit

]]> 483 2 https://cdn.slidesharecdn.com/ss_thumbnails/zen-of-erlang-wide-reslide-light-161011222414-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Monolith to Reactive Microservices /slideshow/monolith-to-reactive-microservices/67032584 rsa-161011221525
In this talk, we will review an experience of rearchitecting and migrating a system that appeared reactive and microservice-based, but was in fact a monolith with RPC calls to a truly reactive architecture. The migration work had to be done without causing disruption to the current system, and without taking time to rewrite the system. The result is a biometric computer vision system with a distributed domain in Akka / Scala with storage in Apache Cassandra, with the computer vision components in OpenCV in C++, connected with RabbitMQ and with batch analytics code in Apache Spark. This talk will show the architectural and code smells that were the result of half-harted reactive implementation and the way to address them, but also the impact of the changes on privacy and security of the stored biometric information.]]>
In this talk, we will review an experience of rearchitecting and migrating a system that appeared reactive and microservice-based, but was in fact a monolith with RPC calls to a truly reactive architecture. The migration work had to be done without causing disruption to the current system, and without taking time to rewrite the system. The result is a biometric computer vision system with a distributed domain in Akka / Scala with storage in Apache Cassandra, with the computer vision components in OpenCV in C++, connected with RabbitMQ and with batch analytics code in Apache Spark. This talk will show the architectural and code smells that were the result of half-harted reactive implementation and the way to address them, but also the impact of the changes on privacy and security of the stored biometric information.]]> Tue, 11 Oct 2016 22:15:25 GMT /slideshow/monolith-to-reactive-microservices/67032584 Reactivesummit@slideshare.net(Reactivesummit) Monolith to Reactive Microservices Reactivesummit In this talk, we will review an experience of rearchitecting and migrating a system that appeared reactive and microservice-based, but was in fact a monolith with RPC calls to a truly reactive architecture. The migration work had to be done without causing disruption to the current system, and without taking time to rewrite the system. The result is a biometric computer vision system with a distributed domain in Akka / Scala with storage in Apache Cassandra, with the computer vision components in OpenCV in C++, connected with RabbitMQ and with batch analytics code in Apache Spark. This talk will show the architectural and code smells that were the result of half-harted reactive implementation and the way to address them, but also the impact of the changes on privacy and security of the stored biometric information. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/rsa-161011221525-thumbnail.jpg?width=120&height=120&fit=bounds" /> In this talk, we will review an experience of rearchitecting and migrating a system that appeared reactive and microservice-based, but was in fact a monolith with RPC calls to a truly reactive architecture. The migration work had to be done without causing disruption to the current system, and without taking time to rewrite the system. The result is a biometric computer vision system with a distributed domain in Akka / Scala with storage in Apache Cassandra, with the computer vision components in OpenCV in C++, connected with RabbitMQ and with batch analytics code in Apache Spark. This talk will show the architectural and code smells that were the result of half-harted reactive implementation and the way to address them, but also the impact of the changes on privacy and security of the stored biometric information.

Monolith to Reactive Microservices from Reactivesummit

]]> 452 9 https://cdn.slidesharecdn.com/ss_thumbnails/rsa-161011221525-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Back-Pressure in Action: Handling High-Burst Workloads with Akka Streams & Kafka @PayPal /slideshow/backpressure-in-action-handling-highburst-workloads-with-akka-streams-kafka-paypal/67032463 back-pressurereactivesummit-161011221331
Akka Streams and its amazing handling of stream back-pressure should be no surprise to anyone. But it takes a couple of use cases to really see it in action - especially use cases where the amount of work increases as you process make you really value the back-pressure. This talk takes a sample web crawler use case where each processing pass expands to a larger and larger workload to process, and discusses how we use the buffering capabilities in Kafka and the back-pressure with asynchronous processing in Akka Streams to handle such bursts. In addition, we will also provide some constructive “rants” about the architectural components, the maturity, or immaturity you’ll expect, and tidbits and open source goodies like memory-mapped stream buffers that can be helpful in other Akka Streams and/or Kafka use cases.]]>
Akka Streams and its amazing handling of stream back-pressure should be no surprise to anyone. But it takes a couple of use cases to really see it in action - especially use cases where the amount of work increases as you process make you really value the back-pressure. This talk takes a sample web crawler use case where each processing pass expands to a larger and larger workload to process, and discusses how we use the buffering capabilities in Kafka and the back-pressure with asynchronous processing in Akka Streams to handle such bursts. In addition, we will also provide some constructive “rants” about the architectural components, the maturity, or immaturity you’ll expect, and tidbits and open source goodies like memory-mapped stream buffers that can be helpful in other Akka Streams and/or Kafka use cases.]]> Tue, 11 Oct 2016 22:13:31 GMT /slideshow/backpressure-in-action-handling-highburst-workloads-with-akka-streams-kafka-paypal/67032463 Reactivesummit@slideshare.net(Reactivesummit) Back-Pressure in Action: Handling High-Burst Workloads with Akka Streams & Kafka @PayPal Reactivesummit Akka Streams and its amazing handling of stream back-pressure should be no surprise to anyone. But it takes a couple of use cases to really see it in action - especially use cases where the amount of work increases as you process make you really value the back-pressure. This talk takes a sample web crawler use case where each processing pass expands to a larger and larger workload to process, and discusses how we use the buffering capabilities in Kafka and the back-pressure with asynchronous processing in Akka Streams to handle such bursts. In addition, we will also provide some constructive “rants” about the architectural components, the maturity, or immaturity you’ll expect, and tidbits and open source goodies like memory-mapped stream buffers that can be helpful in other Akka Streams and/or Kafka use cases. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/back-pressurereactivesummit-161011221331-thumbnail.jpg?width=120&height=120&fit=bounds" /> Akka Streams and its amazing handling of stream back-pressure should be no surprise to anyone. But it takes a couple of use cases to really see it in action - especially use cases where the amount of work increases as you process make you really value the back-pressure. This talk takes a sample web crawler use case where each processing pass expands to a larger and larger workload to process, and discusses how we use the buffering capabilities in Kafka and the back-pressure with asynchronous processing in Akka Streams to handle such bursts. In addition, we will also provide some constructive “rants” about the architectural components, the maturity, or immaturity you’ll expect, and tidbits and open source goodies like memory-mapped stream buffers that can be helpful in other Akka Streams and/or Kafka use cases.

Back-Pressure in Action: Handling High-Burst Workloads with Akka Streams & Kafka @PayPal from Reactivesummit

]]> 2077 3 https://cdn.slidesharecdn.com/ss_thumbnails/back-pressurereactivesummit-161011221331-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://public.slidesharecdn.com/v2/images/profile-picture.png https://cdn.slidesharecdn.com/ss_thumbnails/kafka-streams-reactive-summit-161019071233-thumbnail.jpg?width=320&height=320&fit=bounds Reactivesummit/distributed-stream-processing-with-apache-kafka Distributed stream pro... https://cdn.slidesharecdn.com/ss_thumbnails/vertx-openshift-slides-161011223413-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/reactive-polyglot-microservices-with-openshift-and-vertx/67033115 Reactive Polyglot Micr... https://cdn.slidesharecdn.com/ss_thumbnails/microservices-and-checklistsreactive-summit-20161-161011223256-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/microservices-the-danger-of-overhype-and-importance-of-checklists/67033092 Microservices: The dan...