the problem with "microservices" is the "micro". Why we thought we need so many tiny services is beyond me. How about just a few regular sized services?
I have always understood "micro" to be referring to "scope", not to "size".
Microservices should form a polytree
71–80 of 121 posts
Re: Microservices should form a polytree
#72What are you trying to protect yourself against?
1. Microservices imply distributed computing. So work with the grain on that - which is basically message passing with shared nothing resources. Most microservices try to do that so we are pretty good from a technical pov
2. Semantic loops - which is kind of what we are doing here with poly trees. This is really trying to model the business in software
Now here comes the hard part - this is not merely hard it’s sometimes bad politics to find out how a business really works. Is think far more software projects fail because the business they are in is unwilling to admit it is not the shape they are telling the software developers it is. Politics, fraud or anything in steer.
Re: Microservices should form a polytree
#73Back in the day an OS called CTOS hosted what were essentially microservices. This acyclic problem was solved there, by not letting the essential OS services ever wait on a service response. It simply registered the outstanding service request and went back to servicing its own request queue.
I thought at the time, this was an elegant solution to the deadlock problem.
Re: Microservices should form a polytree
#74So a data flow path that is a dag. Yeah, sounds right.
Also seems close to Erlang / Elixir supervision trees, which makes sense as Erlang / Elixir basically gives you microservices anyway...
Re: Microservices should form a polytree
#75the problem with "microservices" is the "micro". Why we thought we need so many tiny services is beyond me. How about just a few regular sized services?
Micro is a relative term. And was coined by these massive conglomerates, where micro to them is "normal sized" to us.
They work better if you ignore what "micro" normally means.
But "not too too large services" doesn't quite roll off the tongue.
Re: Microservices should form a polytree
#76Earlier quoted context omitted.
The explanation given makes sense. If they're operating on the same data, especially if the result goes to the same consumer, are they really different services? On the other hand, if the shared service provides different data to each, is it really one microservice or has it started to become a tad monolithic in that it's one service performing multiple functions? I like that the author provides both solutions: join…
I don't understand this. Can you help explain it with a more practical example? Say that N1 (the root service) is a GraphQL API layer or something. And then N2 and N3 are different services feeding different parts of that API—using Linear as my example, say we have a different service for ticket management and one for AI agent management (e.g. Copilot integration). These are clearly different services with different…
I tried and cannot. Just keep thinking of it as: if something is doing 2 jobs, split it, if 2 things have the same as they say goes-in-tos and -goes-out-ofs, combine them. And same doesn't mean bit for bit match (though obviously don't needlessly duplicate data), but just a bit higher level.
The problem is that I don't sit in the microservice or enterprise backend spaces, so I an struggling to formulate explanations in those terms.
Re: Microservices should form a polytree
#77Earlier quoted context omitted.
Yeah if services can't be used by multiple other services, then what's the point?
The article doesn't make that claim. For example, the service n7 is used by multiple other nodes, namely n3 and n4. There is no cycle there, so it's okay.
but why is having multiple paths to a service wrong ? The article just claims "it does bad things", without explaining how it does bad things and why it would be bad in that context.
Re: Microservices should form a polytree
#78I have a question. Does the directed / no cycles aspect mean that webhooks / callbacks are forbidden.
I work a lot in the messaging space (SMS,Email); typically the client wants to send a message and wants to know when it reached its destination (milliseconds to days later). Unless the client is forbidden from also being the report server which feels like an arbitrary restriction I'm not sure how to apply this.
Re: Microservices should form a polytree
#79Here's a really simple way to get a cycle. Service A: publish a notification indicating that some new data is available. Service B: consume these notifications and call back to service A with queries for the changed data and perhaps surrounding context. What would you recommend when something like this is desired?
That's not a cycle - service B isn't writing any new data to A.
Re: Microservices should form a polytree
#80This seems cool if all you need is: call service -> Get response from service -> do something with response.
How do you structure this for long running tasks when you need to alert multiple services upon their completion?
Like what does your polytree look like if you add a messaging pub/sub type system into it. Does that just obliterate all semblance of the graph now that any service can subscribe to events? I am not sure how you can keep it clean and also have multiple long running services that need to be able to queue tasks and alert every concerned service when work is completed.