Does serverless computing also have network-communication issues as microservices?

Network communication among microservices cannot be taken for granted.  A lot of things can go wrong and the following libraries are among those that help dealing with the issues:

Among them, istio looks nicest on paper and supports different communications mechanisms.  However, I dislike the fact that every API call between two services must go through extra two hops through each service’s own sidecar process, Envoy:

The overall architecture of an Istio-based application.

Other than the extra hops, it would also be nice if istio can embed Hysterix  (or something like it) to fail-fast when API calls do not return quickly.

I disagree with Serverless Framework’s claim that the use of serverless architecture (e.g., AWS Lambda) “solves almost all of above problems.”  Serverless computing simply shifts the burden of handling similar issues to the cloud provider, which in itself is a good thing.  As customers of cloud providers, we should demand that cloud providers furnish solutions to our problems, rather than requiring each of us reinventing the wheel.

I like the idea of serverless computing, but I also think that non-trivial applications probably need some long-running services in the mix.  For example, how does one store persistent state without services?  On AWS, one can use DynamoDB for AWS Lambda (AWS SimpleDB is too dumb to be useful for anything but school projects).  As another example, serverless computing in their current implementations requires at least one network hop for every API call, which is too expensive.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s