Why Reactive?

by Konrad Malawski

It’s often difficult to separate hype from reality when it comes to evaluating new technologies, and that’s certainly true of reactive programming. In this report, author Konrad Malawski ana...

Designing Reactive Systems

by Hugh McKee

Everything old is new again, at least when it comes to the Actor model. Today, there is renewed interest and adoption of this technology for building distributed systems, especially as cloud...

Akka In Action

by Raymond Roestenburg, Rob Bakker, and Rob Williams

Akka is a Scala-based toolkit that simplifies developing concurrent distributed applications. Akka uses Actors-independently executing processes that communicate via message passing—as the f...

The Basics Of Reactive System Design For Traditional Java Enterprises

with Sean Walsh and Duncan DeVore

Like most things in life, in software there exists an Old and a New way of doing things. The growth of computing power, increase in the sheer number of users, cheaper and more available hardware, and the explosive IoT market mandates that we build our systems using modern methods that diverge from past.

This modern way is called “Reactive”, which was first co-authored by Lightbend in 2013 with the Reactive Manifesto and now has over 15,000 signatories. With 2017 nearly upon us, we now see the market widely embracing Reactive in response to the many Architects, Developers and DevOps practitioners failing to meet tough new demands on their systems using last year’s technologies and monolithic designs.

Yet with this popularity, the term Reactive is being overloaded and confused. Some believe that asynchronous messaging alone is good enough. As we will see, this is only part of the puzzle.

In this webinar aimed at Architects and Developers working with more traditional Java environments, Lightbend’s Sean Walsh and Duncan DeVore take us on a journey that goes beyond just asynchronous programming and into the very basics of designing Reactive systems as a whole.

We will review:

• Why simply implementing asynchronous messaging is only part of the puzzle, and what it means to build entire systems as a whole based on the principles of Reactive system design: message-driven, resilient, elastic and responsive.
• How to avoid repeatedly building monoliths by embracing tried-and-true concepts of Domain Driven Design (DDD), Command Query Responsibility Segregation (CQRS) and Event Sourcing.
• How the Actor Model with Akka makes concurrency a breeze and harnesses clustered computing capabilities to divide and conquer work.
• How to design systems that can self-heal, self-scale, both up and down and truly provide the most real time and responsive experience for your customers, clients and partners while being a joy to program and maintain.

Distributed Systems Done Right: Why Java Enterprises Are Embracing The Actor Model

with Hugh McKee

Most likely, your job is heavily focused on helping your organization modernize for the digital era. As the days of purely Object-Oriented Programming and related frameworks come to a close, enterprises migrating to distributed, cloud infrastructures are embracing a different approach: the Actor Model.

When it comes to distributed computing, the Actor Model is the great-grandparent of it all.

Created by Carl Hewitt in 1973, Forrester Research notes, “the Actor model is seeing renewed interest as cloud concurrency challenges grow.”

Yet even if you understand the Actor Model and used some of the toolkits for it (e.g. Akka and Erlang), how do you easily explain the concept to your team, colleagues and managers? Where do you start?

In this webinar, Hugh McKee, Global Solutions Architect at Lightbend, shows you how Actors behave and interact as humans do when it comes to communicating, and how these similar behavioral patterns provide basic intuition when designing Reactive systems. Actors allow your teams to focus on an application’s business logic rather than on low-level protocols, accelerating time-to-market while keeping your infrastructure costs low.

Our goal is twofold: provide you with a comprehensive review of the Actor Model, and give you the resources you need to help others learn why enterprises like Walmart, Intel, Samsung, IBM, Norwegian Cruise Lines and HSBC are committed production users of Akka, the JVM-based toolkit built on the Actor Model.

In this webinar, you’ll learn:

• Why actor-based systems are one of the foundational technologies for creating microservices architecture (MSA)
• How Actors delegate work by creating other Actors in a supervisor-to-worker relationship
• How Actors manage requests and scale horizontally in large systems
• The difference between traditional systems and actor-based systems
• How an Actor system forms clusters when the flow of work exceeds a system’s capacity to process it
• Why failure detection and failure recovery is an architectural feature of Actor systems
• An example of using Actors to build an Internet of Things (IoT) application

Lessons Learned From PayPal: Back Pressure With Akka Streams And Kafka

with Akara Sucharitakul

Audience: Architects, Management Technical level: Intermediate

Akka Streams and its amazing handling of streaming with back-pressure should be no surprise to anyone. But it takes a couple of use cases to really see it in action - especially in use cases where the amount of work continues to increase as you’re processing it. This is where back-pressure really shines.

In this talk for Architects and Dev Managers by Akara Sucharitakul, Principal MTS for Global Platform Frameworks at PayPal, Inc., we look at how back-pressure based on Akka Streams and Kafka is being used at PayPal to handle very bursty workloads.

In addition, Akara will also share experiences in creating a platform based on Akka and Akka Streams that currently processes over 1 billion transactions per day (on just 8 VMs), with the aim of helping teams adopt these technologies. In this webinar, you will:

• Start with a sample web crawler use case to examine what happens when each processing pass expands to a larger and larger workload to process.
• Review how we use the buffering capabilities in Kafka and the back-pressure with asynchronous processing in Akka Streams to handle such bursts.
• Look at lessons learned, plus 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.