The reason behind that question is ppl tend to use RPC style and calling other parts of application and think they designed a microservice , but in reality they made a glorified complex monolith with network calls
I feel like learned a lot about microservices from this single video. This has been the clearest and most concise explanation of what a microservice "looks like", if that makes sense 😊 I'm also learning a lot by reading the comments! Great discussions
Hi Derek, I think you have either the Ca & Ce swapped on the slide at 4:54, or maybe the arrows are reversed Efferent coupling as you mentioned is: Who do you depend on I think Catalog doesn't depend on anything in this example, but it shows Ce = 3
Quite an intriguing video. I would like to share my criticism. First, the C in CAP stands for strong consistency, where every successful read gets the most recent result. The eventually consistent result in the sales-billing-shipping example 9:42 means C is given up in CAP. Second, the sales-billing-shipping example is oversimplified in terms of decoupling: Say if the system requires to prevent overselling out-of-stock items, which calls for strong consistency, then availability must be sacrificed (by using a FIFO queue or distributed lock) since network partitioning between sales and warehouse services is inevitable.
Exactly. This is what I'm saying in the video. We're in agreement but not sure if that didn't come across in the video. I did another video about consistency here: ruclips.net/video/uKURpE12Mgo/видео.html
@@CodeOpinion In the data consistency video, by gathering transaction related data records into one service, P is sacrificed to keep CA. Which is another example of how CAP does apply to microservice architecture.
@@CodeOpinion Good discussion, but that's just another way to look at it. For your solution in the data consistency video, we have name and description in Catalog, price and ATP in Sales, quantity in Warehouse. If we're looking at all the data in the system (name, description, price, ATP, quantity), we have A and P (the system tolerates partition between services) but not C (name, description, quantity have only eventual consistency); On the other hand, if we're looking at data in Sales only, then we have C and A, but not P (communication within Sales is reliable since we are not considering inner-service CAP in the discussion). Either way, CAP holds. In the end, all the solutions we mentioned are essentially tradeoffs in CAP, whether we're aware of it or not.
@Goo Woo I appreciate the the comment, but I disagree. I think we'll just go round in round in comments! Also, I had a typo in the earlier comment which I fixed. It should of said: "You can't have a partition if no service communicates directly with another service."
The problem with eventual consistency is the reality that inevitable inconsistency will exist. The inconsistency allows faulty state based decisions to occur, thus creating a tangled web of undo scenarios to create your eventual consistency [or the real world state you can't get away from].
Very clarifying document to me. I had a misconception about MSs and CAP theorem. According to your explanation it's like MSs care about Availability and Consistency and no need to care about PT anymore cause of EDA's in the picture. So if "P" variable removes from equation then there's no point on taking care about CAP theorem. Thank u Derek
Yes. You don't have a system that's composed of all the same data (ATM example), you have a system that's decomposed and each service owns it's own portion of the data.
I think this question comes from the fact that many companies use http between microservices, to achieve consistency. Meaning they have sacrificed availability for consistency. In your example you have sacrificed consistency for availability (eventual consistency).
Yes, I can see how it could be viewed that way. I guess the difference for me is I don't view HTTP or RPC calls between service as even an option. Because it's not even an option, I'm not choosing one or the other, it's chosen for me. If you haven't already, check out this video on REST APIs (HTTP) between Microservices and all the problems it can cause: ruclips.net/video/_4gyR6CBkUE/видео.html
Could you comment on duplication caused by Order being present in all of Sales, Billing, Shipping, Warehouse microservices? Sure Order representation in each of microservices will be different and tailored for the particular microservice, but still there would be a lot of duplication. Isn't it violating the DRY principle? How about storage requirements for all this duplication, both in the sense of storage space as well as SAN bandwidth? How about duplication of cleanup procedures (i.e. each microservice has to clean up orders from the storage once it does not need it any more)? Somehow microservices architecture are closing to exponential complexity with increased microservice granularity. That is why microservices should really be miniservices, less granular than usually suggested. In the original DDD book, Bounded Context is the size of what one team (averaging 7 people) can manage. Now people think microservice should be the size of hundreds of lines of code and what can fit in the head of one developer at single point of time! Oh what a fallacy! Fighting monoliths with fine grained microservices is just jumping from one extreme to the other! The sweet spot is somewhere in between, the size of microservice should be from what can be covered from one developer to one team, not finer grained that that, there is no point in it, just adding unnecessary complexity and repetition!
Absolutely agree on what the size of microservices are. I generally think of them in the same way but it ultimately comes down to cohesion of the capabilities. Wherever that lands is where it lands. The idea of a ton of microservices that each only have a couple of HTTP routes all interconnected is crazy. As for the duplication, as you mentioned each service has its own concept of the Order. The data it owns relates to the capabilities it has. Shipping would obviously have shipping information of the order, but it doesn't at all have any billing information. It doesn't violate DRY because each services concerns are totally different. You aren't repeating the same concept in every service.
@@miletacekovic Yes. I understand that. But its more like a high level overview rather than a tutorial. I think the video title was explained very well. Some sort of guidance going into anything is very helpful.
CAP theorem is applicable to all services, irrespective of the architecture, even in an event driven world if one of the services doesn’t respond to a message due to network failure then the functionality won’t work as a whole even though services might be up & running.
In the example, two ATM machines are a single bounded context. They have the exact same functionality. They communicate between each other to keep data consistent between them. If you want to always be consistent about the state on all ATMs, then if you lose connection to another ATM then all the ATMs must be unavailable. If you choose availability, then if you lose connection to an ATM and they both are still operating, then you will lose consistency because they both won't have the same state. Both have implications. By definition, they aren't microservices because they are have the same functionality. Microservices are composed of services that have specific functionality/boundaries, own specific data, and are loosely coupled.
Ok, and how do I apply loosely coupled event based approach to a service when it’s purpose lets say to query data from other systems and based on the received data it has to decide whether a user is eligible for registrating into a service or not. How one achieve something like this with a message driven architecture. I believe this particular task has a synchronous nature.
Querying another service because you need the data for a business logic is the issue. Especially if you need consistency. Check out this video: ruclips.net/video/uKURpE12Mgo/видео.html
I feel like you are straw manning the argument. At least with the ATM CAP explanation. Those are two instances of the same service and the question is how to keep them in sync. If you have just one database it is simple way simpler, because ATMs would be connected to the same database. But if each instance has it's own database, how will you handle the sync between the services. At least that is what I understood from it. Another thing is the loose coupling you mentioned. It is not like coupling disappeared, what happened is that instead of going counter clock-wise it is going clock-wise (Sales is dependent on Warehouse, Billing is dependent on Sales, etc.). If Warehouse changes it's events the Sales will also have to change. The difference is, that with doing stuff synchronously you at least knew where the message went, now you have no idea who consumes the message, so it makes debugging even harder.
You understood the difference exactly. The ATMs are apart of the same service. Microservices are a individual services that have different responsibilities. As for loose coupling, it can be more difficult because of the decoupling. Good observability is key to understanding message flow. You can also use orchestration to centralize the logic. Check out this video on the topic. ruclips.net/video/rO9BXsl4AMQ/видео.html
First Microservices are not always EDA. Look it this way, Microservices are distributed systems and CAP theorem is a characteristic of Distributed System. Your Microservices are partition tolerant (consider BFF pattern) , Eventual Consistent ( Saga ) and always Available.
I'm wondering what would be the impact of this asynchronous/eventual consistent behavior to real-time applications. It sounds too good that we can build equally performant apps with event-driven microservices and at the same time avoid CAP. Is there any research about real-time apps and event-driven microservices that you are aware?
Well, microservices might not care about other microservices, and they shouldn't care. But we, as a business owner, do care that all of them are not only up individually, but are also available to communicate with each other (via message broker in event-driven architecture). After all, a distributed system is not only a collection of individual microservices living their own lives, it's a collective function of all of them. And network particion for us, business developers, is a real threat that we need to consider when designing them. So, while we might say that CAP theorem is academically not applicable, because microservices equals event-driven and fully autonomous, in a production reality it's not acceptable standpoint.
CAP theorem has to do with network communication and you still need to communicate events across a network through an event bus. You can't remove "partition intolerance" from the equation when dealing with distributed systems. The trade-off between consistency vs availability is nonexistent without partition intolerance and therefore it makes no sense to talk about why an event driven architecture would be desirable in the first place without the constraints of partition intolerance.
I created a somewhat related video talking about consistency and how it doesn't exist in a system that's decomposed into physical services: ruclips.net/video/uKURpE12Mgo/видео.html
I can't see why this approach should be better than gRPC/HTTP approach. In synchronous gRPC when one of the modules is down, this particular functionality is not working. In messaging approach when one of the modules is down, also particular functionality is not working. So where is the difference?
You lost me at just removing partition tolerance with the idea that EDA microservices would adjust. What about that shared layer (message broker, service bus) which is required in your system design? Although your micro services might not need strong consistency, your message broker does if the system is to be reliable - and a pod/network issue would create partitions in the cluster.
Your explanation is even better than IBM’s lecture on CAP theorem. Great job!
Glad you think so!
The reason behind that question is ppl tend to use RPC style and calling other parts of application and think they designed a microservice , but in reality they made a glorified complex monolith with network calls
I feel like learned a lot about microservices from this single video. This has been the clearest and most concise explanation of what a microservice "looks like", if that makes sense 😊
I'm also learning a lot by reading the comments! Great discussions
Great to hear!
Hi Derek, I think you have either the Ca & Ce swapped on the slide at 4:54, or maybe the arrows are reversed
Efferent coupling as you mentioned is: Who do you depend on
I think Catalog doesn't depend on anything in this example, but it shows Ce = 3
Ooops! Thanks for pointing that out.
Quite an intriguing video. I would like to share my criticism. First, the C in CAP stands for strong consistency, where every successful read gets the most recent result. The eventually consistent result in the sales-billing-shipping example 9:42 means C is given up in CAP. Second, the sales-billing-shipping example is oversimplified in terms of decoupling: Say if the system requires to prevent overselling out-of-stock items, which calls for strong consistency, then availability must be sacrificed (by using a FIFO queue or distributed lock) since network partitioning between sales and warehouse services is inevitable.
Exactly. This is what I'm saying in the video. We're in agreement but not sure if that didn't come across in the video. I did another video about consistency here: ruclips.net/video/uKURpE12Mgo/видео.html
@@CodeOpinion In the data consistency video, by gathering transaction related data records into one service, P is sacrificed to keep CA. Which is another example of how CAP does apply to microservice architecture.
@@goowoo2598 You can't have a partition if no service communicates directly with another service.
@@CodeOpinion Good discussion, but that's just another way to look at it. For your solution in the data consistency video, we have name and description in Catalog, price and ATP in Sales, quantity in Warehouse. If we're looking at all the data in the system (name, description, price, ATP, quantity), we have A and P (the system tolerates partition between services) but not C (name, description, quantity have only eventual consistency); On the other hand, if we're looking at data in Sales only, then we have C and A, but not P (communication within Sales is reliable since we are not considering inner-service CAP in the discussion). Either way, CAP holds. In the end, all the solutions we mentioned are essentially tradeoffs in CAP, whether we're aware of it or not.
@Goo Woo I appreciate the the comment, but I disagree. I think we'll just go round in round in comments! Also, I had a typo in the earlier comment which I fixed. It should of said: "You can't have a partition if no service communicates directly with another service."
The problem with eventual consistency is the reality that inevitable inconsistency will exist. The inconsistency allows faulty state based decisions to occur, thus creating a tangled web of undo scenarios to create your eventual consistency [or the real world state you can't get away from].
This was brilliant, I think udi dahan the creator of Nservicebus said, most people are developing a distributed monolith in the name of microservices
I'd agree. I'd say the majority of articles/blogs/videos about Microservices show communication happening via synchronous (temporal) RPC calls.
Very clarifying document to me. I had a misconception about MSs and CAP theorem. According to your explanation it's like MSs care about Availability and Consistency and no need to care about PT anymore cause of EDA's in the picture. So if "P" variable removes from equation then there's no point on taking care about CAP theorem. Thank u Derek
Yes. You don't have a system that's composed of all the same data (ATM example), you have a system that's decomposed and each service owns it's own portion of the data.
I think this question comes from the fact that many companies use http between microservices, to achieve consistency. Meaning they have sacrificed availability for consistency. In your example you have sacrificed consistency for availability (eventual consistency).
Yes, I can see how it could be viewed that way. I guess the difference for me is I don't view HTTP or RPC calls between service as even an option. Because it's not even an option, I'm not choosing one or the other, it's chosen for me. If you haven't already, check out this video on REST APIs (HTTP) between Microservices and all the problems it can cause: ruclips.net/video/_4gyR6CBkUE/видео.html
Could you comment on duplication caused by Order being present in all of Sales, Billing, Shipping, Warehouse microservices?
Sure Order representation in each of microservices will be different and tailored for the particular microservice, but still there would be a lot of duplication.
Isn't it violating the DRY principle?
How about storage requirements for all this duplication, both in the sense of storage space as well as SAN bandwidth?
How about duplication of cleanup procedures (i.e. each microservice has to clean up orders from the storage once it does not need it any more)?
Somehow microservices architecture are closing to exponential complexity with increased microservice granularity.
That is why microservices should really be miniservices, less granular than usually suggested.
In the original DDD book, Bounded Context is the size of what one team (averaging 7 people) can manage.
Now people think microservice should be the size of hundreds of lines of code and what can fit in the head of one developer at single point of time! Oh what a fallacy!
Fighting monoliths with fine grained microservices is just jumping from one extreme to the other!
The sweet spot is somewhere in between, the size of microservice should be from what can be covered from one developer to one team, not finer grained that that, there is no point in it, just adding unnecessary complexity and repetition!
Absolutely agree on what the size of microservices are. I generally think of them in the same way but it ultimately comes down to cohesion of the capabilities. Wherever that lands is where it lands. The idea of a ton of microservices that each only have a couple of HTTP routes all interconnected is crazy. As for the duplication, as you mentioned each service has its own concept of the Order. The data it owns relates to the capabilities it has. Shipping would obviously have shipping information of the order, but it doesn't at all have any billing information. It doesn't violate DRY because each services concerns are totally different. You aren't repeating the same concept in every service.
Informative video. Kept it simple but explained everything. 👌
Glad it was helpful!
Unfortunately, things are not that simple as presented in this video ;). Still en excellent video!
@@miletacekovic Yes. I understand that. But its more like a high level overview rather than a tutorial. I think the video title was explained very well. Some sort of guidance going into anything is very helpful.
CAP theorem is applicable to all services, irrespective of the architecture, even in an event driven world if one of the services doesn’t respond to a message due to network failure then the functionality won’t work as a whole even though services might be up & running.
I'm confused. So a system like this ATM can't be implemented using microservices by definition?
In the example, two ATM machines are a single bounded context. They have the exact same functionality. They communicate between each other to keep data consistent between them. If you want to always be consistent about the state on all ATMs, then if you lose connection to another ATM then all the ATMs must be unavailable. If you choose availability, then if you lose connection to an ATM and they both are still operating, then you will lose consistency because they both won't have the same state. Both have implications. By definition, they aren't microservices because they are have the same functionality. Microservices are composed of services that have specific functionality/boundaries, own specific data, and are loosely coupled.
@@CodeOpinion That makes sense. Thanks!
Well-thought and to the point. Thanks!
Ok, and how do I apply loosely coupled event based approach to a service when it’s purpose lets say to query data from other systems and based on the received data it has to decide whether a user is eligible for registrating into a service or not. How one achieve something like this with a message driven architecture. I believe this particular task has a synchronous nature.
Querying another service because you need the data for a business logic is the issue. Especially if you need consistency. Check out this video: ruclips.net/video/uKURpE12Mgo/видео.html
I feel like you are straw manning the argument. At least with the ATM CAP explanation. Those are two instances of the same service and the question is how to keep them in sync. If you have just one database it is simple way simpler, because ATMs would be connected to the same database. But if each instance has it's own database, how will you handle the sync between the services. At least that is what I understood from it.
Another thing is the loose coupling you mentioned. It is not like coupling disappeared, what happened is that instead of going counter clock-wise it is going clock-wise (Sales is dependent on Warehouse, Billing is dependent on Sales, etc.). If Warehouse changes it's events the Sales will also have to change. The difference is, that with doing stuff synchronously you at least knew where the message went, now you have no idea who consumes the message, so it makes debugging even harder.
You understood the difference exactly. The ATMs are apart of the same service. Microservices are a individual services that have different responsibilities.
As for loose coupling, it can be more difficult because of the decoupling. Good observability is key to understanding message flow. You can also use orchestration to centralize the logic. Check out this video on the topic. ruclips.net/video/rO9BXsl4AMQ/видео.html
First Microservices are not always EDA. Look it this way, Microservices are distributed systems and CAP theorem is a characteristic of Distributed System. Your Microservices are partition tolerant (consider BFF pattern) , Eventual Consistent ( Saga ) and always Available.
Agree to disagree.
I'm wondering what would be the impact of this asynchronous/eventual consistent behavior to real-time applications. It sounds too good that we can build equally performant apps with event-driven microservices and at the same time avoid CAP. Is there any research about real-time apps and event-driven microservices that you are aware?
Research, no. Have you checked out this video about real time web using events? ruclips.net/video/Tu1GEIhkIqU/видео.html
Intuitive..... Hey Derek, could you share cap theorem code level implementation git repo, if possible.
I'd have to create an example. I might do that for another video where I use UI composition which is request/response.
Thanks
Well, microservices might not care about other microservices, and they shouldn't care. But we, as a business owner, do care that all of them are not only up individually, but are also available to communicate with each other (via message broker in event-driven architecture). After all, a distributed system is not only a collection of individual microservices living their own lives, it's a collective function of all of them. And network particion for us, business developers, is a real threat that we need to consider when designing them. So, while we might say that CAP theorem is academically not applicable, because microservices equals event-driven and fully autonomous, in a production reality it's not acceptable standpoint.
CAP theorem has to do with network communication and you still need to communicate events across a network through an event bus. You can't remove "partition intolerance" from the equation when dealing with distributed systems. The trade-off between consistency vs availability is nonexistent without partition intolerance and therefore it makes no sense to talk about why an event driven architecture would be desirable in the first place without the constraints of partition intolerance.
I created a somewhat related video talking about consistency and how it doesn't exist in a system that's decomposed into physical services: ruclips.net/video/uKURpE12Mgo/видео.html
I can't see why this approach should be better than gRPC/HTTP approach. In synchronous gRPC when one of the modules is down, this particular functionality is not working. In messaging approach when one of the modules is down, also particular functionality is not working. So where is the difference?
I cover a the downsides to synchronous requests in this video: ruclips.net/video/_4gyR6CBkUE/видео.html
You lost me at just removing partition tolerance with the idea that EDA microservices would adjust. What about that shared layer (message broker, service bus) which is required in your system design? Although your micro services might not need strong consistency, your message broker does if the system is to be reliable - and a pod/network issue would create partitions in the cluster.
@CodeOpinion Can you take this topic next. ORLEANS
Ya I'll get it in at some point in the near future.
@@CodeOpinion awesome thanks.