About the conference
ReactSphere is a conference focused on Reactive Programming and Reactive System Design.
Let's dive deep into the principles of building responsive distributed systems handling huge amounts of data with near-realtime performance. Microservice Architectures, Actors, Messaging Systems, methods for domain analysis, and more will be covered during lively talks.
Jamie Allen has been a part of the Scala development community for over 10 years, and is formerly an employee of Typesafe/Lightbend. He is the author of Effective Akka (O’Reilly, 2013), and the co-author of Reactive Design Patterns (Manning, 2017). Jamie is a computer languages enthusiast who enjoys writing performant code that most efficiently leverages available resources.
Reactive is a Product
Spent half of his life on programming, for the last decade professionally in Java land. Loves back-end and data visualization. Passionate about alternative JVM languages. Disappointed with the quality of software written these days (so often by himself!), hates long methods and hidden side effects. Interested in charting, data analysis and reporting. Believes that computers were invented so that developers can automate boring and repetitive tasks. Also their own.
On a daily basis works in the e-commerce sector. Involved in open-source, DZone’s Most Valuable Blogger, used to be very active on StackOverflow. Author, trainer, conference speaker, technical reviewer, runner. Claims that code not tested automatically is not a feature but just a rumour. Wrote a book on RxJava for O’Reilly.
Reactive programming: lessons learned
Reactive programming enables amazing things. Highly scalable systems consuming just a fraction of CPU compared to ordinary applications? Sure. Responsive, low latency and high throughput? No problem. Small memory and OS footprint? Out-of-the-box. Any reason not to love reactive? I will share some of my experiences with reactive programming and systems. Where it shines and where it was an over-engineering. What are the hidden costs and common mistakes? How to convince your teammates to start the reactive journey. And more importantly: how to convince your teammates, that going reactive is a dead end. On a case-by-case basis.
Stefano is a Staff Software Engineer working for HomeAway in London, UK. He has been developing large scale backend systems within the cozy boundaries of the JVM for a few years, and he has recently become passionate about the Scala ecosystem – especially all things Akka. He has contributed to Akka, Akka HTTP and Alpakka codebases.
Stream Driven Development with Akka Streams
Akka Streams is a well-known Reactive Streams implementation that helps you build asynchronous, data-intensive apps with no predetermined data volumes. But how would you leverage its full power to design complex, Akka-backed reactive pipelines? At HomeAway we devised an approach to tackle this problem, combining elements of DDD with the abstraction power of the Akka Streams model. Here we’ll discuss useful patterns to
– reason about your stream and identify its building blocks
– type-drive the implementation
– handle failure
– instrument your application for logging and monitoring purposes
Yan is an experienced engineer who has worked with AWS for near 10 years. He has been an architect and lead developer with a variety of industries ranging from investment banks, e-commence to mobile gaming. In the last 2 years he has worked extensively with AWS Lambda in production, and he has been very active in sharing his experiences and the lessons he has learnt, some of his work has even made their way into the Well-Architected whitepaper published by AWS.
Yan is polyglot in both spoken and programming languages, he is fluent in both English and Mandarin, and counts C#, F#, Scala, Node.js and Erlang amongst programming languages that he has worked with professionally. Although he enjoys learning different programming languages and paradigms, he still holds F# as his undisputed favourite.
Yan is a regular speaker at user groups and conferences internationally, and he is also the author of AWS Lambda in Motion and a co-author of F# Deep Dives. In his spare time he keeps an active blog where he shares his thoughts on topics such as AWS, serverless, functional programming and chaos engineering.
Applying principles of chaos engineering to Serverless
The motivation of this talk is to provoke the audience to think about the failure modes that exists in their serverless architecture and how they can discover them early by applying the principles of chaos engineering. Serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour! For instance: smaller unit of deployment, means there are more of them, and each of these “units” is a boundary that needs to be hardened (for security and failure resilience) it’s more difficult to harden around the boundaries simply because there are so many more of them more intermediate services (dynamodb, kinesis, SNS, S3, API Gateway to name a few), each with their own failure modes there are more configurations overall (timeout, IAM permissions, application config, etc.) therefore more opportunities for misconfiguration
Head of Cloud & Reactive Systems / Partner @ VirtusLab
Software engineer / manager / entrepreneur. Worked in international corporations and small local software houses (two of which I co-founded). These days my weapon of choice is mostly Lightbend stack (Scala / Akka / Play / Spark) though I am trying to remain flexible and not be too orthodox.
Far more important than actual technology — I am really passionate about technological challenges and problems that technology is trying to solve. I like to work on things that matter.
Last but not least, infrequent conference speaker.
Beyond the hype: reactive vs traditional microservices
(Joint talk with Łukasz Biały and Marcin Zagórski)
For some time now IT media were sparkled with success stories of teams who went reactive and reaped benefits of paradigm change but in most cases it was not an apples to apples comparison – just legacy stack vs new, shiny async-based technology. In this talk we want to deliver hard, cold numbers about pros, cons, benefits and pains of selecting reactive technologies for your company’s application stack compared to traditional sync webservices. Is reactive microservices approach really worth the effort or are we all drinking the kool-aid?
Gideon de Kok
Having built software over the full range of the stack; from embedded systems, telephony systems, to end-user focused applications and data-processing architectures, Gideon learned the importance of building responsive, resilient, elastic and decoupled systems the hard way. Backed by this experience, Gideon helps organisations in building software in redesigned architectures which enable a more scalable, agile and sustainable way of software development.
A larger part of that focus lies in the design, implementation and creation of awareness of truly modular and autonomous services. Not only to improve overall reactive traits of that system, but to improve alignment within a business by separating and forming teams and functionality directly around the domains they try to model. Call it microservices, call it self-contained services, call it modular design, DDD or agile software architectures; Gideon’s focus is on helping organisations in mapping business and IT in the most optimal form.
Events-first microservices with Lagom
Even with microservices starting to become a commodity, a lot of implementations still fail as microliths. To ensure the autonomy of services and its development process, strong coupling between services should be limited as much as possible. The way to achieve this is to isolate the inner working of a service at cost and to switch from a commanding and synchronous to a promising and asynchronous way of communication between services.
A route to success is to stop architectural design from a perspective of services with well-defined and canonical relationships and to switch to a model which is based on the production of immutable domain events. Not only does this way of architecting ensure a better match with the things that happen within your business. The focus on the timeline of facts over the structures producing them ensures far less coupling within your system.
In this talk, I will share how Lagom embraces this way of thinking by pushing events-first development as a default. From the event-sourcing principles within aggregates to the message-broker functionality between services, I’ll give you the background of the elements which are in place to shift your system to an event-driven microservice architecture.
I’m a passionate software engineer living in the JVM land – mainly, but not limited to. I also tend to play with electronics and hardware. When sharing my knowlegde, I always keep in mind that a working example is worth a thousand words.
Practical Reactive Streams with Monix
Stream processing is a hot topic today and it’s easy to get lost among all the possibilities. In this live coding session we will explore the Reactive Streams approach used by the Monix project – one of the Scala implementations of the Reactive Streams concepts. On an almost real-life example we’re going to walk through both the basics and some more advanced usages of the library.
Grew up as C64-nerd, got into Basic, C and Assembly. Found the JVM and fell in love. Since then I’ve been constantly wandering through the world of IT, always focusing on highly available distributed systems. Today I am happy to be a part of the nerd herd at codecentric. I spent the past few years working with a bunch of very creative and fun people in Scala-heavy projects using Akka, Vert.x, Spark, … . Oh, and I joined the Vert.x-team in 2017 as maintainer for the Scala-stack. That’s where most of my non-working-coding-time goes.
A reactive architecture based on Vert.x and Kubernetes
The combination of microservices and the availability of easy to operate cloud infrastructures has changed the way we build software. Where classic 3-tier applications dominated only a few years ago we today see highly distributed microservice infrastructures. At the same time the expectations of our customers advanced at almost the same pace. Downtimes are a far more serious issue as they will drive them away to the competition. Classic application design and the way we used to build software hit there limits a while ago and new paradigms were required.
This talk will show how the combination of a reactive application framework like Vert.x, a Kubernetes based infrastructure, Scala and a lot of fun give us a fully reactive architecture … and happy customers.
In this talk I will introduce the core concepts of Vert.x, its event bus, the new Scala-integration and how this all plays together with Kubernetes.
Expect to see a lot of code and to learn how a developer can effectively develop locally using Vert.x and Kubernetes together.
Tudor is a Software Consultant based in London with more than 15 years of software development experience. After working for a while as a Java engineer for some well known clients (Oracle, BNP Paribas, Sony Playstation Network) he decided to steer his career to Scala, working for the last year and a half at Expedia/Hotels.com. He’s passionate about writing good quality software, microservice architecture and functional programing.
Software Engineer at Actyx by day, sporadic Akka and Dotty projects contributor by night. Interested in how software works on low level, he does not find big frameworks appealing. This is the main reason why he loves Scala, a very expressive language that allows one to build right abstractions quickly without losing control over details. Jan is an active member of JUG Łódź and occasional conference speaker. In his spare time he loves to dust-off some old issue of computer science journal only to find out that everything has already been invented before he even was born.
Alpakka – a new world of Connectors for Reactive Enterprise Integration
Connecting your programs with various upstream and downstream systems is a frequent problem. Until recently if one wanted to integrate an Akka Streams application with the world outside, the tool of choice would be the Akka Camel module. However, this frequently resulted in non-intuitive, complex and hard to test implementations. With the recent advent of Alpakka library, you can integrate in a reactive, backpressure-preserving way.
In this talk we will:
– introduce the Alpakka library
– do a short walk through sample modules
– show how to write your own integration (and make it a part of Alpakka).
JVM Developer with quite functional heart
2 small steps for a team
Kotlin + Spring 5.0 Web Flux
Almost nobody likes big changes. This includes management and developers. It is often very hard to convince people to try something new. Even if the old way is pathetic, leads to bugs and does not fit to a problem. If you do not believe in that try to convince any JavaEE/ Spring team to use something else. Even though both platforms are quite dated and do not really enable writing clean code. They are even worse if you try functional programming.
The way I often do is to introduce only a small improvements, to the extent that might get accepted by the team and managers. Such a trick is to use Kotlin as Java++ and Spring 5… as just a new version of Spring. After a while it can appear that the “new Java” is written totally functional, with very little or none mutability. And the new Spring works without annotations and so called beans. Eventually, we get code that is more similar to Scala/Akka-HTTP stack… that would not be ever accepted.
Reactive Developer & Architect in Amsterdam, I am in love with anything reactive & streaming, especially if built with Scala, Akka and the rest of their wonderful ecosystem.
I love to help communities grow and I founded myself the Reactive Amsterdam meetup which has been very successful over the last couple of years, with great numbers and sponsors. My biggest passion beside tech is bicycle touring – the biggest adventure so far cycling from Amsterdam to Rome, my home town. Oh, I run a meetup about that too!
Cloud Native Akka & Kubernetes: the holy grail to elasticity?
I have been in love with Akka since I first saw it. Akka is the most mature choice to implement the traits of the Reactive Manifesto, thanks to the Actor model. Resilience is enabled by asynchronous message passing and Actor supervision. Location transparency, message routing and the “share nothing” approach enable seamless scalability, but once our app is deployed we need to rely on some external infrastructure to automatically scale up or down our services. At this point, Akka alone is not sufficient anymore. What else do we need?
I found Docker & Kubernetes to be a perfect match for clustered Akka applications running in the cloud. Thanks to the Kubernetes API, one can write infrastructure logic that complements the business logic. This leads to a general approach of infrastructure-as-code tailored to each different business case, which in turn lets companies achieve maximum efficiency and resource usage.
During this talk I will cover features from both Akka and Kubernetes, plus example code in Scala: familiarity with these technologies is recommended. My example will rely on Google Cloud infrastructure.
Other sphere.it events
Scala.sphere.it is a unique event devoted to important topic for every Scala Software Developer – Dev Tools.
Data.sphere.it is a conference devoted to data-centric systems and the technologies making them tick. Whether it is data engineering or AI application challenges – they all fit well in.
Main venueThe Opera of Kraków
Code of Conduct
The following Code of Conduct is inspired by that from other prominent conferences such as ScalaDays or Scala eXchange.
ReactSphere is dedicated to providing a harassment-free experience for everyone, regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, nationality, age or religion. We do not tolerate harassment of participants in any form. Please show respect for those around you. This applies to both in-person and online behavior.
All communication should be appropriate for a technical audience,
including people of many different backgrounds. Sexual language, innuendo, and imagery is not appropriate for any conference venue, including talks.
If you are being harassed, notice that someone else is being harassed, or have any other concerns, please contact a member of staff immediately. If an individual engages in harassing behaviour, the React.sphere.it staff may take any action they deem appropriate, including warning the offender or expulsion from the event.
We expect all attendees to follow above rules during our Conferences.