
OF MONKEYS AND MICROSERVICES - timmillwood
http://daemon.co.za/2014/04/monkeys-and-microservices/
======
sillysaurus3
Would anyone explain this concept in technical terms, and metaphors? I need to
be sure my mental model of the design is accurate.

Also, how are messages routed to the individual microservices? The author says
that each microservice receives a note, and if the note tells it to do
something it's capable of doing, it returns a result. So my first instinct is
to assume that every message is multicasted to every microservice, and as long
as you're careful that no two microservices respond to the same type of
message, you'll always get exactly one result. (By "multicast" I just mean
"every microservice sees every message and has the opportunity to respond to
it," not literal UDP multicasting. This could be accomplished e.g. by sticking
each message into a Redis list, which every microservice reads in its
entirety. That would also give you a nice deterministic replay log for
debugging purposes.)

I'm also guessing that when a microservice generates a result, it returns that
result by e.g. stuffing it into a central Redis server, which is being polled
by some other part of the architecture which is waiting for the result.

EDIT: Sorry, I meant, does the above design sound reasonable? What are some
hidden gotchas? I just came up with it off the top of my head, so it probably
isn't great.

~~~
AdrianRossouw
that's not defined by the term, and is left up to you to decide. All it
requires is a lightweight interface, often http.

This is basically where the complex programming will be in these systems,
understanding all of the various ways to route messages and where and how to
deploy them effectively.

Seneca.js has support for redis, kafka, and so many others.

Martin Fowler's take on them (of "Refactoring" fame)
[http://martinfowler.com/articles/microservices.html](http://martinfowler.com/articles/microservices.html)

For a succinct explanation:
[http://klangism.tumblr.com/post/80087171446/microservices](http://klangism.tumblr.com/post/80087171446/microservices)

~~~
sillysaurus3
_Next post: Microservice Architectures— "what is needed to create an
architecture composed of Microservices"_

Hmm, well, I eagerly await the next post.

It seems like what's needed is a concrete, simple tutorial on coding and
deploying a microservice infrastructure. That'd demonstrate that this design
is practical and, importantly, would reveal any pain points or cornercases
that the design is susceptible to.

One pain point is that if a microservice goes down, any messages that were in
the process of being handled may be dropped. So there has to be a way to
ensure that every message eventually returns exactly one result, and that
messages are never accidentally dropped due to microservice crashes.

~~~
jively
Actually if you set you message broker up and message handling up properly,
you can get your microservice to only acknowledge receipt once it's finished
processing and output it's result. If it crashes in the process, the queue
would try to redeliver the message once the next service comes on-line. It's
built into AMQP as a standard.

------
barrkel
There is very little difference (read: almost none) between a single thread of
control transferring between objects and synchronous messages and associated
return messages flowing between independent "microservices", providing the
"microservices" aren't busy when not acting on a message or when waiting for
the return value immediately after having sent a message.

In so far as things are easier to test in isolation, it'll be due to the more
dynamically typed nature of message passing over and above traditional method
calls.

"Microservices", or actors or whatever you want to call them, are more
justified when you have concurrency inherent in your problem and you want to
avoid the trouble threads create.

------
lifeisstillgood
You seem to have fallen off the front page really fast - I suspect the all
caps got you binned - excellent article by the way.

I am working on a similar blog / articles for a similar implementation - would
be interested in sharing war stories - email is in the profile if you are
interested

(I was not planning any monkey analogies though :-)

~~~
sillysaurus3
Hmm, the post was completely buried. I'd guess it was an accidental false
positive due to the all caps title looking spammy, or a voting ring was
detected. The article itself was pretty good.

~~~
AdrianRossouw
thanks. I was wondering what happened.

Post wasn't submitted by me, and it's a pity if it was due to the text-
transform: uppercase on my headers =)

~~~
sillysaurus3
I would email info@ycombinator.com and ask for permission to resubmit it. I'm
sure it was just a misunderstanding.

~~~
AdrianRossouw
thanks man. I have requested permission.

------
datashaman
Seneca.js is awesome!

------
Top_geek
Great article

~~~
AdrianRossouw
thanks! and trust me, i am nowhere near exhausting my stash of synonyms for
simians.

