Why not just use RPC?

@bfirsh Cool project. I'm curious as to what the motivation is to not just use RPC though. For instance, if you look at [Golang RPC](https://golang.org/pkg/net/rpc/), the `Arith.Multiply` example is pretty similar to `add` example here. You might want to think about adding a section to the `README.md` addressing this, since it's unclear to me.

With RPC, a load balancer (probably even Docker's default `service` LB) could go in front of multiple copies and updating # of replicas would be "scaling". JSON-RPC or gRPC (granted, gRPC is a whole beast of its own) could be used if compatibility between languages is desired. Granted, you would need to keep at least one "warm" copy around, but a little RPC listener doesn't eat too many resources.

p.s. -- I know the project's just for funsies, but I wondered if you might have a better answer for me than what I could come up with on my own :)

p.p.s -- One possible answer is that `funker` could be the management layer which creates / sends requests to containers/services _in response to events_. e.g., there's a built-in "store" of events to possibly react to, like "someone posted a GitHub issue on repo X".

This seems to be one of the main appeals of Lambda (the other being promise of easily burstable compute without needing to manage individual machines) -- think things like, "when a photo gets uploaded to bucket A, I want to react by downloading, resizing it, and uploading the resized version to bucket B".

Start by reading README.md and the linked Golang RPC example to understand the project's current model. Document why funker does or does not use RPC, including the scaling and event-driven considerations raised here; done means the README clearly addresses the comparison.

Written by the indexing model from the issue text.