This is very succinct. To think I spent a lot of time last year trying to explain the pros/cons of call and response model vs orchestration model for an ecommerce cart and order system, when I could have just linked this video 😅
@morespinach98326 ай бұрын
Orchestration means many things, apparently.
@alexsiuwh2 жыл бұрын
This is a very valid issue coming into micro services design. I came across to actually merging several services into one on a high transaction volume system. Thanks very much for sharing
@CodeOpinion2 жыл бұрын
Great to hear!
@alokrm3 жыл бұрын
Pretty good explanation. You actually explained pretty well the MS architectural challenges and how to solve them. Looking forward for more videos . Thanks
@CodeOpinion3 жыл бұрын
Appreciate the comment!
@stefangabor59852 жыл бұрын
Hi Dereck, Super clear explanation. It is the 1st video which clearly outlines the need for events. Great Job!
@CodeOpinion2 жыл бұрын
Glad you enjoyed it!
@mikemccarthy98553 жыл бұрын
8:26 "If you have services that are making synchronous calls to other services to get data you may want to look at boundaries to see if they're actually correct." This is the problem with REST API's and microservices. You need API's for UI's to compose together a page of data from different services. Where most people go wrong is those same API's are then used for exactly what you said in your video, for getting data from other services for the currently executing service to do its job. At the heart problem is not understanding CQRS and how that translates into a microservices architecture. The API's that get data from microservices are CQRS "reads". Those API's are not to be called by other services. Why? Because by doing that, you've essentially opened the door to logical coupling at the data level. All the work you did to separate the data and encapsulate it into each service is essentially undone when you allow service A to call service B's CQRS "read" API in order to get data. What will service A do with that data? Most likely, persist it. If each service is doing this, then all autonomy, both at the logical level and the physical level is gone. Another way to think about it is when you are in a given service executing a business operation, you are essentially processing a CQRS "command" not a CQRS "read". All the data to process that command should be present in that service, you should NOT be reaching out to other services to get data you need (CQRS "read") while in that operation. If you do this correctly, you'll start to see the way you achieve read/write separation in your architecture (CQRS) is the API's become your "reads" and the messages become your "writes".
@CodeOpinion3 жыл бұрын
Ya, I like that you just said all the data you need to process command should be in that service. I didn't say that exactly, but that's what I meant from what you quoted. Appreciate the comment!
@calvinzhu74382 жыл бұрын
First of all, it is very good video to expose all the concerns of Microservices which exposed with REST APIs. And I guess it would be more durable to implement WCF web services instead of Rest API for internal apps. Or maybe messaging queues instead of rest apis ?
@CodeOpinion2 жыл бұрын
Anything that is a direct network request/response from service to service is going to have the problems outlined. Decoupling via asynchronous messaging removes the temporal aspect.
@iandrake46833 жыл бұрын
Nice video. When devs at my client talk about micro services, this is one of the conversations I try to have. I ask them to define the transactional boundaries and to be realistic about the current interdependency between silos. This usually kills the enthusiasm as I do not believe they are not a good candidate for micro services anyway.
@CodeOpinion3 жыл бұрын
Yes is a required conversation to get boundaries in order. There will be required communication between services for a long running process/workflow, however these can generally be done via messaging.
@gigiduru1252 жыл бұрын
also what if those boundaries change in the future?
@BinarySpike Жыл бұрын
Derek: "Do you know what the default timeout is?", Me: "Yes ☹"
@robertsedgewick12663 жыл бұрын
Excellent explanation. Your channel is a gem, thanks for sharing!
@CodeOpinion3 жыл бұрын
Glad you think so!
@efrenb53 жыл бұрын
But now you've coupled your whole system to the message broker. What happens when that guy breaks? You end up in the same situation: full system fire because the broker is down.
@CodeOpinion3 жыл бұрын
Generally you persist messages locally before going to the broker for this reason. Avoiding a distributed transaction with a broker. Most messaging libraries support it. Check out my video on the outbox pattern. kzbin.info/www/bejne/q2nJgKGudt1-fs0
@CassioRogerioEskelsen3 жыл бұрын
No system is perfect, but the chances of a well-configured broker going down are less than a poorly behaved microservice to stop an entire business process running. And it is very easy to implement contingencies.
@evilroxxx3 жыл бұрын
You could also have broker redundancy by implementing primary and replicas with automatic failover
@dusan-minic3 жыл бұрын
Really getting valuable insight from this channel Distributed services are my main focus lately, and your videos are really concise and well explained. Good job.
@CodeOpinion3 жыл бұрын
Thanks! Glad they are helpful
@thilehoffer3 жыл бұрын
Great video. Good, old fashioned class libraries have been working fine for my team for years.
@CodeOpinion3 жыл бұрын
Meaning all in-process in a single transactions? It can work, and it's all trade-offs. I've been thinking about creating a video around what those trade-offs are and why you might want to stick with a monolith or microservices, or where I've been advocating a loosely coupled monolith, which is kind of in the middle.
@robert57633 жыл бұрын
@@CodeOpinion I think such video would be valuable so consider making it. I would also like a detailed video about how to handle compensating transactions and the edge cases such as payments.
@rafaspimenta2 жыл бұрын
Very nice article! One option that I use for some cases is create a cache for other microservice datas. So, I get the data from the cache instead of perform a http request. The cache is updated via event message. Thanks
@YoutTubeHandle3 жыл бұрын
Great video. Short and to the point...not sure why 3 dislike. It's really discourage the creator if you simply hit the dislike without any comment about why.
@CodeOpinion3 жыл бұрын
It's fine. If someone disagrees, they can dislike. A reaction is better than no reaction.
@liam32843 ай бұрын
I have seen this go wrong. Storage array was under load, database took a while to complete. service b times out waiting for service a, which eventually completes the transaction. Service b then sends the same request again, where service a makes a duplicate entry.
@CodeOpinion3 ай бұрын
Indeed. "failure" response when the request doesn't actually fail.
@fabriciopontesdearaujo75912 жыл бұрын
Could be an interesting idea in your example to make warehouse being implemented in a interface/service manner: API just feed an execution queue and return an receipt to sales to it request results in another API call? In that way, the timeout problem disappear since the return of the initial call is just creating the queue item instead of executing the whole task. Last system I developed it worked very well.
@fabriciopontesdearaujo75912 жыл бұрын
I discovered your channed today. Very good video.
@CodeOpinion2 жыл бұрын
Thanks for the comment. I've done a bunch of videos, most related would be the video on Event Choreography & Orchestration: kzbin.info/www/bejne/qICcc4upoZl0g7M
@vivienh.missamou2083 жыл бұрын
you'are lucid.thanks
@xReDCrIsTx3 жыл бұрын
I didn't understand how to fix distributed transactions. I mean, I understand the issue, not the solution haha. For instance: I have 3 microservices, and they receive a request that is valid for microservice A and B but not for C ( not because C is slow or down ) the request itself is incorrect for that MS. In that case, the right approach to fix that would be to send a rollback transaction to all microservices involved in that transaction. Right? Amazing video!!! Thanks!
@CodeOpinion3 жыл бұрын
Check out this video on event choreography and orchestration kzbin.info/www/bejne/qICcc4upoZl0g7M
@xReDCrIsTx3 жыл бұрын
Thanks!!
@louistiches48109 ай бұрын
Why do they need their own database? It feels like I am just managing more tiny monolithic apps. I am very new to microservices and I have only really created B2B applications for orgs that do just fine with a monolithic ROR app.
@francescodente28763 жыл бұрын
Hi Derek! I was wondering how to go about notifying the frontend of an event that occurs within the execution of a saga. Using the example from the video, let's say the frontend sends an http request to the sales service asking to place an order. From what I understood, the request immediately returns successfully after starting the saga. Now, I'd like the frontend to get notified when the shipping label is created succesfully. How is this done if the UI is not aware of the internal communication between services? Thanks in advance.
@CodeOpinion3 жыл бұрын
Events! Having a component in your UI be handling events for this purpose. If we're talking web or mobile frontend, like to have a consumer at the web application level to pass down the event to the frontend/UI via something like websockets. If you're using .NET that would be SignalR.
@jeyfus3 жыл бұрын
@Dr3w 97 I’m not sure Kafka is a good fit in this kind of interaction. It is internal to the system and should stay abstracted IMHO . A Websocket or even a long pulling based implementation would be a better fit
@vadimprudnikov90723 жыл бұрын
Very nice video, thanks! :) Maybe it's worth saying some terms like "circuit breaker" so people will search for it...
@CodeOpinion3 жыл бұрын
I mention circuit breakers, retries, fallbacks, etc. in this video when talking about fault tolerance kzbin.info/www/bejne/iZbWdox-fM2fgrM
@miyazakizachary51083 жыл бұрын
Love your presentation. I wonder do you have any idea to create a video talking about service bus vs message queue. What decision we should make on this choice. Hopefully, you could consider my proposal. Thanks.
@CodeOpinion3 жыл бұрын
Funny enough I was thinking of this yesterday. I'll be adding to my list of future topics.
@vishnuvardhanreddy2203 жыл бұрын
+1
@srik7903 жыл бұрын
Great video again... Thanks.. Waiting for your video how to handle task based UI/UX to create new product and it's SKU...
@CodeOpinion3 жыл бұрын
It's in the list of videos to tackle!
@KunalMukherjee37013 жыл бұрын
These videos are gold, keep em coming
@CodeOpinion3 жыл бұрын
Glad you like them!
@fallonmassey47143 жыл бұрын
Have you looked at Dapr? The issues with http/grpc communication still exists, but if you know what you're doing, it shouldn't be a problem. Dapr has messaging that allows you to switch out many different brokers(Redis, RabbitMQ, etc) without any loss of generality.
@CodeOpinion3 жыл бұрын
Thanks for the comment. Ya, I'm looking to cover it sooner rather than later. Are you using it?
@fallonmassey47143 жыл бұрын
@@CodeOpinion Yes! After a rocky start, I've dropped my event bus built around .net core and RabbitMQ in favor of Darp's implementation, and have a sidecar for each of my services. I almost dropped it when initial explanations were not so clear, but I kept coming back and the documentation got a lot better.
@jamesalcaraz87292 жыл бұрын
Good stuff as always. On the case of async messaging, how do you satisfy the requirement of the consumer where the nature of the request is synchronuous. Example the UI needs a response the represents multiple details from different services. Not everything is a fire and forget so in those cases what strategy to use to build out the requirement?
@CodeOpinion2 жыл бұрын
If the nature of the request is synchronous, make it synchronous. You don't need to fight it or force asynchronous messaging where it doesn't need to be. Check out this video where I talk about RPC vs Messaging: kzbin.info/www/bejne/gn6uh62dqs15rZY
@hrtummala2 жыл бұрын
We can still work through Asynchronous messaging with combination of server sent events to UI to mimic synchronous api calls. But yeah it's adding complexity to your already complex stack 🙂. State management on UI should clearly have a error boundary when you make best effort for response but if it is not ever coming via server event then what's the fall back option.
@sfcommand2 жыл бұрын
It would be a more solid opinion if you used the same failure modes for both rest and messaging examples...
@CodeOpinion2 жыл бұрын
Elaborate by what you mean "failure modes"?
@sfcommand2 жыл бұрын
@@CodeOpinion your examples such as "what happens when x service is slow, y service is slow", etc. Showing messaging succeeding with the exact same cases you used for sync ws calls seems like it builds a more solid foundation for ya.
@CodeOpinion2 жыл бұрын
@@sfcommand I cover that in other videos, specifically talking about handling failures in a message driven architecture: kzbin.info/www/bejne/iZbWdox-fM2fgrM
@krumbergify3 жыл бұрын
Thanks for a great video with clear explanations!
@krystian58583 жыл бұрын
Nice vid, as always, thanks!
@CodeOpinion3 жыл бұрын
Thanks for watching!
@ismile473 жыл бұрын
What are disadvantages of messge borker communications , I pushed an event and wating for other event which I was expecting response if there delay or failure of pull those response or track th on failure? Please suggest this video is really help full
@CodeOpinion3 жыл бұрын
Disadvantages of asynchronous messaging are just how it's a different mindset then synchronous request/response. Modelling things is different. Observability is key because otherwise debugging can be much more difficult.
@ChanceMinus Жыл бұрын
Fantastic video. Thank you.
@CodeOpinion Жыл бұрын
Glad you enjoyed it!
@ericomfg3 жыл бұрын
I'm struggling with this example because it seems like such a good fit for a monolith! Maybe I'm biased, microservices add so much complexity for little benefit until your organization is gigantic..
@CodeOpinion3 жыл бұрын
I agree that org structure matters and plays a role. I've created a few videos around what I call a loosely coupled monolith and also posted a video about starting with it. Check it out kzbin.info/www/bejne/kJDTm2Sjiql-mtk
@timhosking3 жыл бұрын
It’s not a monolith. He has given a very poor example of a micro service and has fallen into the trap of designing the micro service to follow entities in the database, which is surprising given he has other videos where he talks about separating resources from the data model. Your natural reaction here @eric is correct. It’s a micro service. Don’t make the technology fight the business. Purchasing, inventory, warehouse, etc are all part of a proper business transaction. If you find yourself writing “sagas” you’ve made the services too micro. Make them match the business use case.
@CodeOpinion3 жыл бұрын
@@timhosking As a bunch of my other videos have pointed out, focus on capabilities, not entities. A "product" entity can live in multiple services/boundaries and which has different capabilities. The capabilities are what define the service. Purchasing, Inventory/Warehouse, Sales all have different capabilities of a product. The cost owned by purchasing has absolutely nothing to do with sales. POs have nothing to do with Sales. Stock Count/Inventory Adjustments in a warehouse have nothing to do with Purchasing. But they are all related a the concept of a product. Almost all domain's I've worked in, there is a life cycle. Eg, from the moment and order is placed, to the moment it hits AR and the work hits AP. If you match that as a business case, you'll create a monolith. Which maybe totally fine depending on the goals of the system. If you create services, you're likely going to create a workflow either with event choreography or orchestration to handle that long running process (saga or process manager, depending on the term you live by).
@s0psAA3 жыл бұрын
Has anyone even done two phase commits on rest api? Doest it go against the stateless nature of it?
@CodeOpinion3 жыл бұрын
Check out this video I've done about Event Choreography & Orchestration kzbin.info/www/bejne/qICcc4upoZl0g7M
@daretsuki69883 жыл бұрын
This is amazing. Currently I'm trying to write a game as a distributed system. I'm gonna check other videos as well!
@CodeOpinion3 жыл бұрын
Thanks. I've never been much for writing games. Totally out of my area of knowledge, but hopefully the videos help in some way.
@derrick35342 жыл бұрын
Love the explanation. I have a question. You make a good case for not using REST for a distributed system however, how do u deal with validation of form in put when using an asynchronous approach. For example, let's say a user wants to change his email but the backend needs to verify that that new e.ail doesnt already exists. If that new email does exist and u are using asynchronous REST or messaging queue, how does that work out?
@CodeOpinion2 жыл бұрын
Some requests will naturally be sync request/response, as an example most requests from a UI. As your example, that call from the UI to the server is synchronous and that makes sense. Is placing an Order need to be fully synchronous? No. The request from the UI to the server is synchronous. But the server could enqueue a message to create the order and then immediately tell the UI/Client, "Thanks we've got your order and we'll let you know when it's processed". The order creation, payment processing, etc, can all be done asynchronously not blocking the UI/Client.
@derrick35342 жыл бұрын
@@CodeOpinion thanks I was thinking the same thing
@phanuwatwattanapraya79982 жыл бұрын
This really very useful video, thank you so much
@CodeOpinion2 жыл бұрын
Glad it was helpful!
@LawZist2 жыл бұрын
Hi Derek, From your professional opinion - what is the time duration you think a request should be made async instead of sync?
@CodeOpinion2 жыл бұрын
I don't really know if the duration is the key factor. To me it would be more about does it need to be blocking? Meaning if a user is placing an order, does it really need to block the client because it needs to save the order, process the credit card, confirm with the warehouse all the items are in stock? No. That can all be orchestrated asynchronously. The benefit with moving to async is removing the temporal aspect where all services needed to be available and online for the process to complete.
@LawZist2 жыл бұрын
@@CodeOpinion Thanks for the reply!
@hectorluisbarrientosmargol9303 Жыл бұрын
As I'm watching this video I can't get CAP theorem out of my mind
@CodeOpinion Жыл бұрын
I did a video about it related to microservices. A distributed system in relation to CAP is different than large system that's decomposed into a set of distributed services. kzbin.info/www/bejne/hpirfqeDorihb9U
@FecayDuncan3 жыл бұрын
I would use a process engine and implement a Saga pattern.
@CodeOpinion3 жыл бұрын
In the portion of the video I mentioned messaging and gave an example of event choreography. I have a separate video on event choreography and orchestration here for those interested. kzbin.info/www/bejne/qICcc4upoZl0g7M
@FecayDuncan3 жыл бұрын
@@CodeOpinion thanks, good one!
@twiksify Жыл бұрын
Great content, however consider mirroring the video of the face cam. Your sweatshirt is a giveaway, the logo reads "hsamedoc" instead of "codemash".
@CodeOpinion Жыл бұрын
I have it set this way so that when I look at my monitor, I'm looking in the same direction as the code. I often don't wear lettering anymore because I get this comment.
@TheSurroundification3 жыл бұрын
I'd like to see a video about application interface architecture with middlewares between and based on REST most likely. Im finding myself in a lot of project lately where i have to build interfaces between two seperate systems via webservices (for example synchronizing integrations). Most systems have their own middleware and handling events and processes on both sides is kinda tricky, in most cases the other system is handled by other people. Is there some kind of best practice for building solid process oriented interfaces? I know it depends on the case but maybe you have some good ideas and best practices. Thanks
@CodeOpinion3 жыл бұрын
I'm not entirely sure what you mean. Do you have a specific example that you can explain? Basically you have a service that's delegating between other services via HTTP? Is it for workflow?
@TheSurroundification3 жыл бұрын
@@CodeOpinion Specific example would be an Interface for Incident Management Workflow/Process in two tools, customer and external supplier system. Synchronising status changes and updates event driven. Might be too specific for a video but im looking more for a high level abstraction how to build an event driven solution where the two systems are both responsible for their own internal workflows but interact with eachother. I hope this is alittle bit more clear? Thanks
@CodeOpinion3 жыл бұрын
It is now, thanks for explanation. I'll put the idea in my list. Trying to think of exactly what the topic of that is. Do you control those other systems or no?
@TheSurroundification3 жыл бұрын
@@CodeOpinion in most cases the updates or status changes are informative. Since workflows and processes in the other system might be different to the sender system, the actions are interpreted and handled by the other systems middleware or logic and then transformed into actions based on their business workflow. While writing all this, i see that this is very dependend on each case since every system is different. Thank you for the effort :D
@evilroxxx3 жыл бұрын
@TheSurroundification you might wanna look into webhooks for something like that.
@Crozz223 жыл бұрын
How would you deal with the warehouse running out of items but there are still unprocessed orders in the queue? The user would have got an order received confirmation already, right?
@CodeOpinion3 жыл бұрын
Take a look at my video on long running processes with Event Choreography & Orchestration. It's about having compensating transactions. Let me know if this helps, otherwise I'll create more content around it. kzbin.info/www/bejne/qICcc4upoZl0g7M
@Crozz223 жыл бұрын
@@CodeOpinion Thanks, that made sense. I might have changed up the order a little bit and waited for the warehouse to reserve the item before billing, but the principle would seem to be the same.
@aadams993 жыл бұрын
What if the services are not in the same data center (it will be difficult to use a messaging bus like RabbitMQ)? What about setting longer timeouts? What about placing a messaing broker behind a web api (or inside a web api layer) with the api acting as the orchestrator but still using res/res for serv to serv coms but the broker as state/persistance? If there's a timeout have the broker retry the service or a second using req/res? Basically what we need stateless req/res for service-to-service communication and a persitance store for keeping track of calls.
@CodeOpinion3 жыл бұрын
Depends the broker. Something like AWS SNS can push to an HTTPS endpoints and AWS SQS supports VPC endpoints.
@timhosking3 жыл бұрын
If you have a business transaction that has to put messages on a stack rather than implementing a software transaction to support then I think you have drawn the boundaries around your micro services incorrectly.
@CodeOpinion3 жыл бұрын
While I agree that it's often likely boundaries are wrong, that's not the case all the time anytime you need to use messaging. I often use messaging within the same boundary to improve scalability. Also if you're integrating with an external system that you don't control (or from a different team) it can increasing reliability of your own service. Having said all that, they aren't the answer to all problems and in a many cases, you're likely better with a single schema and atomic transactions then creating a distributed system.
@HelloThere-xs8ss3 жыл бұрын
Why not just sockets?
@CodeOpinion3 жыл бұрын
Web Sockets or network (tcp)? Same situation as HTTP, if the service is down and or is degraded and cannot respond to your request, then you have to queue up those requests locally and retry them. Alternative is a message broker to handle that for you.
@HelloThere-xs8ss3 жыл бұрын
@@CodeOpinion I was thinking of tcp. maybe theres no way around this kind of issue?
@GCoda3 жыл бұрын
cap`n proto WTF
@CodeOpinion3 жыл бұрын
It's still RPC
@scdecade3 жыл бұрын
As soon as you say "each service has its own database" you caused yourself all the problems. Modern SQL databases are easily capable of handling multiple services.
@CodeOpinion3 жыл бұрын
Sure a database could likely scale to handle the required load. Or it can't. Or storage requirements are not the same across all services. Or you don't want to be coupled by schema. Or you have teams per service and they can't deploy independently because you're coupled by schema and may break other services with a schema changes. Or the list goes on. Or none of the above is an issue and you can use a shared schema. As usual, context matters.