I think it's likely that the recent faddishness of Go, which upon actual use turns out to be difficult to use for anything /except/ microservices, itself is causing microservice adoption.
If I can rephrase this without it being a criticism: Go encourages particular patterns of use, much like any technology.
Rails, for example, strongly encourages programmers to keep a company's entire operations in a single application and memory space. Many Rails shops eventually discover that this is suboptimal for their needs, for example when one particular part of all of their operations need to be scaled up substantially but scaling a "monorail" requires memory proportionate to the total size of all operations times the highest desired throughput of any piece of the system. I'm aware of several Rails shops which needed to retroactively decompose a monorail, and many of them rewrote the performance-intensive part in Go, as Go is bugs-in-your-teeth fast for many common workloads.
Just like Rails "wants" to be a monorail, Go feels to me like it wants to be a collection of small, X00 to ~2k line programs, talking to each other via JSON messages passed either over HTTP or a queueing system. (Use NSQ! It's fantastic!)
Partly this is due to affordances in Go's design for e.g. deploying systems. If you want to re-deploy, just compile (for free) and copy the binary everywhere. Partly it is due to Golang not yet having much in the way of community norms for building really big systems. Dependency management is a very unsolved problem and gets worse the larger the individual pieces of your system get. Golang also isn't very opinionated about project structure in the way Rails is, which counsels keeping parts of your system bite-sized as a way of imposing structure on top of it. (By comparison, you can drop any intermediate Rails programmer into virtually any Rails program and say "Find the login page. Find the $FOO business logic." and they'll be able to do it in a few seconds.)
Rails, for example, strongly encourages programmers to keep a company's entire operations in a single application and memory space. Many Rails shops eventually discover that this is suboptimal for their needs, for example when one particular part of all of their operations need to be scaled up substantially but scaling a "monorail" requires memory proportionate to the total size of all operations times the highest desired throughput of any piece of the system. I'm aware of several Rails shops which needed to retroactively decompose a monorail, and many of them rewrote the performance-intensive part in Go, as Go is bugs-in-your-teeth fast for many common workloads.
Just like Rails "wants" to be a monorail, Go feels to me like it wants to be a collection of small, X00 to ~2k line programs, talking to each other via JSON messages passed either over HTTP or a queueing system. (Use NSQ! It's fantastic!)
Partly this is due to affordances in Go's design for e.g. deploying systems. If you want to re-deploy, just compile (for free) and copy the binary everywhere. Partly it is due to Golang not yet having much in the way of community norms for building really big systems. Dependency management is a very unsolved problem and gets worse the larger the individual pieces of your system get. Golang also isn't very opinionated about project structure in the way Rails is, which counsels keeping parts of your system bite-sized as a way of imposing structure on top of it. (By comparison, you can drop any intermediate Rails programmer into virtually any Rails program and say "Find the login page. Find the $FOO business logic." and they'll be able to do it in a few seconds.)