Ask HN: How microservices works?
Stupid question: how exactly works microservices ? how they comunicate between different apps/languages ? they use rest api or is better use something like zeromq/rabbitmq ?
Sorry to post this here, but honestly I often hear about microservices but I don't really understand what they are.
Any good link/book/slide is welcome.
PS: I will appreciate some examples in real world by big companies(example: how they do in airbnb/uber/whatever ?)
12 comments
[ 3.6 ms ] story [ 38.0 ms ] threadEverything you mentioned, and then several other mechanisms. Whatever happens to be fashionable where they are being implemented.
> Sorry to post this here, but honestly I often hear about microservices but I don't really understand what they are.
A bunch of small applications running separately that talk to each other using different protocols (sometimes one of the RPC protocols, sometimes raw HTTP that is today called REST, sometimes ZeroMQ or AMQP or some other ESB). The idea has little more in it than this, though operationally there are still some things to figure out.
For example I don't understand why companies like airbnb (I understand for uber instead) need microservices...it's just a frontend app + backend + api. This can(could) be an single app.
1. What is a micro-service?
2. How is a micro-service architecture implemented?
The first is subject to some debate, and it's not a debate I'm particularly interested in so I'll leave it as an exercise.
Micro-service architectures are generally implemented in two ways: push and pull. A collection of REST API's will tend to produce a push architecture of explicit requests and responses. A log to which all requests and responses are written with each individual service responsible for finding applicable messages is a way of implementing a pull architecture. Queues can play a role in either but are at an implementation detail at a lower level of abstraction.
Chat bots [1] can be seen as an example of a pull architecture with a log. Bots scan the continuous stream of messages and ignore what does not apply and act upon what does apply, typically they return results to the message stream. A chat bot might have a queue to manage requests and responses (input/output) or not, but that's an implementation detail not a high level architectural one at the level of a chat system.
A chat system will tend to grow by adding more bots rather than expanding existing bots and each bot will tend to have little or no knowledge of other bots. Each bot will be independent: one will run Jenkins another will make coffee.
The big point is that services are a way of organizing a system architecture and micro-services are one granularity at which the system may be decomposed. It's probably arguable that what constitutes a micro-service versus a service is relative to the size of the overall system. In practice, what is and isn't a micro-service has some correlation to the practicality of delegating responsibility to a team <= two pizzas.
YMMV.
[1]: A chat bot might be an example of something that is small enough to be 'micro'-- or deci, nano, atto, yocto etc. -- (or not).
https://www.amazon.com/Building-Microservices-Designing-Fine...