When Google, Amazon, etc. did it, it was called Service-Oriented Architecture (SOA). There's a good reason for that: doing it on a "micro" basis is ridiculous.
I've got pretty extensive experience with the Google stack. At Google's scale, there's really no other way to solve the problem. However, there are very real costs to all those process boundaries that make you move much slower. When I started there (2009), the common wisdom was that if you were trying to launch a new product, you absolutely did not want to pay those costs unless you absolutely had to; go start with a single binary that interfaces with BigTable/AppEngine/SSTables and see where it grows from there. When I finished there (2014), the common wisdom was "don't launch a new product".
Google can afford to not launch new products (or see all their new products fail) because when adding a new feature to an existing product can make $100M+, that's a lot more economically sound than taking a risk on something new. Your startup cannot afford to not launch a new product. Don't follow Google.
I've got pretty extensive experience with the Google stack. At Google's scale, there's really no other way to solve the problem. However, there are very real costs to all those process boundaries that make you move much slower. When I started there (2009), the common wisdom was that if you were trying to launch a new product, you absolutely did not want to pay those costs unless you absolutely had to; go start with a single binary that interfaces with BigTable/AppEngine/SSTables and see where it grows from there. When I finished there (2014), the common wisdom was "don't launch a new product".
Google can afford to not launch new products (or see all their new products fail) because when adding a new feature to an existing product can make $100M+, that's a lot more economically sound than taking a risk on something new. Your startup cannot afford to not launch a new product. Don't follow Google.