Senior Consultant at Icon Solutions, Patrick Altaie is working on IPF – Icon Solutions’ flagship real-time payments processing platform that is built using Reactive concepts and leading open-source frameworks, including Akka.
In advance of Patrick’s talk “Clustering and Distributed Data: The Winning Combination?” at Reactive Summit in Montreal, we asked him about his Reactive journey, why legacy-heavy companies are struggling to adopt Reactive and what one can learn from his talk.
What is your background and what sparked your interest in distributed systems?
My background is in “enterprise application integration,” for those who are familiar with the term – the heady days of SOAP web services, UDDI service discovery, and messaging – the latter of which is managing to survive the buzzword cull! The tech stack was TIBCO-heavy and very enterprise-y. My first job was in banking, maintaining a set of SOAP web services, where I got an introduction into distributed systems.
Later in life I joined Icon Solutions to work on a variety of exciting projects, mostly integration-oriented and heavy on distributed systems, and the latest iteration of my Icon story being IPF – our reactive instant payments platform.
What problems do you solve as a part of your day-to-day job?
I’ve recently taken on a design lead role, which means looking at lots of pull requests, sharing feedback on people’s code, and attending the technical design authority (TDA) with our architects to ensure that the ivory tower is not too ivory, and doesn’t resemble too much of a tower. I’m only joking of course because our architects are the most pragmatic bunch of folks with whom I’ve had the pleasure of working.
My favourite part of my job is teaching others about the best use of Reactive systems – we have a sizable number of team members who are unfamiliar with the unpredictability of asynchronous payment messaging which presents a unique set of challenges as opposed to, say, building a simple REST service. It’s a good feeling to teach folks about “akka-y” ways of doing things to make sure we stay reactive.
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?
It’s certainly the “in” buzzword right now, but I believe it’s just another iteration of hype for good development practices that we should all embrace – building modular, fault-tolerant systems supported by messaging. We’ve been doing these things for a long time and they tend to get re-badged as something new every couple of years.
I suppose, in the future, some new concept might come along and we’d start calling our best practices something else, but as long as we keep things decoupled and fault-tolerant then it’ll make our lives really easy.
What is the biggest challenge companies deploying distributed Reactive systems are facing?
From my experience, I’m seeing that legacy-heavy companies, or companies that see technology as a cost centre instead of as an opportunity, are struggling to adapt to the agility and distributed nature of Reactive systems. For a number of our clients, simply adopting containers or microservices was enough of a challenge, so having to describe a Reactive system to them appeared to be a bridge too far.
What is the best solution to this challenge?
I’m sure I’m about to be seen as a heretic for saying the following, but I really think that the solution to dealing with resistance to change is to demonstrate the benefits in non-technical ways. We can explain to “traditional” ops folks the ways of the Site Reliability Engineering (SRE) and how breaking our systems up into smaller units will make them more maintainable (and also accepting the fact that there will be more “things” deployed on our precious environments). After some perseverance, pragmatism and understanding on both sides, we will surely be able to reach a suitable agreement on how to implement a reactive system.
What is your most ambitious professional dream that you hope to achieve one day?
I’ve always enjoyed taking on a mentoring or teaching role, and I take any opportunities to mentor junior members of the team or run a knowledge transfer session about whatever topic. Before I had a “grown-up” job I used to be a tutor at university, which I enjoyed a great deal.
It would be good to get back into some sort of teaching or tutoring position at some stage; I’m not sure what form that’d take, but conveying my knowledge to other people has always been an interesting idea to me nonetheless.
Who should attend your talk at Reactive Summit and what will they learn?
My talk is about combining two of Akka’s coolest features (in my opinion) – clustering and distributed data. I will show you the types of problems you can solve by combining these two, with a cool Akka implementation of a super weird protocol near the end.
If you’re interested in clustering or Akka Distributed Data, or are interested in horizontally scaling your Akka application, or are having issues around maintaining state across an Akka cluster, or just want to learn about some new feature of Akka that you may not have heard about, then I recommend you come to my talk to learn a thing or two about how we can combine clustering and distributed data to have a super resilient system that will never fail! (Conditions apply!)
Whom would you like to connect with at the conference?
I’m interested in seeing how other folks are deploying Akka in all types of settings, and where they are in their journey. Our IPF product is seeing a lot of varied use and deployment around our different clients, and I’m interested to see what others are experiencing in relation to ours and possibly exchange some war stories over a beer or two.