Skip to main content
Question Protected by gnat
Tweeted twitter.com/StackSoftEng/status/908457136593752064
Included a reference to an existing question from Stack Overflow
Source Link
A.Rashad
  • 604
  • 4
  • 19

Disclaimer

I hope I am not stepping on anyone's toes or offending either concepts' enthusiasts

Background

I have been looking for real differences between Service Oriented Architecture and Microservices, without finding any clear answer.

I read things like:

  • the side effects of SOA
  • SOA being anti-pattern
  • Microservices came to fix SOA's failures
  • ESBs are not really ESBs instead they are EAIs
  • Over-reliance on Message Brokers
  • Vendors are abusing the notion of SOA and trying to sell their products
  • SOA grows uncontrollably

But still, nothing clearly defines architectural differences between Service Oriented Architecture (as a concept) and Microservices (as a concept)

According to what I understood, they both have:

  • Service Providers, doing only one thing
  • Service Gateway/ESB exposing those services to consumers
  • Service Consumers, accessing services via ESB/Service Gateway

Question

So, is there anything different other than relabeling SOA into Microservices? is it a technology constraint placed to limit Microservices from becoming macro?

Note: I am not looking for opinions, only hard facts, hopefully in bullet points

References

Update

It seems that a similar debate happened in a Stack overflow question, with opinions divided wether or not Microservices are Service Oriented Architecture in disguise.

Conclusion from the SO question:

  • MS is a special case of SOA
  • MS endorse smaller size of applications hosting services
  • MS is technology dependent (the use of HTTP rather than open protocol options)
  • MS relies on technology to enforce discipline (automatic deployment of services)
  • MS Considers ESBs (evil), but uses API Gateways which IMHO is a type of ESB

That concludes that MS is SOA, if the following is true:

  • Do MS support the notion of Orchestration? One or more master process(es) manage workflows
  • Is there a message broker layer in MS? A set of adapters translating message formats from the message space of the service producers to the service consumers
  • Can microservices read data from monolithic enterprise applications? Can it be APIs of a monolithic application? or it has to be standalone self contained applications, capable of operating independently?

If the answer to last question turned out to be no, then Microservices would not be capable of handling complex workflow systems, e.g. Credit Card Management Systems, or reconciliation systems

Disclaimer

I hope I am not stepping on anyone's toes or offending either concepts' enthusiasts

Background

I have been looking for real differences between Service Oriented Architecture and Microservices, without finding any clear answer.

I read things like:

  • the side effects of SOA
  • SOA being anti-pattern
  • Microservices came to fix SOA's failures
  • ESBs are not really ESBs instead they are EAIs
  • Over-reliance on Message Brokers
  • Vendors are abusing the notion of SOA and trying to sell their products
  • SOA grows uncontrollably

But still, nothing clearly defines architectural differences between Service Oriented Architecture (as a concept) and Microservices (as a concept)

According to what I understood, they both have:

  • Service Providers, doing only one thing
  • Service Gateway/ESB exposing those services to consumers
  • Service Consumers, accessing services via ESB/Service Gateway

Question

So, is there anything different other than relabeling SOA into Microservices? is it a technology constraint placed to limit Microservices from becoming macro?

Note: I am not looking for opinions, only hard facts, hopefully in bullet points

References

Disclaimer

I hope I am not stepping on anyone's toes or offending either concepts' enthusiasts

Background

I have been looking for real differences between Service Oriented Architecture and Microservices, without finding any clear answer.

I read things like:

  • the side effects of SOA
  • SOA being anti-pattern
  • Microservices came to fix SOA's failures
  • ESBs are not really ESBs instead they are EAIs
  • Over-reliance on Message Brokers
  • Vendors are abusing the notion of SOA and trying to sell their products
  • SOA grows uncontrollably

But still, nothing clearly defines architectural differences between Service Oriented Architecture (as a concept) and Microservices (as a concept)

According to what I understood, they both have:

  • Service Providers, doing only one thing
  • Service Gateway/ESB exposing those services to consumers
  • Service Consumers, accessing services via ESB/Service Gateway

Question

So, is there anything different other than relabeling SOA into Microservices? is it a technology constraint placed to limit Microservices from becoming macro?

Note: I am not looking for opinions, only hard facts, hopefully in bullet points

References

Update

It seems that a similar debate happened in a Stack overflow question, with opinions divided wether or not Microservices are Service Oriented Architecture in disguise.

Conclusion from the SO question:

  • MS is a special case of SOA
  • MS endorse smaller size of applications hosting services
  • MS is technology dependent (the use of HTTP rather than open protocol options)
  • MS relies on technology to enforce discipline (automatic deployment of services)
  • MS Considers ESBs (evil), but uses API Gateways which IMHO is a type of ESB

That concludes that MS is SOA, if the following is true:

  • Do MS support the notion of Orchestration? One or more master process(es) manage workflows
  • Is there a message broker layer in MS? A set of adapters translating message formats from the message space of the service producers to the service consumers
  • Can microservices read data from monolithic enterprise applications? Can it be APIs of a monolithic application? or it has to be standalone self contained applications, capable of operating independently?

If the answer to last question turned out to be no, then Microservices would not be capable of handling complex workflow systems, e.g. Credit Card Management Systems, or reconciliation systems

Source Link
A.Rashad
  • 604
  • 4
  • 19

What is really different between SOA and Microservices

Disclaimer

I hope I am not stepping on anyone's toes or offending either concepts' enthusiasts

Background

I have been looking for real differences between Service Oriented Architecture and Microservices, without finding any clear answer.

I read things like:

  • the side effects of SOA
  • SOA being anti-pattern
  • Microservices came to fix SOA's failures
  • ESBs are not really ESBs instead they are EAIs
  • Over-reliance on Message Brokers
  • Vendors are abusing the notion of SOA and trying to sell their products
  • SOA grows uncontrollably

But still, nothing clearly defines architectural differences between Service Oriented Architecture (as a concept) and Microservices (as a concept)

According to what I understood, they both have:

  • Service Providers, doing only one thing
  • Service Gateway/ESB exposing those services to consumers
  • Service Consumers, accessing services via ESB/Service Gateway

Question

So, is there anything different other than relabeling SOA into Microservices? is it a technology constraint placed to limit Microservices from becoming macro?

Note: I am not looking for opinions, only hard facts, hopefully in bullet points

References