Ask HN: How microservices works?
12 comments
Very good read that gives a pretty high level description of services:
https://www.amazon.com/Building-Microservices-Designing-Fine...
https://www.amazon.com/Building-Microservices-Designing-Fine...
There are two related questions:
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).
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).
Lets say you have an ecommerce firm. When a user is browsing an item(diapers?), at a mimimum he/she expects to see images, description, reviews, cost, tax, delivery dates, promotions, related items. In addition to what you see on frontend, in the backend, there may be jobs run for analytics, revenue reconciliation, warehouse management optimization, carrier management, fraud checks, item data setup and a host of other activities. Each of these tasks has its own complex business logic and typically has its own team. Each team runs a service, possibly in the form of a REST API call. You can call them microservices.
> how [microservices] comunicate between different apps/languages ? they use rest api or is better use something like zeromq/rabbitmq ?
Everything 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.
Everything 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.
Ok, you know any good talk/slide with real examples ?
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.
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.
The backend does many different things, hence could be split into microservices
Here's a good talk that, while it mentions how Amazon use micro-services, it's very broad, and will probably leave you with more questions then answers:
https://youtu.be/6K4ljFZWgW8?list=LL9RQYUX_WIjk8SAcyuarJEw
(The Future of Software Engineering • Mary Poppendieck)
I would strongly suggest to read the book "Building Microservices" by Sam Newman. He gave fair good description of what it is and what are the considerations you need to think when build it.
for example. a calculator as a service. where users can add substrct divide and multply. devision turns out to be most in demand and is thus turned into its own service with separare hardware and team.
Take a look at http://learnmicroservices.io
That has links to numerous resources including some introductory articles.
they can be compleatly isolated. and are often used as a scale out strategy. or an optimization where a botleneck is taken out from a monolith so it can scale independenly.
[deleted]
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 ?)