Cloud architects have been quickly converting CIOs and IT Engineering Managers to adopt Microservices Architecture for a couple of years now. Teams have invested considerable sums in training staff and buying the tools to implement a whole raft of microservices in their organizations. Product vendors and cloud service providers have been pumping out new offerings on a regular basis to improve the manageability and scalability of microservices.

There’s a flaw that I’ve seen in practice, though. Coming down out of the ivory tower for a few minutes, there’s a flaw that is easy to see when you look at actual microservices and how they are actually built. The flaw is Conway’s law.

For those of you not familiar with Conway’s law, this is a bit of computing history. Back in the early years of computing, a young Melvin Conway, not long after earning his Ph.D. in Mathematics, presented a paper called “How Do Committees Invent” at the 1968 National Symposium on Modular Computing. He proposed the following:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

How Do Committees Invent; Conway, Melvin; Datamation, 14 (5) 28-31

This has been phrased (often humorously) in dozens of different ways over the years. Essentially it means that if you have a system, with four teams working on it, you will have four components in your design. Wikipedia lists a few (with citations of course).

It’s not lost on teams in the modern age that microservices have to be owned by a team. End to end, the entire life of the microservice, along with all of its history has to be owned by a team. Team ownership of the microservice is taken as an underlying principle. But the thing is: the team may own the microservice, but according to Conway’s law, the microservice will look like the team.

More importantly, when a single team owns a set of microservices, and they never just own one, then the set of microservices will come to share common dependencies. Each team will create a set of services that share information models, conceptual models, programming language, API design, and shared libraries. In effect, a set of microservices will be, in practice, a single (non micro) service. There may be multiple endpoints, but they will have one data store, will interact with one another, and will nearly always be shipped together in a single docker container.

Calling that a microservice is a flaw in the thinking. We don’t have a situation where the microservice is a design paradigm. We have a situation where a team is the design paradigm. The team creates one or more services, and those services share things amongst themselves. Because they come from one team.

But why is that?

For the services to be truly independent, the teams that make them must be independent. Implication: Each team to have skills in all layers of the stack. The team has to understand containers, APIs, routing protocols, REST, information design, software development, unit testing, tool chains, CI/CD, code management, security management, and many more cross cutting concerns. Either these people are super human or you have a sizeable team.

Now put these two facts together. Let’s say your IT organization is not large enough to have more than five or six sizeable autonomous teams. That’s pretty typical. Assuming those teams will share design elements, you won’t have 40 or 60 or 80 microservices. Not really. You will have six “micro” service containers. You have six teams. You will have six (not micro) services. (Let’s churn things up… each team can manage three groups of services. Woo Hoo… we are up to eighteen!)

Sure, really large software organizations will have more teams. Netflix, Google, Facebook, LinkedIn, Twitter… if your organization has the size and scope to host 200 teams, each able to develop the complete stack of skills, then you will can have 200 or 400 microservices. Is that you? Really?

So reality check. Come out of the ivory tower. If you are like most IT shops, even in large and profitable companies (that do not make money on their IT capabilities), you really cannot afford to create 500 services. You will have a handful of services for each team. You will have a handful of teams. You will have services. Not microservices. Not really.

Lower your expectations to the size of your organization. We may think we can build a thousand microservices, but we don’t need the tools to support a thousand microservices. Especially if we have the organization to support only ten.