A microservice would be more like a well-structured, logically-bounded Erlang OTP Application (as in literally the Application pattern provided by OTP), than a single process.
You could run the OTP Application, and a bunch of others, locally. You could stick some on a different machine/cluster. Everything is nice and encapsulated and distributable.
The only issue is this would still violate the concept in the OP because it forces everything to either behave like an OTP Application or at a minimum to behave like an Erlang node.
Message Bus != SOA. What the prior poster is alluding too is the Actor pattern and/or Message passing pattern.
My problem with microservices is that your often picking subpar solutions/technologies particularly if low latency is a priority. For example HTTP is not always the best protocol and Request/Reply is not always the best messaging pattern but this is what most people equate to microservice (ie HTTP 1.1 REST a lightweight list of servers (etcd, zookeeper, consuler) or a load balancer).
While subjective, for a JVM-based solution stack, Apache Storm appears to be more elegant, complete and efficient than Linkerd, as an example.
May be advantage of microservices vs Storm becomes more apparent with scale, and I just simply had not had the experience at that level.