The origins
Human being can be described in many ways. We, as a animal specie, are complex and intricate. One of the many characteristics that can be used to describe us as a very special and strange form of life the fact that we live in a organized group called society. In fact there is not just one form of society. Different groups of humans are organized in very different ways therefore very different societies exist among our specie. Like societies, in the context of human organization, computer systems also need some kind of organization to tackle all the complexity, that inevitably rises, due the fact that we add more and more features to our programs. In the beginning of time computer program complexity was tackled by improving the computer languages we used to build our programs. Initially computer languages were directed mainly to computer architectures and were basically simple translators. Operations were represented in a human readable form, the opcode. The translator mapped these instructions into a representation that machines could understand and execute, the machine code. This primitive way of programming is known by the name of assembly language and the program that translate one form into the other is the assembler. Time gone by and people start developing more sophisticated and higher form of abstractions to represent programs. As a result was invented the compiler. With a compiler people could use human friendly languages and describe concepts in a more abstract way that is easy for humans to understand and work with. In the end we called the compiler to do the magical step of converting the high level language into machine code. Again, time gone by and the complexity of the projects start to become overwhelmingly big and just one human was not enough.
Scaling systems
People start to organize in teams and teams of teams, and using a divide and conquer strategy to tackle complexity. Big programs were sliced into distinct parts and each team would work independently on each part. In the end, hopefully, we would join all the parts and everything would end up nice and smooth. Unfortunately many of the projects didn't end up nice and smooth. On the other hand the initial premises changed during the life of the project and those had implications to the initial architecture and to the success of the project. The high percentage of failed projects forced the industry to rethink the way stuff was done and people start to search for new ways of managing the risk and at the same time the gigantic complexity. The industry acknowledged that one of the main problems of software projects were how unaligned clients expectations were with respect to the software, as well as how bad initial requirements were so distant from what were really pretended. With this in mind new ways of doing software developing arise. The key idea was a quick feedback and a iteration based development that give the possibility of more frequent validation of requisites as well as more versatility to new ones, at the same time that risk was controlled in a tight way. Agile is just a name (a philosophy to be frankly) that we call to the implementation of these ideas. Again, time gone by and the complexity and risk of software didn't soften and more sophistication needed to come into the arena. For some kind of really big projects people start to notice that they were much like societies. The idea was that the same organizational level we use to manage the complexity of human relationships could be useful in the software industry. This way of thinking has many forms but it is undeniable the distinction of micro-service oriented architecture as being the jewel of the crown. So the question is: Are micro-service enough. Did this new way of doing things solved the problem of managing risk and complexity for projects whose dimension goes over 9000?
Conway's Law
In How do committees invent, Melvin Conway's paper, we can read the following
It seems reasonable to suppose that the knowledge that one will have to carry out one's own recommendations or that this task will fall to others, probably affects some design choices which the individual designer is called upon to make. Most design activity requires continually making choices, Many of these choices may be more than design decisions; they may also be personal decisions the designer makes about his own future. As we shall see later, the incentives which exist in a conventional management environment can motivate choices which subvert the intent of the sponsor.
Yet in the Conway's article we have one very interesting conclusion
Ways must be found to reward design managers for keeping their organizations lean and flexible. There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity.
All this was written in April 1968. Well we are in 2016 and organizations still struggling to allocate the human resources in the most efficient way. Fortunately now we got micro-services that will solve all the problems. Or do we? If we carefully read Conway's article we easily conclude that no matter what the process the company adapt there will be hidden forces that will try to adapt the process into the company structure. This is already addressed by Conway's paper in a very interesting application of direct linear graphs. The interesting point here is not if Conway's Law still works but, instead, how does this pressure manifests itself in a micro-service oriented organization.
Walk through Sin City
Lets assume we got a micro-service oriented architecture an lets call it Sin City (why not), for simplicity purposes.
Each node of the previous draw is a micro-service but when we look these names we remember something more familiar. I bet this draw makes you think of a small village, and the only reason why cities don't came into your mind is because we don't have enough elements in the picture. So if a lot of company entities make us think of a city, more accurately the economical topology of a city, then where does this leave us regarding the economy theories that study the way these organism works? The question here is, can we parallelize between economical agents and respective theories and the world of microservices? Well to begin with we got two main branches in economics, much like quantum and the relativistic approach, that have two different approaches and objects of study. Our friend wikipedia broadly defines micro and macro economy as
Microeconomics (from Greek prefix mikro- meaning "small") is a branch of economics that studies the behavior of individuals and firms in making decisions regarding the allocation of limited resources.[1][2][3]
Macroeconomics (from the Greek prefix makro- meaning "large" and economics) is a branch of economics dealing with the performance, structure, behavior, and decision-making of an economy as a whole rather than individual markets. This includes national, regional, and global economies.[1][2]
What are the individuals and firms, and resources, in the case of a Micro-service Arquitecture? Well I would say that a micro-service can be seen as a traditional company.
We can see the workers as the team members. The stock I believe we can identify as the component the team in involved with. The capital we can say that is the time of the team members will have in the future to do the work. In a sense time is money. In another way we can see capital of a micro-service as the man/hour time available to do the work.
The economy on micro-services
Well, lets turn again to traditional economy. We know that in a real economy we got a multitude of mechanisms that are well studied and which have impact in the local and national economy (micro, macro). For instance is well known that big companies can be a problem when they reach a status of too big to fail. The pressure these organizations can put in the government of a country is big and in the end this turns out to be a problem to all the economy. The to big to fail problem in a micro-service architecture is a service that has to much importance or has to many responsibilities and as a consequence enormous power and risk inside an organization. We all know that not all micro-services are of the same importance, it is possible that some are not so core and if they are not functioning right the system is able to continue without much trouble. For instance if you got a platform for batch processing that index and extracts data for data mining process and this is done in time intervals of weeks and the impact in business is small the importance is not the same as the core transactional part that is responsible for market processing data. So different micro-services have different weights inside the organization. So the same principle of to big to fail that exists in economy also can exist in the micro-service world. Which in layman terms is just the importance a specific micro-service has in the company.
Another mechanism that is sometimes not desirable on an economy is when state has an active role on the economy and cherry pick what companies to foster and those who aren't needed. Government has an enormous power since it can use its legislative tools to restrict economy. Imagine that the Mayor of Sin City decides that Bicycle Workshop should give away, and not sell for a market price, bicycles to every one that works on the bakery. By doing this the local government is creating stress and difficulties on the Bicycle Workshop which will have a negative impact on this last company. But does this happens in the micro-service world? Well lets imagine that the upper management (the equivalent of Mayor) decides that a micro-service A should do some work that in a architectural viewpoint is from micro-service B because, for example, service B has not enough man power to implement that feature, so it is decided that this should be migrated to micro-service A. This is not very different from the active role of local government in the economy of Sin City, is it? These are just simple examples that, I believe, show that common economies and the micro-service world is not so far away from each other. The point here is that not only Conway Law is easy to verify but if the company is big enough and the problems big enough the mechanisms that already exist, and which inspired micro-services, also emerge. This can be a problem if ignored by those who are responsible. In the end, like in a human social organization, we are all responsible.