So, at the very outset let me state clearly that I see these models differently by virtue of my experience. So this post is my perspective on the difference between these two architectural patterns as I had experienced it.
- SOA is monolithic solution like a big lion in the jungle; how it works would be pretty evident for a pair of eyes.
MSA is distributed system constituting a set of services working together as one, like a pack of wild dogs working together to attack its target; how it works together would seem like a magic for a pair of eyes. - SOA is layered. The app is broken into independent functional modules owned by respective teams. In the Java EE world, each team owning the module builds and publishes its artifacts as libraries for consumption by the core app. The application thus remains monolithic, so any changes to a module meant building and deploying the entire application. This also means that the release of functional modules needs to be coordinated with that of the main application. At least that is how the teams I had been in had build the big monolithic enterprise application, the SOA way.
MSA is about breaking the large monolithic app into independently deploy-able application where the teams owning it can have its own release cadence; although the larger release of the application still requires some bit of coordinated efforts. - SOA standardizes on shared release cadence requiring larger project planning to keep teams occupied and syncing efforts across teams.
MSA liberates teams to have its own release cadence to meet the needs of the larger release cycle of the application. - SOA is externally focussed. It was intended to solving communication gaps with 3rd-party heterogeneous systems in a safe, secure and vendor neutral way. More often than not, the communication was outside of the trusted networks.
MSA is internally focussed. It lays emphasis on building small and independently deployable applications that work together, for faster development and deployment of business needs. The inter-app communication challenge was a consequence of this decision. Typically, the coordinating apps are within the trusted network of the company. - Refactoring across bounded context is relatively simpler with SOA.
Refactoring across bounded context is harder with MSA. This is one of the key reasons I don't recommend Microservices First Architecture, but yeah, you can always hit a middle ground that is there somewhere. - SOA embraced SOAP as the de-facto communication protocol and later went on to support REST protocol too.
MSA embraced REST as the de-facto communication protocol, but is pretty open to embracing other newer protocols for good. Inherently though, there is a dislike for SOAP/XML within the MSA community :) - SOA solved the integration challenges for businesses primarily in the B2B space.
MSA solved the delivery challenges for businesses that wanted to be nimble with faster release cycles; historically, to respond to its B2C customers.