3 ms·

OF MONKEYS AND MICROSERVICES

24 points by timmillwood 13y ago

datashaman 13y ago
Seneca.js is awesome!
Top_geek 13y ago
Great article
- AdrianRossouw 13y ago
  thanks! and trust me, i am nowhere near exhausting my stash of synonyms for simians.
sillysaurus3 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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.
  - lerouxb 13y ago
    Sheesh. That Martin Fowler article is the type of thing that immediately makes my eyes glaze over.
  - 13y ago
lifeisstillgood 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      I would email info@ycombinator.com and ask for permission to resubmit it. I'm sure it was just a misunderstanding.
      - AdrianRossouw 13y ago
        thanks man. I have requested permission.
barrkel 13y ago
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.

24 points by timmillwood 13y ago

datashaman 13y ago

Seneca.js is awesome!

Top_geek 13y ago

Great article

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

sillysaurus3 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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.
- lerouxb 13y ago
  Sheesh. That Martin Fowler article is the type of thing that immediately makes my eyes glaze over.
- 13y ago

lifeisstillgood 13y ago

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 13y ago
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 13y ago
  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 13y ago
    I would email info@ycombinator.com and ask for permission to resubmit it. I'm sure it was just a misunderstanding.
    - AdrianRossouw 13y ago
      thanks man. I have requested permission.

barrkel 13y ago

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.