4 ms·

SOA is just Spaghetti Architecture. I haven't seen an implementation that convinces me otherwise.

by soperj 4y ago

duxup 4y ago
I feel like it has its place in large organization. But being a large organization means the odds of spaghetti are approaching 100% no matter what you do.
jedberg 4y ago
What is your definition of Spaghetti Architecture? Netflix had a good SOA that enabled rapid development and had strong cut lines between services, with no way to access the data of a service without going through the service's API. I think that's where most people go wrong. They put a bunch of services in front of a shared database, which means that they don't have to go through a service's API to get to it's data, and that's what breaks everything.
- eropple 4y ago
  This is really important, and I've gotten a lot of quizzical looks when making this assertion over the years: data is owned by one and only one service. If two pieces of code assert ownership of it by mutating that data or looking past the public encapsulation of that data, then that code is the same service. If you see a queue between two services, that is usually an indication that some ownership is being transferred (even briefly), and that is a critical point where you need introspection and observation.
  - lamontcg 4y ago
    Yeah, services should be formed around the needs of data, and you shouldn't run multiple services in the same image/container just to split the code up. It shouldn't ever be about the code. Amazon's SOA architecture at least all started out about pulling bits of data spread over hundreds of servers into services that could take advantage of caching.
  - wikibob 4y ago
    > Data sovereignty per microservice > An important rule for microservices architecture is that each microservice must own its domain data and logic . Just as a full application owns its logic and data, so must each microservice own its logic and data under an autonomous lifecycle, with independent deployment per microservice. https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/data-sovereignty-per-microservice https://learn.microsoft.com/en-us/dotnet/architecture/micros...
    - JamesBarney 4y ago
      The big issue I've seen is that takes a lot of work, so people cut corners. The problem is of course when you cut corners with microservices and rely on a shared database for instance, suddenly you're dealing with 40% of the costs of a microservices and 0% of the benefits.
      - GauntletWizard 4y ago
        Shared database can be a reasonable microservice boundary, especially when using database-as-queue or database-as-mucroservice. In the former, services a, b and c can insert and query but only D can update, i.e. any service can creat a work-order but only D can mark it completed. I. The latter, nobody can read or write and all access to tables is done through stored procedures. I don't recommend either, and it's still a code smell, but with clear definitions they can work.
        JamesBarney 4y ago
        The benefits of the microservice pattern are you can build separate teams responsible for different business logic, and they can have their own deployment schedule. You don't get either of those benefits when a b and c have to coordinate on their work-order creation business logic, and a, b, c and d all need to be deployed at the same time anytime the schema changes. Btw some of the confusion might be what I mean by shared database. I didn't mean two services sharing a limited set of tables, using the database as a rabbitmq replacement. I meant sharing the backing database of the microservices. It sounds like we probably agree I just wasn't very clear about what I meant by sharing a database. (Ironically I am literally using a database as a queue to share data between two services we are running in prod. I don't think of it as a microservice because it's not separate teams, it just because our monolith is hosted on a platform that doesn't support certain libraries so we had to role those libraries onto a separate platform that does support them.)
  - maxrev17 4y ago
    This is it exactly!
- throwdbaaway 4y ago
  I have seen the "data service" design pattern that tries to work around this, by having a CRUD microservice to front a database, providing hundreds of APIs to read/write the data for 50 other microservices. If one of these CRUD microservices goes down, everything breaks.
Kinrany 4y ago
Any general purpose architecture allows spaghetti, there's no way around it.
- usrusr 4y ago
  Has there been an architecture movement that formally embraces the spaghetti, aiming for peaceful coexistence? Detractors will certainly point at SOA and shout "that one!", but I mean one that openly admits..
  - Spivak 4y ago
    I’m not sure if this architecture has a name other than “Event Sourcing” but I think giant org wide shared message bus with all services freely pushing and pulling data from it is the closest to embracing spaghetti.
rileyphone 4y ago
Microservices should be resource-oriented, not service-oriented. NetKernel takes it to the extreme, it’s a shame it hasn’t seen broader adoption. http://resources.1060research.com/docs/IntroductionToResourceOrientedComputing-1.pdf http://resources.1060research.com/docs/IntroductionToResourc...

SOA is just Spaghetti Architecture. I haven't seen an implementation that convinces me otherwise.

by soperj 4y ago

SOA is just Spaghetti Architecture. I haven't seen an implementation that convinces me otherwise.

I feel like it has its place in large organization. But being a large organization means the odds of spaghetti are approaching 100% no matter what you do.

jedberg 4y ago

What is your definition of Spaghetti Architecture? Netflix had a good SOA that enabled rapid development and had strong cut lines between services, with no way to access the data of a service without going through the service's API. I think that's where most people go wrong. They put a bunch of services in front of a shared database, which means that they don't have to go through a service's API to get to it's data, and that's what breaks everything.

eropple 4y ago
This is really important, and I've gotten a lot of quizzical looks when making this assertion over the years: data is owned by one and only one service. If two pieces of code assert ownership of it by mutating that data or looking past the public encapsulation of that data, then that code is the same service. If you see a queue between two services, that is usually an indication that some ownership is being transferred (even briefly), and that is a critical point where you need introspection and observation.
- lamontcg 4y ago
  Yeah, services should be formed around the needs of data, and you shouldn't run multiple services in the same image/container just to split the code up. It shouldn't ever be about the code. Amazon's SOA architecture at least all started out about pulling bits of data spread over hundreds of servers into services that could take advantage of caching.
- wikibob 4y ago
  > Data sovereignty per microservice > An important rule for microservices architecture is that each microservice must own its domain data and logic . Just as a full application owns its logic and data, so must each microservice own its logic and data under an autonomous lifecycle, with independent deployment per microservice. https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/data-sovereignty-per-microservice https://learn.microsoft.com/en-us/dotnet/architecture/micros...
  - JamesBarney 4y ago
    The big issue I've seen is that takes a lot of work, so people cut corners. The problem is of course when you cut corners with microservices and rely on a shared database for instance, suddenly you're dealing with 40% of the costs of a microservices and 0% of the benefits.
    - GauntletWizard 4y ago
      Shared database can be a reasonable microservice boundary, especially when using database-as-queue or database-as-mucroservice. In the former, services a, b and c can insert and query but only D can update, i.e. any service can creat a work-order but only D can mark it completed. I. The latter, nobody can read or write and all access to tables is done through stored procedures. I don't recommend either, and it's still a code smell, but with clear definitions they can work.
      - JamesBarney 4y ago
        The benefits of the microservice pattern are you can build separate teams responsible for different business logic, and they can have their own deployment schedule. You don't get either of those benefits when a b and c have to coordinate on their work-order creation business logic, and a, b, c and d all need to be deployed at the same time anytime the schema changes. Btw some of the confusion might be what I mean by shared database. I didn't mean two services sharing a limited set of tables, using the database as a rabbitmq replacement. I meant sharing the backing database of the microservices. It sounds like we probably agree I just wasn't very clear about what I meant by sharing a database. (Ironically I am literally using a database as a queue to share data between two services we are running in prod. I don't think of it as a microservice because it's not separate teams, it just because our monolith is hosted on a platform that doesn't support certain libraries so we had to role those libraries onto a separate platform that does support them.)
- maxrev17 4y ago
  This is it exactly!
throwdbaaway 4y ago
I have seen the "data service" design pattern that tries to work around this, by having a CRUD microservice to front a database, providing hundreds of APIs to read/write the data for 50 other microservices. If one of these CRUD microservices goes down, everything breaks.

Kinrany 4y ago

Any general purpose architecture allows spaghetti, there's no way around it.

usrusr 4y ago
Has there been an architecture movement that formally embraces the spaghetti, aiming for peaceful coexistence? Detractors will certainly point at SOA and shout "that one!", but I mean one that openly admits..
- Spivak 4y ago
  I’m not sure if this architecture has a name other than “Event Sourcing” but I think giant org wide shared message bus with all services freely pushing and pulling data from it is the closest to embracing spaghetti.

rileyphone 4y ago

Microservices should be resource-oriented, not service-oriented. NetKernel takes it to the extreme, it’s a shame it hasn’t seen broader adoption. http://resources.1060research.com/docs/IntroductionToResourceOrientedComputing-1.pdf http://resources.1060research.com/docs/IntroductionToResourc...