https://blog.christianposta.com/microservices/the-real-success-story-of-microservices-architectures/
We hear the benefits of microservices architectures loud and clear; we hear the constant drum beat of how/why/by all means/etc you should be doing microservices; we know companies such as Amazon, Netflix and Gilt have successful microservices architectures.
However, as I’ve touched on in my blog post titled You’re not going to do microservices, getting microservices right – and being able to add your company or organization to the list of success stories – is difficult. Just deciding to use Dropwizard/SpringBoot/WildflySwarm/flat classloader/Docker etc doesn’t mean you’re doing microservices. In fact, prematurely breaking your apps/services down into smaller services has significant tradeoffs and could lead to a SOA on steroids disaster. Even the venerable Martin Fowler agrees with me.
So when we talk about the success stories of microservices at conferences, on developer blogs, etc. I think we’re missing the point. The successes aren’t about which dependency manager, or classloader structure, or linux container, or cloud service to use. They aren’t about mythical internet web-scale unicorns or their architects. I think it’s about something a bit more fundamental, albeit, less sexy than Docker/Kubernetes/SpringBoot.
The real success stories of a microservice architecture are about how organizations that embrace small, cross-functional teams that engage with a flat, self/peer-management structure, are able to scale and innovate at levels unheard of in traditional organizational structures and do it wildly successfully.
I had the pleasure to work closely with teams at Amazon and learn about their organizational culture. One tenant of their structure was that organized teams had to follow the “two-pizza” rule. Simply, a team could not be larger than what two pizzas could feed. The thinking behind this was summed up by an Amazon CEO Jeff Bezos quote:
Managers: We need more communication on and between our teams
Bezos: No. Communication is terrible”
To create and sustain autonomous, creative, innovative teams, you don’t want “more communication” you want “effective communication.” This is easier said than done, but it starts by having smaller groups of people work together. They get to know each other better, they form relationships, trust, and motivation. There is less chance of group think or social loafing.
J Richard Hackman studied team and group dynamics found that the communication links between members grows as you add more people to a team following this equation:
(n * n-1) / 2
As the number of links grow within a team (ie, more members), the communication degrades and team productivity similarly degrades. The number Hackman settled on was something less than 10. Amazon teams usually consist of 6-8 members. Navy Seals work in combat teams of 4. The number is not hard and fast, but it should be small. In fact, just stop and think about social situations you encounter ever day. Is it easier to have a conversation and relate to one another in large groups (ie, at a wedding, people break off into smaller groups to chat)?
I highly recommend reading Hackman’s article here about why teams don’t work.
I saw this quote recently that can perfectly sum up why a team should be cross-functional:
Bad behavior arises when you abstract people away from the consequences of their actions