For a profession that stresses the importance of naming things well, we've done ourselves a disservice with microservices. The problem is that that there is nothing inherently "micro" about microservices. Some can be small, but size is relative and there's no standard of unit of measure across organizations. A "small" service at one company might be one million lines of code while far less at another.
Some argue that microservices aren't a new thing at all and rather a rebranding of Service Oriented Architectures, while others advocate for viewing microservices as an implementation of SOA similar to how Scrum is an implementation of Agile (for more on the ambiguity of microservice definitions, check out Microservices for Startups).
Regardless, the poor naming of microservices is one of the reasons behind misconceptions and misapplication of microservices. Lots of developers, even those in 3-man teams, are jumping on the bandwagon of splitting up apps into far too many services without understanding what microservices really are.
When a popular, attractive-sounding term like "microservices" flies around, it's easy for the the concepts behind it to get lost and distorted. Martin Fowler calls this Semantic Diffusion.
Semantic diffusion is essentially a succession of Chinese whispers where a different group of people to the originators of a term start talking about it without being careful about following the original definition. These people are listened to by a further group which then goes on to add their own distortions. After a few of these hand-offs it's easy to lose a lot of the key meaning of the term unless you make the point of going back to the originators.
The misconceptions don't just affect people who want to use microservices, it also stokes the fires of those that dismayed by the industry hopping on the microservices bandwagon without deep understanding of its concepts.
Confusion on Teams
When I first mentioned the concept of microservices to my engineering team, I was surprised by how quickly everyone researched the idea and then jumped to the conclusion that our monolith should be split up into tiny APIs that were each responsible for a model in our existing Rails application.
From the research I'd done, I knew that it was dangerous to build a bunch of microservices without careful consideration about size, boundaries, and other tradeoffs. But no one on my team seemed concerned about it.
So I probed my team with questions. Why so many services? Why not less? What were the tradeoffs?
What I found was that people on my team were jumping to conclusions based on shallow notions of what a microservice was. They held knowledge that microservices were small API's pieced together to create whole systems. But they weren't aware of the intricate tradeoffs and design considerations that can mean the difference between success and failure. They were pitching architectures with little ability to justify or reason about them. They had simply jumped to the conclusion of creating a bunch of API's because that's what they thought microservices were supposed to be.
I wish I could say this was a unique occurrence, but I've worked on several teams where this has happened. If you're reading this, you probably have to.
Getting alignment on your team
How do you align your team when no precise definitions of microservices exist? The most important thing when talking about microservices on a team is to ensure that you are grounded in a common starting point.
But ambiguous definitions don't help with this. It would be like trying to put Agile into practice without context for what you are trying to achieve, or an understanding of precise methodologies like Scrum.