I see microservices as responsibility deduplication in a organization-traversal-wide.
De-duplication is a very old concept (differentiates good "sysadmins" from bad ones, since the 90's, and good programmers from bad ones).
Thinking organization-traversal-wide is what is hard for some persons.
Currently working at consulting in a big corp... you get to this problem:
Resource: name FooBar, type int (organization view point)
app1 name: FooBar type: int
app2 name: foo_bar type: int32
app3 name: Foobar type: Meta::Foo::Bar
app4 name: foobar type: string
app5 name: fooBar type: int64
...
etc until app 35 and script 192679
Microservices, thinking transversely, solve that. See AWS, GoogleCloud, Azure, etc "resource names" (ARNs, etc), for an example of a simple and great microservice.
Note also, that microservices experts (and I'm not one of those) recommend a monolithic and transactional core architecture, for microservices infrastructure.
De-duplication is a very old concept (differentiates good "sysadmins" from bad ones, since the 90's, and good programmers from bad ones).
Thinking organization-traversal-wide is what is hard for some persons.
Currently working at consulting in a big corp... you get to this problem:
Resource: name FooBar, type int (organization view point)
... etc until app 35 and script 192679Microservices, thinking transversely, solve that. See AWS, GoogleCloud, Azure, etc "resource names" (ARNs, etc), for an example of a simple and great microservice.
Note also, that microservices experts (and I'm not one of those) recommend a monolithic and transactional core architecture, for microservices infrastructure.