Did you know that PayPal’s product performance tracking platform processes over 10 billion messages per day making it one of the busiest systems in PayPal? Its end-to-end Reactive data processing pipeline consists of Akka Streams, Kafka, Spark and Druid, which posed a number of technical and the organizational challenges, including converting this well-established team into a Reactive mindset.
In his talk, Turning PayPal’s Product Performance Tracking platform Reactive, End-to-End, at Reactive Summit in Montreal on October 23, Michael Zeltser, senior member of technical staff and architect at PayPal, will share a narrative useful for both beginner and intermediate audiences, builders and managers alike, that will help contextualize conceptual and practical aspects of switching to reactive systems.
In advance of his talk, we spoke to Michael about his path to Reactive systems, the future of Reactive, and why his job is never boring.
What is your background and what sparked your interest in distributed systems?
Prior to discovering Reactive systems, I was deeply involved with finding solutions to arrest escalating cost for collecting and processing large amounts of data at PayPal. My earlier background was classical data architecture. Before the Big Data era, my main focus was on relational databases like Oracle and SQL Server. Around 2000-2001, “web logs” started to creep in into my perfect world of relational modeling. By the time I joined PayPal in 2010, the “new data” had overshadowed traditional data and was (and still is) driving the cost of the data ownership through the roof. Distributed systems are the only way to deal with the deluge at the moment. From Hadoop to Spark, from Spark to Akka (via Scala and FP), I am up to my ears in all things Reactive.
What problems do you solve in your day-to-day job and what do you enjoy most?
I have been called an architect for the better part of the last two decades. It is my job description and my actual title. I’m still in the dark regarding what it means exactly. Primarily my job consists of discovering big blobs of chaos and separating them into small manageable bits of order. It takes a different form almost weekly. In technical terms, I deal with a number of adjacent systems that constitute the domain I’m responsible for. Those systems are developed and maintained by people in several teams. So sometimes I’m solving a technical puzzle, like how to feed bazillions of bytes into a handful of nodes in real-time avoiding race conditions, sometimes it’s about managing internal communications and making sure we’re all on the same page and moving in the right direction. As long as I get things moving, I’m happy. The most favorite part of my job is the ever-changing nature of what I do. It never gets boring.
Reactive is a new buzzword for many traditional developers. What is your prediction for its importance in application development over the next couple of years?
I feel that Reactive is just going to be built-in to everything. My prediction is that we will stop even noticing it, just like we do not notice OOP anymore. It is already happening in Web UI frameworks. We hire a lot of recent graduates and we see that they use React as a natural part of the job, not some hyped new things. The back-end adoption has been a bit slower. Yet in only a couple of years, we are already seeing the beginning of commoditization of Reactive concepts. I have a feeling that understanding is already out there and there is enough of it to get to a critical mass within next couple of years.
What is the biggest challenge companies deploying distributed Reactive systems are facing?
Continuity of the skill set. Switching from imperative programming to Actors and streaming requires a significant mental effort. It is much more acute then switching from framework to framework in last 10-15 years.
What is the best solution to this challenge?
I think getting to a higher level of abstraction as fast as possible is the way to go. Frameworks and tools need to “hide” the total asynchronicity from “unsuspecting” developers. I like what Spark has done for Big Data. It hid most of the distributed complexity. Akka Streams is moving us in the right direction.
What is the most ambitious professional dream you hope to achieve one day?
I’m very lucky so far (knock on wood). I have been able to love what I do and do what I love for 26 years straight. I feel like this in itself such an achievement that hoping for something better is almost sacrilegious. So I just want to keep my lucky streak going for as long as I can.
Who should attend your talk and what will they learn?
In my talk, I will share our experience in putting together an end-to-end Reactive data processing pipeline consisting of Akka Streams, Kafka, Spark and Druid components. If you are at the start of your Reactive journey, need help making a convincing case for Reactive in the real world and are trying to make it happen in a large organization, I hope you will join my presentation and find it useful.
Whom would you like to connect with at the conference?
I’m getting a kick out of connecting with people that smarter than I am. From what I’ve observed within FP and Reactive community, that’s most of them.