Would you say that this distinction between SOA and micro services is correct, which I found in an O'Reilly report [1]:
> One of the fundamental concepts to remember is that microservices architecture is a share-as-little-as-possible architecture pattern that places a heavy emphasis on the concept of a bounded context, whereas SOA is a share-as-much-as-possible architecture pattern that places heavy emphasis on abstraction and business functionality reuse. By understanding this fundamental concept—as well as the other characteristics, capabilities, and shortcomings of both micro‐ services and SOA that I discussed in this report—you can make a more informed decision about which architecture pattern is right for your situation.
Or is this a distinction you would not make (or were not even aware of)?
[1] Mark Richards - Microservices vs. Service-Oriented architecture
To be honest, I've never really thought of the architectures I work on as being divided along those lines. I think it may be a more important distinction for larger teams. In general I think in terms of separation of duties and authority; my preference is for loose coupling and lazy loading, separate data stores and applets for separate purposes, what might be called microservices; but referring to SOA I really just mean the sharding of different parts of the stack to independent services (several RDSs, S3 buckets, EC2 instances that run cron tasks to sync disparate data systems, beanstalks for some app frontends, etc). I guess some applications within that paradigm are more "micro" than others. Some have custom APIs and others are bound more tightly to central software functions. But perhaps I don't really understand what others are talking about when they stress this distinction.
> One of the fundamental concepts to remember is that microservices architecture is a share-as-little-as-possible architecture pattern that places a heavy emphasis on the concept of a bounded context, whereas SOA is a share-as-much-as-possible architecture pattern that places heavy emphasis on abstraction and business functionality reuse. By understanding this fundamental concept—as well as the other characteristics, capabilities, and shortcomings of both micro‐ services and SOA that I discussed in this report—you can make a more informed decision about which architecture pattern is right for your situation.
Or is this a distinction you would not make (or were not even aware of)?
[1] Mark Richards - Microservices vs. Service-Oriented architecture