which point a large thread pool will be
supplied. If the service happens to be
handling two different kinds of jobs,
we can separate them into different execution tracks.
More recently, we have also had a
fair amount of success using circuit
breakers in situations where we have
had a number of progressive timeouts
as a consequence of some third party
getting involved. But now we can just
cut the connection and carry on. Much
of this comes for free just because of
all the tools Akka provides. We have
learned that we can take much better
advantage of those tools by keeping
our designs as simple as possible.
BONÉR: Something I also find very
interesting is that Akka and Erlang appear to be the only platforms or libraries that put an emphasis on embracing
and managing failure—which is to say
they are basically designed for resilience. The best way to get the fullest
benefit of that is if they are part of your
application from Day One. That way,
you can fully embrace failure right at
the core of your architecture.
But, with that being said, how did
this newfound embrace of failure work
out in practice for those of your developers who had come from other environments with very different mindsets? Was this something they were
able to accept and start feeling natural
about in fairly short order?
BERUBE: For some, it actually required
a pretty substantial mindset shift.
But I think Akka—or at least the actor
model—makes it easier to understand
the benefits of that, since you have to
be fairly explicit about how you handle
failures as a supervisor. That is, as an ac-
tor that spins off other actors, you must
have rules in place as to what ought to
happen should one of your child actors
end up failing. But, yes, people had to
be educated about that. And even then,
it still took a bit of getting used to.
Now, as new developers come in, we
see them resort to the more traditional
patterns of handling exceptions. But
once you get some exposure to how
much saner it is just to leave that to
the supervisor hierarchy, there’s generally no turning back. Your code just
becomes a lot simpler that way, meaning you can turn your focus instead to
figuring out what each actor ought to
be responsible for.
COATTA: Talking about actor frameworks in the abstract is one thing, but
what does this look like once the rubber actually hits the road? For example,
how do you deal with failure cases?
BERUBE: You can just let the actor
fail, which means it will essentially
die, with a notification of that then being sent off to the supervisor. Then the
supervisor can decide, based on the severity or the nature of the failure, how
to deal with the situation—whether
that means spinning off a new actor or
simply ignoring the failure. If it seems
the problem is something the system
actually ought to be able to handle, it
will just use a new actor essentially to
send the same message again.
But the point is that the actor model
allows you to focus all the logic related
to the handling of specific failure cases
in one place. Because actor systems are
One of the fantastic
lessons to come out
of all this is it has
allowed me to start
thinking about how
the system actually
works in terms of
and dealing with
the external agents
with via messages.