What do they mean with "god forbid a microservice"?
So each of them has a potential for an unexpected and transient failure that may be returned either via an exception or via a null result.
In my own experience with systems built on top of multiple services (not micro in my case but enough services...) unexpected nulls or incorrectly handled exceptions from transient/network failures in the services depended on is a common mechanism that surfaces bugs in production code.
And these bugs rarely show up in testing unless someone went out of their way to simulate the failure(s). Optionals have been a good way for us to convey that possibility to the calling code and force the consumer to consider the possibility and plan an appropriate response (we're big fans of fail-fast).
I can't remember who said this originally, but it was something like "The first rule of distributing your application is don't." The implication is you should distribute by business concern, not by tech concern.... which could be done with microservices, but it's not how they're being used right now.
http://www.drdobbs.com/errant-architectures/184414966
Just skimmed through the article and found myself nodding all the way through.
Also: I'm not really buying into the whole microservices movement, it is the latest silver bullet.