could take advantage of Akka as an
available library. That was a big part of
the decision as well.
In fact, I think we were able to use
some actors right from the start. That
was with a very early version of Akka,
but it still offered a lot of compelling
features we found useful.
BONÉR: Were you already thinking in
terms of microservices back then, even
before that took off as a buzzword? Or
were you more drawn by reactive prin-
ciples having to do with things like a
share-nothing architecture, strong iso-
lation, and loose coupling?
STEEL: Microservices were always in
the back of our minds. We already had
some batch processes written in PHP
that were starting to run jobs at that
point. That sort of worked, but it was
far from an ideal way of doing things.
So I think we had already started to de-
velop an appetite for a system on which
we could build a few services, with the
thought being that perhaps we could
then move toward a service-oriented
architecture. The idea of microservices
wasn’t something that came up until a
little later, and that was probably influ-
enced by some of the buzz around the
industry at the time.
COATTA: You have already mentioned
Akka a couple of times, so can you
speak to how that fits in here?
S TEEL: At that time, at least, the main
appeal of the Akka system for the JVM
was that it provided people beyond the
Erlang community with access to the
actor model. The thing about actors is
that they are both message based and
highly resilient—which is to say that
even when they crash, they can typi-
cally be brought back in a useful way.
This probably explains why Erlang has
so often been used to develop resilient
telecommunications systems. When-
ever you are talking about distributed
systems or some system where you ex-
pect to fire a lot of messages around,
you can expect the actor model to re-
YANIK BERUBE: Just in terms of where
this fits into our current infrastructure,
we should note that all our microser-
vices are powered by Akka. Internally,
we have a server-type library that han-
dles requests and responses via Akka,
and we also have at least one, if not
more, back-end services that use sets
of actors to accomplish work at certain
intervals of time.
COATTA: One of the things that
comes to mind when I think of the
Erlang actor system, beyond the in-
dependence you have already men-
tioned, is that it’s quite fine-grained.
So I wonder, given your focus on no-
tifications to user mobile devices,
whether you might actually require an
actor per user just to deal with that?
STEEL: In our case, no. But symptoms of that definitely showed up as we