

Is this microservice? - mrkschan
https://docs.google.com/drawings/d/1upfZP0O8Jn3izR59TmWe0F31doHQci-KGEBryYJcb6M
A web frontend to receive requests. Some requests are stored in a pub&#x2F;sub message broker like Kafka &#x2F; RabbitMQ. Some daemons would subscribe to the broker and do some work. Any processes would have HTTP REST API call &#x2F; Thrift RPC to some other functional services. Each of those functional services and daemons are load balanced.<p>Is this microservice?
======
davismwfl
It depends, likely not given the daemons are showing direct communication to
what appears to be other services etc. But in reality, I don't feel there is
enough data to answer that question completely based on the diagram.

IMO, a micro-service does only 1 thing, does not access common data
repositories and stores its own data isolated (could be same physical db
server but separate db/table/catalog etc.). Additionally, at least as I see it
a micro-service does its job and then pushes a new message on the queue with
the results, it never talks via the network layer to anyone else for
coordination or status. But of course it may send out data or make calls via
the network, e.g. HTTP, SMTP etc.

You probably already know this but from reading and my experience a micro-
service should only act upon data it receives in the message. Sometimes this
is where people have a hard time because it means passing an entire data set
with the message to make sure the micro-service has enough information to do
its job. But doing so is the only way to decouple the services and get the
benefits of a distributed system. If you use the database as a communication
layer it will cause you all kinds of headaches and it couples the services to
data structure changes which means you still are not isolated. You should be
able to update any micro-service without the need to update any other service
at the same time.

~~~
mrkschan
I was confused that a micro-service (architecture) is just renaming SOA / Rest
API / what-so-ever and connecting different components with a scalable message
bus. And, now, you point out some great distinctions from those :) ty.

'''does not access common data repositories and stores its own data
isolated'''

&

'''does its job and then pushes a new message on the queue with the results,
it never talks via the network layer to anyone else for coordination or
status'''

~~~
davismwfl
Your welcome, glad it helped clarify. Good luck!

------
peterwwillis
Why do people care about the arbitrary names used to classify custom
solutions?

~~~
aespinoza
He might be trying to learn more about Microservices by identifying the
structure in a current project. So it is a valid question.

Those names are useful to communicate ideas. It is just like software
patterns. It doesn't correlate to a direct implementation of the pattern, but
a pattern correlates to an idea, and it is extremely useful to communicate
them. Microservices are just that.

~~~
peterwwillis
That's a bit like saying, i'm trying to learn about supercars by asking if
this car is a supercar. It's a generic classification. Moreover, knowing how
to classify it does not change how you design it or why.

Unix programs are non-networked microservices. An LCD controller and display
driver could be described as a single-function single-process non-networked
microservice. It really does not matter what you call it or how it is
categorized; it just is.

Better communication is great, but we don't need a new word for every idea.
Especially if people get wrapped up in what counts as that word.

~~~
aespinoza
Microservices is a new "word" assigned to an old idea. But it is still new for
someone. I agree with you, I just think this is a valid question. It might be
improved by asking "Why is this is/isn't a Microservices architecture?

------
tinco
I'm going to say no. You can have multiple WWW/API nodes, but that's not the
main issue. The different daemons, they have to be able to connect to
eachother, and the Redis/DB/SMTP nodes, they're simply one of the
microservices. There could be any number of DB nodes. Every micro service
might have their own persistant storage or caching mechanism.

Might have, not must have, of course.

To really show the merit of microservices, this must really be reflected in
your drawing.

------
joss82
At first glance, the diagram does not look isolated enough.

There should be clear _separation_ and _interfaces_ between the different
_services_.

There seem to be only one database for all of the system, wich sets a strong
dependency between services.

Perhaps the right question is: It this microservice enough?

------
tckr
No. What was the question?

~~~
mrkschan
eh, my fault, cannot edit the post... The question is here ...
[https://news.ycombinator.com/item?id=8885965](https://news.ycombinator.com/item?id=8885965)

