Thank you so much for this video series, really appreciate the contribution to the community. It’s people like you who make this into a vibrant community.🎉
I proposed server/self registration as a solution on a problem for our High Available microserices. Works like a charm now! Thanks very very much for your content! Percise and to the point! And the diagrams just amazing! Keep up the good work!
Excelente! Siempre me ha gustado esa manera de explicar con el papel, lápiz y dibujos que tiene este canal. Todo queda explicado en una forma clara y práctica
Typically SOA was associated with a more structured way of developing services. There were things defined like services taxonomy, a service bus, wsdl documents that allow you import easily another service API and lots of XMLs. Microservices then came as a leaner approach where the idea is that you just create small services that talk to each other, typically over REST (but not exclusive). Then came the debate on how small should a "micro" service be. From there a bunch new of additional design patterns arose like API Gateway, Sagas, etc. To me, in essence they are the same, and just differ in the implementation details. You just do you system designs taking in consideration the basics (design principles, maintainability, domain driven design, etc) and trying not to overcomplicate things (by not having too much structure as typical SOA if not needed, and not making services so small that orchestrating and monitoring becomes a headache).
Yes HTTP would be the protocol but typically you will call it from one service to call another service. These are implemented in a specific language. Each language will have utils to make it easier to make http calls, and the higher level you code, the less you deal with the specific details of lower level like the http protocol
@@ADevStory That has nothing to do with the service discovery itself. You interact with it using HTTP. Would it be useful to create a package that implements theunderline HTTP calls and exposes functions? For sure. But you can say that about any service. When you interact with Authentication service you will probably use some sort of Auth0 package. However, that doesn't make Auth0 is language-agnostic right?
That's actually the point. If the network routing is hidden to your service (proxy) you don't need to implement anything on the client. If you have the routing in the client then you need to implement it. Not possible to make it language-agnostic because is on the client. You can create a generic library but your actual service needs to call that library. In the proxy one you just call another URL that will get you what you want. Hope is clearer :)
Yes. But if your client needs to access another service you need to implement that code in your client's programming language. So if you have a python service A that needs to talk to your service registry you need that client code in Python that's is able to call the service registry and understand the protocol in Python. Then, if you have another service B in nodejs you need to do the same as well. Hope is clear.
@@ADevStory so language dependency comes in between a client and service registry not necessarily between the client and the service(s) it wants because these can communicate via RESTful APIs(not exclusive) right?
@@talentoutput2153 partially. So everyone you connect 2 systems you need to implement a connections n between them. If it is a REST API, it will go via http and most languages implement already that. Same for parsing the responses. If you add more validations on top of the calls or custom logic, you may need to replicate that across different services. If they are in the same language it's just about importing a library. If it's in different languages then you need to implement that library in multiple languages
انا باخد معاش والدي وانا ارمله واخو انا باخد معي انا ارمله وانا باخد معاش والدي واخويا قسم لي في المعاش وهو ليه تامين رخصه واتوقف عنه معاش والده هل معاش والدي يرجع لي منه ثاني 1:05 يا قسمني في المعاش وهو بياخد تامين
I've used and I have seen it being used at work. Really relevant when needing systems that are populated via event sourcing. Otherwise to do CRUD operations or most web applications where only data input directly by the user is added is not necessary to use.
Thank you so much for this video series, really appreciate the contribution to the community. It’s people like you who make this into a vibrant community.🎉
Oh thanks for the kind words!
I proposed server/self registration as a solution on a problem for our High Available microserices. Works like a charm now!
Thanks very very much for your content! Percise and to the point!
And the diagrams just amazing!
Keep up the good work!
Nice! Glad it worked ! Thanks for the feedback!
i love how your videos are so on point and direct !!! thank youuu
Oh thank you! Glad you like them!
Your videos are very concise and informative! Thank you for taking the time and making them. Looking forward to the next video on Service Meshes!
Thank you! Glad it was useful for you!
Your videos are upto the point and crystal clear to understand, hats off.
Thank you! Glad it was useful!
already waiting for Service Mesh video! Awesome job, congratulations !
Thank you!
Excelente! Siempre me ha gustado esa manera de explicar con el papel, lápiz y dibujos que tiene este canal. Todo queda explicado en una forma clara y práctica
¡Me alegra que lo disfrutes y sea útil! ¡Gracias por el feedback!
Thanks for your short videos! Keep it up
Thanks!
Excellent playlist, loved every bit of it.
Thank you!
I am now following your "Services" without a second thought 😄. Many Thanks 👌
Hahaha amazing! Thanks! Glad you liked it!
Yeah. A perfect opportunity to use the word "Subscribe" literally 😆@@ADevStory
This is applied for instances as well in a composition for example
thank you Sir for sharing your knowledge
Thank you for watching and the feedback!
Thanks for sharing
Thank you for the explanation, it was cool 👍
Glad you enjoyed it! Thanks!
Use microservices if method call is too fast.
you are pro, thanks!
Thanks! Glad you enjoyed!
is api gateway service discovery? Because api gateway also stores the services IP location and so on.
Good question! The short answer is: no. The api gateway uses service discovery to find the service to call
Hi , what is different between SOA and Microservice Design ?
Typically SOA was associated with a more structured way of developing services. There were things defined like services taxonomy, a service bus, wsdl documents that allow you import easily another service API and lots of XMLs.
Microservices then came as a leaner approach where the idea is that you just create small services that talk to each other, typically over REST (but not exclusive). Then came the debate on how small should a "micro" service be. From there a bunch new of additional design patterns arose like API Gateway, Sagas, etc.
To me, in essence they are the same, and just differ in the implementation details. You just do you system designs taking in consideration the basics (design principles, maintainability, domain driven design, etc) and trying not to overcomplicate things (by not having too much structure as typical SOA if not needed, and not making services so small that orchestrating and monitoring becomes a headache).
I didn’t your point regarding “language agnostic”… Why would I need a language-based package? HTTP wouldn’t be enough?
Yes HTTP would be the protocol but typically you will call it from one service to call another service. These are implemented in a specific language. Each language will have utils to make it easier to make http calls, and the higher level you code, the less you deal with the specific details of lower level like the http protocol
@@ADevStory
That has nothing to do with the service discovery itself. You interact with it using HTTP. Would it be useful to create a package that implements theunderline HTTP calls and exposes functions? For sure. But you can say that about any service. When you interact with Authentication service you will probably use some sort of Auth0 package. However, that doesn't make Auth0 is language-agnostic right?
That's actually the point. If the network routing is hidden to your service (proxy) you don't need to implement anything on the client. If you have the routing in the client then you need to implement it. Not possible to make it language-agnostic because is on the client. You can create a generic library but your actual service needs to call that library. In the proxy one you just call another URL that will get you what you want.
Hope is clearer :)
awesome.... just absolutely awesome content. One of the best, totally underrated. Thanks.
Glad you liked it!
Why the access of service discovery (client or server side) should be language dependent ? Aren't they calling Web Services ?
Yes. But if your client needs to access another service you need to implement that code in your client's programming language. So if you have a python service A that needs to talk to your service registry you need that client code in Python that's is able to call the service registry and understand the protocol in Python.
Then, if you have another service B in nodejs you need to do the same as well.
Hope is clear.
@@ADevStory so language dependency comes in between a client and service registry not necessarily between the client and the service(s) it wants because these can communicate via RESTful APIs(not exclusive) right?
@@talentoutput2153 partially. So everyone you connect 2 systems you need to implement a connections n between them. If it is a REST API, it will go via http and most languages implement already that. Same for parsing the responses.
If you add more validations on top of the calls or custom logic, you may need to replicate that across different services. If they are in the same language it's just about importing a library. If it's in different languages then you need to implement that library in multiple languages
انا باخد معاش والدي وانا ارمله واخو انا باخد معي انا ارمله وانا باخد معاش والدي واخويا قسم لي في المعاش وهو ليه تامين رخصه واتوقف عنه معاش والده هل معاش والدي يرجع لي منه ثاني 1:05 يا قسمني في المعاش وهو بياخد تامين
Basically no one ever uses cqrs. This is just talk as architect to show off knowledge.
I've used and I have seen it being used at work. Really relevant when needing systems that are populated via event sourcing. Otherwise to do CRUD operations or most web applications where only data input directly by the user is added is not necessary to use.
Cannot thank you enough. Open Patreon for your channel, I will subscribe. (or use TH-cam one)
Oh thank you very much! I've been thinking about it but need to have more time to dedicate to the channel. Maybe in the future 😀