If I recall correctly, the original SOA vision focused a lot on creating a services catalog and ecosystem, with service location transparency, and loose-coupling between services, yellow pages for advertising and discovering services, and the calling interface formed a contract between caller and provider.
It seemed like a new combination of ideas that could change how software was delivered, but the vision was really tough to realize ... like, how do you bind to a service when its location can change? There was a lot of blind alleys to run down trying to solve that, and ultimately the vendors trundled out their Enterprise Service Bus products. These provided mediation, transparent failover, and quality of service. ESB servers were a new single point of failure, and deploying to ESB's was incredibly painful since you couldn't commit the configurations to source control easily, but you could get that transparency as originally advertised.
And it seemed like everything else in SOA was like that. A lot of solutions begging for problems, or incredible complication that inevitably required massive vendor products to implement - which also led to atrocious runtime performance/instability due to shovelware vendor code.
The Microservices bliki read to me like a reboot of SOA - but a really good reboot. Gone were the service catalogs. And in was discussions of how to organize teams around code/features. There was the whole novel versioning scheme, where multiple versions of a microservice could be deployed simultaneously. And deployed code was immutable - you would never redeploy or modify the code of a version, you'd just deprecate and release another version.
All this stuff screamed "PRODUCTIVE" to me, and was more a return to patterns and not leaving gaping voids in the description for vendors to fill with more shovelware.
It just turns out that software components are tougher to work with and maintain the further away they are from each other.
You can have two components A and B, where A depends on B. A and B are in the same code repository, just kept in separate folders. Doing this is handy because you can do refactorings against A and B and it's easy to keep them in sync. Perhaps A and B are built separately with different build scripts, but they get deployed together and they are versioned together.
Now let's move A and B into their own code repos. Now refactoring is a bit more difficult because now you have to make sure to keep A and B in sync. Why did we put A and B into their own repos? Because the boss is convinced that this separation was critical because he worked at Oracle awhile back (huh?) So, versioning is now an issue too, A has to refer to a version/range of B that it wants. Needless busy work, but alright!
Now that we have our sea legs, we can go ahead and build and deploy A and B as independent microservices: A expects particular versions of B to be deployed, and A calls B via HTTP RESTful service calls. Refactoring is now officially painful, it requires a lot of negotiating between teams. B is required for A to function, the A team has to produce a client library for calling B that issues proper maintenance alerts when B is unavailable. Does B really need to be a microservice and are HTTP calls to it justified? PAIN PAIN PAIN! Hey, couldn't B just be a library that gets called by A and not get its own microservice? (NO! Because Oracle!) That is where the whole "Monolith" discussion starts.
I fault Fowler for painting a rosy SOA'esque picture initially, but I can't fault him too much. The original Microservices discussion he helped launch was really refreshing. It felt doable, it felt scalable, and it felt patterny instead of tooly.
Maintaining service contracts and encouraging intra-team friction is going to hurt agility, and it's a miss that he didn't call that out originally. So, I'm calling you out Martin Fowler: your good idea wasn't a panacea!