sentially glue business logic onto the
data part of the logic. But in terms of
the size of these things, I’d say we’re
still trying to figure that out, and we
haven’t come up with any hard and fast
rules so far.
BONÉR: I’m guessing each of your microservices owns its own data store. If
so—with these things being stateful—
how are you then able to ensure resilience across outages?
STEEL: Each of these services absolutely owns its own data. When it comes
to replacing parts of the monolithic system, it generally comes down to dealing
with a table or a couple of related tables
from the LAMP MySQL database. Generally speaking, the space is pretty minimal in terms of the services that need
to be accounted for. It’s basically just a
matter of retrieving and creating data.
BERUBE: I would say we make fairly
heterogeneous use of various technologies for data storage. And, yes, we do
come from a LAMP stack, so there is
still a heavy reliance on MySQL, but we
also make use of MongoDB and other
The services typically each encapsulate some area of the data. In theory,
at least, they are each supposed to own
their data and rely on data storage dedicated only to them. So, we have recently
started looking into storing a bit more
data within the services themselves for
reasons of efficiency and performance.
COATTA: To be clear, then, there’s
some separate data-access layer
from which the services are able to
pull in whatever information they
need to manipulate?
were first building our system. When
we were starting out, we learned more
about how we should be building the
system, as well as about how actors really ought to work. At first, we definitely
fell into the trap of putting too much
logic into single actors—for example,
by putting recovery logic into each actor instead of relying on the supervision hierarchy, which would have allowed us to code less defensively. It
turns out it’s best just to embrace the
“let it crash” philosophy, since that actually offers a lot of robustness.
We also learned the model really
shines whenever you separate concerns into single-purpose actors. Besides helping to clarify the design,
it opens up a lot of opportunities in
terms of scalability and configuration
flexibility at the point of deployment.
BONÉR: This applies to microservices
as well. That is, there are plenty of
opinions about what even defines a microservice. What does that term mean
to you? And how does that map conceptually to how you view actors?
BERUBE: Internally, we are still trying to define what a microservice is
and what the scale of that ought to be.
Today, most of our services focus on
accomplishing just one set of highly related tasks. Our goal is to have each of
these services own some part of our domain model. Data services, for example, would each control their own data,
and nothing else would have access to
that. To get to that data, you would have
to go through the data service itself.
Then we would also have functional
services, which are the services that es-
Something I find
is that Akka and
Erlang appear to be
the only platforms
or libraries that
put an emphasis
on embracing and
which is to say
they are basically