COATTA: Let’s talk a little about the
impact the move to microservices
has had on your developers. In particular, I would think this means you
are throwing a lot more asynchrony
at them than most developers are accustomed to. I imagine they probably
also have a lot more data consistency
issues to worry about now.
BERUBE: Although the asynchrony
problem hasn’t been fully addressed,
Scala Futures (data structures used to
retrieve the results of concurrent operations) actually make it really easy to
work with asynchronous computation.
I mean, it still takes some time to adjust to the fact that anything and everything can and will fail. But, with Scala
Futures, it’s actually quite easy for relatively uninitiated programmers to
learn how to express themselves in an
STEEL: If you are coming at this from
the perspective of thread-based concurrency, it’s going to seem much scarier for a lot of use cases than if you’re
coming at it from a Futures point of
view. Also, when you’re working directly inside actors, even though messages
are flying around asynchronously and
the system is doing a thousand things
at the same time, you are insulated
from what it takes to synchronize any
state modifications, since an actor will
process only one message at a time.
KEN BRITTON: I have noticed when
developers first start writing Scala,
they end up with these deeply nested,
control-flow-style programs. You see a lot
of that in imperative languages, but there
is no penalty for it. In a strongly typed
functional language, however, it is much
more difficult to line up your types
through a complex hierarchy. Developers
learn quickly that they are better served
by writing small function blocks and
then composing programs out of those.
Akka takes this one step further by
encouraging you to break up your logic
with messages. I’ve observed a common evolution pattern where developers will start off with these very bulky,
complex actors, only to discover later
that they could have instead piped a
Future to their own actor or any other
actor. In fact, I’ve witnessed a number
of aha moments where developers hit
upon the realization that these tools
actually encourage them to build
smaller composable units of software.
BONÉR: That matches my experience as well. Actors are very object
oriented, and they encapsulate state
and behavior—all of which I think of
as mapping well to a traditional approach. Futures, on the other hand,
lend themselves to functional thinking—with all these small, stateless,
one-off things you can compose easily. But have you found you can actually make these things derived from
two very different universes work well
together? Do you blend them or keep
BERUBE: We have used them together in parallel, and I think they work
well that way. Ken mentioned this
idea of generating Futures and then
piping them either to yourself as an
actor or to some other actors. I think
that pattern works quite well. It’s
both simple and elegant.
STEEL: I have to admit I stumbled
over that mental shift a bit early on.
But, yes, I’d say we have been able to
blend actors and Futures successfully
for the most part.
BONÉR: Do you feel that certain types
of problems lend themselves better to
one or the other?
STEEL: In our simpler services, the
routing of a request to the code is all actor based, and then the actual business
logic is generally written as calls to other
things that produce Futures. I suppose
that when you’re thinking about infrastructure and piping things around, it’s
very natural to think of that in terms
of actors. Business logic, on the other
hand, perhaps maps a little more readily
to the functional point of view.
BRITTON: We are also finding that a
rich object-oriented model is helpful in
our messaging. For example, we have
started defining richer success and
failure messages containing enough
detail to let an actor know exactly how
to respond. So, now our message hierarchy has expanded to encapsulate
a lot of information, which we think
nicely aligns object-oriented concepts
with the actor model.
COATTA: One thing that occurred to
me as you talked about your environ-
ment is that it seems you have moved
not only from a monolithic architec-
ture, but also, in some sense, from
a monolithic technology to a much
wider array of technologies. So I won-
der if you now find it more difficult
to operate in that environment, as
well as to train people to work in it.
Whereas before maybe it was suffi-
cient just to find some new hires that
were proficient in PHP, now you have
ZeroMQ and actors and Futures and
any number of other things for them
to wrap their heads around. Without
question, your environment has be-
come more complex. But is it now in
some respects also actually an easier
place in which to operate?
BERUBE: I think the act of dividing
the logic into a lot of different self-contained services has made it easier at
some level to reason about how the system works. But we are not finished yet.
There is still plenty of work to do and
lots of challenging areas to continue
And, yes, of course, the environment has become a bit more complex.
I have to agree with that. But the benefits outweigh the drawbacks of rolling in all this technology, since we now
have more layers of abstraction to take
advantage of. We have teams that are
generally aware of the big picture but
are mostly focused on just a few microservices they understand really well.
That’s an approach that will have huge
benefits for our operations as we scale
them moving forward.
BRITTON: It has become apparent
how critical frameworks and standards are for development teams
when using microservices. People often mistake the flexibility microservices provide with a requirement to
use different technologies for each
service. Like all development teams,
we still need to keep the number of
technologies we use to a minimum so
we can easily train new people, maintain our code, support moves between
teams, and the like.
We have also seen a trend toward
smaller services. Our initial microservices were actually more like loosely
coupled macroservices. Over time,
though, we have pushed more of the
deployment, runtime, and so forth into
shared libraries, tooling, and the like.
This ensures the services are focused on
logic rather than plumbing, while also
sticking to team standards.
Copyright held by authors/owners.
Publication rights licensed to ACM. $15.00.