I love the way you two go on to related yet tangential topics and still come back to the main topic at hand. Very relatable discussion. Hope you have time in the future to do deeper technical dives. :-)
A lovely way to say we ramble 😆 But, we always and genuinely try to get back to the pre-fork point! Normally, the deeper and wider the tangent, the louder for the signal for a new episode. Love the comment. Thanks so much!
Honestly I think is all about state, and calling every microservice stateless just because there is no answer for stage-management, does not solve a practical problem. Have seen the same in Networking, SDN, Forwarding graph etc. To know what a system is doing, you need state and state introspection, which is somehow "monolithic" or better called consistent...
Solving this problem is non-trivial and a dividing topic. Like you pointed out, is it a thing because it can't be a thing? Or a thing, because it's an actual thing? The stateless movement for me (entirely a personal view) is arm wavey in several dimensions. Every software system absorbs state to fulfil its purpose. For a program to execute, there are start conditions (state), run-time steady-state conditions (derived from start conditions), then there are computed conditions (state) maybe exit conditions, for instance crash logs or simple exit codes. Looking at the problem through micro-services and coupling them to NATS, gives us a means of querying what's online (nodes) and a means of forwarding data between them (data-plane). Coupling that to the KV store, we can have an intended state with the realisation of that in responses over the micro-services API. Is this the kind of thing you were thinking about, or did I miss the point? I do that, so feel free to debate and correct me! Also thanks for taking the time to comment. Much appreciated!
@@davedotdev-synadia yes… totally aligned, but as also more a statement about than a question…. Seems we can agree on that. Btw great talks on NATS FM and nice to see another network geek brings another (good ) perspective to the engineering mix targeting application communication. Looking forward to ep10
I love the way you two go on to related yet tangential topics and still come back to the main topic at hand. Very relatable discussion. Hope you have time in the future to do deeper technical dives. :-)
A lovely way to say we ramble 😆 But, we always and genuinely try to get back to the pre-fork point! Normally, the deeper and wider the tangent, the louder for the signal for a new episode. Love the comment. Thanks so much!
Honestly I think is all about state, and calling every microservice stateless just because there is no answer for stage-management, does not solve a practical problem. Have seen the same in Networking, SDN, Forwarding graph etc. To know what a system is doing, you need state and state introspection, which is somehow "monolithic" or better called consistent...
Solving this problem is non-trivial and a dividing topic. Like you pointed out, is it a thing because it can't be a thing? Or a thing, because it's an actual thing? The stateless movement for me (entirely a personal view) is arm wavey in several dimensions. Every software system absorbs state to fulfil its purpose. For a program to execute, there are start conditions (state), run-time steady-state conditions (derived from start conditions), then there are computed conditions (state) maybe exit conditions, for instance crash logs or simple exit codes. Looking at the problem through micro-services and coupling them to NATS, gives us a means of querying what's online (nodes) and a means of forwarding data between them (data-plane). Coupling that to the KV store, we can have an intended state with the realisation of that in responses over the micro-services API. Is this the kind of thing you were thinking about, or did I miss the point? I do that, so feel free to debate and correct me! Also thanks for taking the time to comment. Much appreciated!
@@davedotdev-synadia yes… totally aligned, but as also more a statement about than a question…. Seems we can agree on that. Btw great talks on NATS FM and nice to see another network geek brings another (good ) perspective to the engineering mix targeting application communication. Looking forward to ep10