A Principal Software Engineering Manager at Microsoft, Sergey Bykov is one of the founders of the Orleans project at Microsoft Research which development he continues to lead, among his other projects. Before joining Microsoft Research, Sergey had worked in several Microsoft product groups, from BizTalk and Host Integration Server to embedded operating systems for Point of Sale terminals to Bing.

At Reactive Summit in Montreal, Sergey is doing a talk“Distributed Transactions are dead, long live distributed transactions!” covering Orleans and how it pioneered the Virtual Actor Model that offered a compelling alternative, especially for building scalable distributed applications.

In advance of his talk, we spoke to Sergey about his passion for the open source community, the challenges companies deploying Reactive face and his biggest professional dream.

What is your background and what sparked your interest in distributed systems?

I worked in several product groups at Microsoft before starting to really focus on distributed systems: BizTalk Server, Embedded Devices, Bing. I saw first-hand how difficult it was to scale a traditional 3-tier service backed by SQL with senior developers spending time on debugging low-level issues instead of working on a broader set of problems.

That turned my interest towards providing software engineers with a set of tools that would free them up from the lower level concerns and making them much more productive in building distributed systems that would scale easily. The challenge here is how to make such tools easy to use for non-expert developers while also not taking away the power from expert engineers.

What problems do you solve as a part of your day-to-day job and what is your most favourite part about your role?

A major part of my day-to-day job involves balancing the development work of my team between incremental improvements and fixes and major investments into new ambitious features. There is always new information coming in and unexpected things happening. There are always decisions to be made, and often with incomplete information.

My most favourite part is interacting with our open source community: via GitHub, Gitter chat or in person. People all around the world report issues, ask for advice, contribute ideas and code, validate fixes, provide feedback. All that happens nearly 24/7 across continents and time zones. I’m still amazed how far we’ve come from the era of shipping boxed software.

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’m really bad at making predictions. I feel maybe we need to emphasize the benefits that the reactive patterns bring more than the implementation details of how that is done. I see that the term “reactive” still confuses some developers – they assume it’s for building interactive applications. If we could bring fault tolerance, scalability, and decoupling into the forefront, that might help with the adoption of these important patterns.

I had a somewhat similar challenge explaining Orleans. When I talked about “virtual actors”, many developers were confused, especially those (the majority) unfamiliar with the Actor Model. When I switched to presenting the same concept as “distributed virtual objects”, I saw a much better traction with various developer audiences.

What is the biggest challenge companies deploying distributed Reactive systems are facing?

In my view, it’s still the challenge of fault tolerance. It’s difficult to think about and to test for.

What is the best solution to this challenge?

The approach we’ve taken in Orleans is to handle most of such failures at the framework level with the promise of virtual actors (that we call grains) that get automatically recovered by the runtime upon a next request. That frees developers up from dealing with most of the recovery complexity, as their business logic objects appear always available. This, of course, doesn’t solve all of the fault tolerance challenges one might have in a distributed system. But I do believe this general approach is very powerful.

What is your most ambitious professional dream that you hope to achieve one day?

I want to see the time when we’ll truly write code to run “up there”, with no concerns about servers, packages, containers, VIPs, and other infrastructure aspects. I’d like storage to be just a “checkbox” on my code class with no need to choose specific databases and schemas. I’d like entities of my application to be subject to intuitive access control that would allow them to be easily exposed to authorized clients and for integration with other systems, all that specified in a declarative manner with built-in validation, monitoring, and analysis tools helping do it right and safe.

Who should attend your talk at Reactive Summit and what will they learn?

I expect that some people will be shocked to hear me talking about distributed transactions in 2018. I plan to challenge the “common wisdom” that distributed transactions don’t scale and to show why and how we are adding support for them to Orleans. In my experience, eventual and strong consistencies are simply complementary to each other, and both have a place in architectures of modern reactive distributed systems. Hence, I expect to see attendees that are interested in such topics and curious about non-conventional approaches to the Actor Model, middleware, and software architecture in general.

Whom would you like to connect with at the conference?

I’d like to learn about some interesting approaches people have taken in building their systems and share what we’ve tried to do over the years, what worked and what didn’t. I’m coming from the .NET background and expect most people at the conference to be from the JVM ecosystem. In my opinion, these two worlds still don’t cross-pollinate enough. I anticipate attendees of the Reactive Summit to be experienced practitioners that collectively have a huge amount and a wide range of experiences. So there should be quite a bit for me to learn.