Timeline for When bounded contexts and "microservices" collide. A distributed systems dilemma in diagram form
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 3, 2020 at 11:39 | comment | added | user3347715 | @allmhuran Well I think you understand the problem. The CAP theorem informs us that, given P, we must choose to forego either C or A when the network goes down. So either we choose to give up A (options 1,2,3) or C (options 4,5) — Of course there is the unlisted option of giving up P and putting Ordering and the CRM on the same box (like right half of option 4). The choice depends on the goals. It’s usually much less of a headache to give up availability than consistency, but not every system can tolerate that. In my experience the “micro-service” paradigm is more suited for the former. | |
| Jul 3, 2020 at 4:43 | comment | added | allmhuran | Now, there will of course be some architectures that prioritize C over A. P is of course a given if we are building multiple different applications. But if you try to prioritize C, you are building a distributed monolith. As long as that's a conscious decision, OK, fair enough. But the one thread of advice that seems to exist across all expert sources is "don't do this". | |
| Jul 3, 2020 at 4:41 | comment | added | allmhuran | No. To be clear, I'm not trying to design a particular architecture to meet a particular need for my particular job here. I mean, yes, I do this as well, but that's not the subject I'm trying to open up for discussion. What I'm trying to point out is that the advice that exists in the field of distributed systems is somewhat incoherent. Sure, there will always be compromises. In the OP I wrote "The big question is "what do you want to achieve?". Well, let's settle on things everyone seems to agree on with distributed systems: Given CAP, we are very interested in A and P, not so much C" | |
| Jul 3, 2020 at 4:17 | comment | added | user3347715 | @allmhuran Is this architecture specifically being designed to minimize availability coupling over all other forms? I don't find availability coupling a particularly important or interesting metric in terms of a micro-service architecture. Of course you are opening yourself up to availability concerns when you put every service on it's own box! If you can't tolerate this kind of exposure, well, don't choose micro-services. A well-designed, modular monolith would fit the bill here. I fear your question is approaching, "How can I get the benefits of micro-services with none of the drawbacks?" | |
| Jul 3, 2020 at 3:37 | comment | added | allmhuran | Also, your suggestion to create "one UI" has ignored the point that some of these systems might be vendor systems. I even put in an explicit warning that not every business is developing all of their own software. Are you going to pay thousands of dollars licensing for a "best of breed" or "best fit" vendor system, and then throw away the UI and rebuild it yourself? No, nobody does that. | |
| Jul 3, 2020 at 3:35 | comment | added | allmhuran | The loosest availability coupling is the ones where systems publish or subscribe to messages. This is why in the image headings for the first 3 options I wrote "no availability decoupling", but I did not write "no availability decoupling" for options 4 to 6. | |
| Jul 3, 2020 at 3:15 | comment | added | user3347715 | @allmhuran I must have misunderstood your statement about the loosest coupling being the ones where messages are shared. | |
| Jul 2, 2020 at 21:52 | comment | added | allmhuran | I don't view "coupling" in simple terms as "lines of communication" either. That's why I specifically qualified it as "availability coupling". As I said in the opening, there can also be temporal, logical, and other forms of dependencies. You'll note I didn't mention any of the advantages of any of the options, except when stating my preference. Because the point was to show that none of the options, except perhaps the last, adhere to all of the principles to which we would like to adhere. | |
| Jul 2, 2020 at 16:57 | comment | added | user3347715 | @allmhuran It's also possible that I am taking a wider view of what constitutes "coupling" than what is used above. I don't view "coupling" in simple terms like "lines of communication". For example, to my mind, Option 2 is more coupled than Option 1, Options 3,4,5 are an absolute disaster waiting to happen, and Option 6 is the least coupled in terms of our domains (not in absolute terms) but doesn't fulfill the use-case. | |
| Jul 2, 2020 at 15:05 | comment | added | user3347715 | @allmhuran The only options you included above where the CRM simply pushes messages onto a queue also include tight coupling to the ordering logic (either via maintaining a copy to the package or by duplicating domain logic). This means changing the Ordering domain necessarily requires changes to the CRM domain. There are very tightly coupled systems regardless of how messages are orchestrated. And a message queue presents similar points of failure as direct communication. Now the CRM ordering functionality could stop working even if Ordering domain is working! (we've added coupling to a MQ) | |
| Jul 2, 2020 at 1:15 | comment | added | allmhuran | The loosest coupling of the options presented are the 3 where messages are shared between the systems. The first three all involve a direct call from one system to the other, rather than communicating through messaging. I can absolutely have other systems taking orders when the actual order processing system is down, because the other systems are simply queuing up messages. When the order system comes up, it can ingest those queued messages. The "one UI" idea is a good one if you write all of your own software, but remember, CRM might be a big vendor system, like dynamics or something. | |
| Jul 1, 2020 at 20:14 | history | answered | user3347715 | CC BY-SA 4.0 |