Microservice architectures are a sub-category of SOA.
Many of the same reasons to use them apply to both, but with a finer granularity on what is being hosted where and how it is scaling with microservices. Scaling a service with multiple facets going through it gets tricky, hence a desire for a more appropriate modularity.
"Placing services in the cloud" kinda papers over why microservices and cloud-native apps hang together so tightly... Leveraging cloud-provider capabilities (message queues, streaming services, specialized DBs, etc), often introduces new kinds of scaling, new requirements, and new deployment needs at the component level. Particularly if you're working in multiple clouds or a hybrid environment or with teams in different organizations... Tech stacks might diverge at the component level, developer competencies diverge, maintenance routines and monitoring and the rest of it too.
A thin service wrapper in front of DynamoDB is gonna have a different scalability story than a DoItAll service on a VM that can also write to DynamoDB. Especially if the service is used by multiple apps, or customers in addition to apps. For a SaaS outfit that can be make or break.
"Message queues, streaming services, specialized DBs, etc" have no intrinsic properties making them "cloud-provider capabilities".
All of these "cloud-provider capabilities" are just normal software that you can run on your own hardware. In one or two cases, the software was first exposed via a particular provider's platform, but similar, and very likely superior software that accomplishes the same goals, is now available for self-hosting (Dynamo -> Cassandra or Riak, for example). That's about as strong as the connection gets.
It doesn't follow that "microservices and cloud-native apps hang together" because the cloud provider charges you a lot of money to access their Redis server, when you could run your own Redis server.
Yes, I agree. My concern is more that microservices (as a sub-category of SOA) are a fad that few people will care about or use 10-20 years from now. Most services probably don't ever go beyond monolith, the rest move to SOA and probably a minuscule minority actually needs microservices.
Many of the same reasons to use them apply to both, but with a finer granularity on what is being hosted where and how it is scaling with microservices. Scaling a service with multiple facets going through it gets tricky, hence a desire for a more appropriate modularity.
"Placing services in the cloud" kinda papers over why microservices and cloud-native apps hang together so tightly... Leveraging cloud-provider capabilities (message queues, streaming services, specialized DBs, etc), often introduces new kinds of scaling, new requirements, and new deployment needs at the component level. Particularly if you're working in multiple clouds or a hybrid environment or with teams in different organizations... Tech stacks might diverge at the component level, developer competencies diverge, maintenance routines and monitoring and the rest of it too.
A thin service wrapper in front of DynamoDB is gonna have a different scalability story than a DoItAll service on a VM that can also write to DynamoDB. Especially if the service is used by multiple apps, or customers in addition to apps. For a SaaS outfit that can be make or break.