Is this microservice?(docs.google.com)
docs.google.com
Is this microservice?
https://docs.google.com/drawings/d/1upfZP0O8Jn3izR59TmWe0F31doHQci-KGEBryYJcb6M
7 comments
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.
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.
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'''
'''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'''
Your welcome, glad it helped clarify. Good luck!
Why do people care about the arbitrary names used to classify custom solutions?
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.
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.
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.
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.
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?
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.
Might have, not must have, of course.
To really show the merit of microservices, this must really be reflected in your drawing.
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?
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?
No.
What was the question?
eh, my fault, cannot edit the post... The question is here ... https://news.ycombinator.com/item?id=8885965
Is this microservice?