Microservices are often basically equivalent with RPC calls. So they have a lot of potential failure modes like service down, network partitioned, timeout, etc.
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).
Yep! It's the fallout from people that didn't learn the lessons in the great SOA/ESB era :P
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.
Comments
Microservices are often basically equivalent with RPC calls. So they have a lot of potential failure modes like service down, network partitioned, timeout, etc.
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).
Yep! It's the fallout from people that didn't learn the lessons in the great SOA/ESB era :P
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.
Martin Fowler's First Law of Distributed Object Design: Don’t distribute your objects!
http://www.drdobbs.com/errant-architectures/184414966
Just skimmed through the article and found myself nodding all the way through.
Yeah and before the SOA/ESB folks, it was CORBA/DCOM (and but uttering those words, I am now too old to be marketable.)