5 ms·

I am not sure how you were confused by this: "In large Enterprises, you will inevitably be trying to get multiple services and databases to work together. The

I am not sure how you were confused by this: "In large Enterprises, you will inevitably be trying to get multiple services and databases to work together. The old style for dealing with this was the ESB (Enterprise Service Bus) or SOA (Service Oriented Architecture)" You write "SOA has nothing to do with ESB" yet both are attempts at "you will inevitably be trying to get multiple services and databases to work together" which was literally the sentence before the one you are reacting to. As to this: "SOA has nothing to do with ESB/distributed logs/event sourcing, and none of that has to do with MongoDB or document-stores" The point of my comment is that MongoDB is so flexible it can replace other approaches to the problem of "get multiple services and databases to work together" including ESB and SOA. At this point, I can not think of any reason to ever use an SQL database. Either your canonical data will be in Kafka, or it can go in MongoDB. There is no need for SQL databases, ever. About this: "MongoDB is not a good event-sourcing system" Obviously, which is why I included a link to the Jay Kreps essay. Kafka is better for an event-sourcing system. I'm not sure how you misread that part. About this: "The last part about treating a database as a cache has nothing to do with databases" It feels like you are almost deliberately trying to misread what I wrote. My whole point was that MongoDB is so flexible, it can work as a cache, and also as a store for canonical data (in those circumstances when you are not storing your canonical data in something like Kafka). Is that more clear?

manigandham 8y ago
A database is not comparable to SOA or ESB. They are 3 entirely separate concepts. They're not used to solve the same problems and they are not interchangeable. The only confusion is in thinking they are. > There is no need for SQL databases, ever. What? This is nonsensical and ideological. > MongoDB is so flexible, it can work as a cache That's meaningless because any database can be used as a cache, but caching is not as simple as storing some records in a collection. You seem to be caught up in some hype around Kafka, event-sourcing and MongoDB when this is a rather poor architecture choice for most applications. If you're going to say that relational databases are useless, you need some solid arguments instead of mixing up a bunch of buzzwords.
- lkrubner 8y ago
  About this: "A database is not comparable to SOA or ESB." It feels like you are deliberately misreading what I wrote. SOA and ESB and the unified log architecture that Jay Kreps wrote about are 3 different approaches to deal with the problem of "In large Enterprises, you will inevitably be trying to get multiple services and databases to work together." That may not be the only reason for SOA and ESB and unified logs, but multiple services with multiple databases is clearly a very large reason for the rise of these 3 different architectures. It is trivial to find articles in which "multiple services and databases" are mentioned as the impetus giving rise to each of these 3 architectures. Is that more clear?
  - manigandham 8y ago
    You're repeating the same thing. SOA is an architectural style where the entire business domain functions as independent components talking to each other. ESB is one type of communication between those components. A unified log is a way to persist those communications. A database is a data persistence system. None of these things replace anything else, they are all separate layers of solving a problem. They are not "3 different architectures" and can all be used at the same time even. Talking about a unified log and SOA to say that MongoDB is the best database for everything only shows a poor understanding of the underlying technical concepts.
    - lkrubner 8y ago
      You seem to be committed to disagreeing with me for the mere sake of disagreeing with me. About this: "and can all be used at the same time even" Obviously. I've worked at many companies that use multiple architectures. Nothing I said implied these were mutually exclusive. But you must be aware that a system needs to know what its canonical data is, or it will get into trouble? That is the caveat. I've seen multiple architectures in use at large companies, but this is typically seen as a red flag, and indeed, I'm often hired to help solve exactly that problem. About this: "SOA is an architectural style where the entire business domain functions as independent components talking to each other. ESB is one type of communication between those components. A unified log is a way to persist those communications. A database is a data persistence system." Finally, we agree about something. But you are simply describing what things are. Did you have some point you were trying to make? About this: "None of these things replace anything else, they are all separate layers of solving a problem." At large companies I'd expect to see different architectures presiding over different parts of a system, but if I arrive at the company and I'm told it is using SOA and ESB and a unified log and I ask the CTO "Which of these systems is responsible for maintaining the canonical version of your data?" and the CTO responds "All of them" then I know I'm dealing with a company that is in deep trouble.

manigandham 8y ago

A database is not comparable to SOA or ESB. They are 3 entirely separate concepts. They're not used to solve the same problems and they are not interchangeable. The only confusion is in thinking they are. > There is no need for SQL databases, ever. What? This is nonsensical and ideological. > MongoDB is so flexible, it can work as a cache That's meaningless because any database can be used as a cache, but caching is not as simple as storing some records in a collection. You seem to be caught up in some hype around Kafka, event-sourcing and MongoDB when this is a rather poor architecture choice for most applications. If you're going to say that relational databases are useless, you need some solid arguments instead of mixing up a bunch of buzzwords.

lkrubner 8y ago
About this: "A database is not comparable to SOA or ESB." It feels like you are deliberately misreading what I wrote. SOA and ESB and the unified log architecture that Jay Kreps wrote about are 3 different approaches to deal with the problem of "In large Enterprises, you will inevitably be trying to get multiple services and databases to work together." That may not be the only reason for SOA and ESB and unified logs, but multiple services with multiple databases is clearly a very large reason for the rise of these 3 different architectures. It is trivial to find articles in which "multiple services and databases" are mentioned as the impetus giving rise to each of these 3 architectures. Is that more clear?
- manigandham 8y ago
  You're repeating the same thing. SOA is an architectural style where the entire business domain functions as independent components talking to each other. ESB is one type of communication between those components. A unified log is a way to persist those communications. A database is a data persistence system. None of these things replace anything else, they are all separate layers of solving a problem. They are not "3 different architectures" and can all be used at the same time even. Talking about a unified log and SOA to say that MongoDB is the best database for everything only shows a poor understanding of the underlying technical concepts.
  - lkrubner 8y ago
    You seem to be committed to disagreeing with me for the mere sake of disagreeing with me. About this: "and can all be used at the same time even" Obviously. I've worked at many companies that use multiple architectures. Nothing I said implied these were mutually exclusive. But you must be aware that a system needs to know what its canonical data is, or it will get into trouble? That is the caveat. I've seen multiple architectures in use at large companies, but this is typically seen as a red flag, and indeed, I'm often hired to help solve exactly that problem. About this: "SOA is an architectural style where the entire business domain functions as independent components talking to each other. ESB is one type of communication between those components. A unified log is a way to persist those communications. A database is a data persistence system." Finally, we agree about something. But you are simply describing what things are. Did you have some point you were trying to make? About this: "None of these things replace anything else, they are all separate layers of solving a problem." At large companies I'd expect to see different architectures presiding over different parts of a system, but if I arrive at the company and I'm told it is using SOA and ESB and a unified log and I ask the CTO "Which of these systems is responsible for maintaining the canonical version of your data?" and the CTO responds "All of them" then I know I'm dealing with a company that is in deep trouble.