Introduction
The battle of Gaugamela in 331 BCE between Alexander the Great and Darius III was one of the first battles that reach one million soldiers on the battlefield. Since, the military organisations had to reply to a critical question: "How to manage hundreds of thousands of soldiers"? To do it, kings, generals and presidents divided their troops into multiple entities such as Corps, Armies, Divisions or Companies then they attached a commandment, logistics, medical and administrative services to these entities. Today, in the modern armies (US, Russia, UK…), this organisation remains, but the rate of combatants ready to fight on the front represents less than 20 % of the global headcount. The commandment assigns the rest of the soldiers to administrative, logistic or medical services; so around 80% of the resources are dedicated to the army infrastructure to improve the combatant's efficiency. To maintain this complex infrastructure, the armies claim for a large national budget and long-term objectives.
Over the last centuries, the military organisation proved its reliability whatever the latitude or the political regime and even when crisis conditions occurred.
However, the military efficiency never convinced civil or governmental entities hiring hundreds or thousands of employees, to copy the military rules in extenso for their organisation and dedicate around 80% of their employees to improve the efficiency of the 20% remaining.
Today, this incompatibility between military and civil organisations finds an echo in the microservice architecture.
The microservices legend
A wonderful IT legend tells the young developers that in the 10's, large Internet companies such as Netflix, Google, eBay, Uber or Amazon, imagined a new architecture to develop their applications. This architecture promoted the isolation and the independence of small applications named "microservices". Since the architecture matched their requirements and demonstrated its efficiency, these companies used it for their developments and then succeed wonderfully. So, they created the "microservice architecture". The legend carries on telling that the valiant developers that use microservices will undoubtedly get the same glory than the GAFA and NATU developers.
Enter your text here ...
The reality
The legend is beautiful, but the historical reality is else.
At the beginning of the 10's, Internet companies overgrew, hiring more and more developers and managing thousands of projects; so much so that they faced the same challenge than the armies: "how to manage tens of thousands of developers without creating: dependencies between teams, long time to market and high maintenance cost?". In response to that challenge, the management had no other choice than enforcing chronologically: the independence of the development team, then the independence of the applications and at last the independence of the services.
For reliability and efficiency purposes, the IT management improved the services' autonomy (like in the army) and provided the services with development and DevOps teams, persistence systems, containers and independent infrastructures. So, a large part of the resources was dedicated to this new organisation with the objective to make the development more efficient.The constraints forced the Internet companies to apply rigorously, independence, isolation and encapsulation to all levels of their IT systems.The companies with generous budget dedicated to the R&D and large incomes to pay and maintain such a complex infrastructure, quickly developed this organisation. For this reason, this complex organisation was implemented by the GAFA and NATU first and not by the banks, insurances or any other legacy companies. We named this organisation the "Microservice Architecture".
Microservices: an architecture for all of us?
Today, backed by Netflix or Uber successes, lecturers, consulting companies, seminars or technical papers suggest us to adopt the microservice architecture in extenso, by copying GAFA and NATU practices, and claim: "it is the best thing that can happen to our IT". However, very few experts explain that these examples, demonstrated their efficiency with a huge R&D budget and exceptionally one of them, notices that these examples could be inaccurate for a middle-size or small company when the R&D budget is limited.
During the last months, we had the opportunity to discuss microservices with CTOs, project managers and architects working for small, middle-sized and large organisations. During our conversations, all of them expressed a keen interest in the microservice architecture but many point out the gap between their budget and the resources required to implement and maintain a state of the art microservice architecture.
As an example, our interlocutors admitted they could not afford:
- The full independence of the development teams
- The multiple languages' developments
- The deployment of many persistence systems per project.
- The proliferation of containers (even light)
- The substitution of their current architecture, Enterprise Service Bus or Application Servers, by a fully distributed infrastructure
- The creation of additional DevOps teams
In summary, they cannot afford the complex infrastructure defined by the microservice architecture without impacting their current development and objectives.
Some microservice architecture's best practices that prevail in the GAFA and NATU projects becomes an impediment when resources and budget are limited. This limitation first affects the small and medium-sized companies, but surprisingly, many major companies (banking, Telco, retail, logistics) and governmental organisations we met, evaluate the state of art of microservices architecture incompatible with their budget.
Who plays in the first League?
Alibaba, E-Bay or Amazon are fighting to be in the global top five resellers and to reach these ranks, they hire tens of thousands of developers and spend billions of dollars in R&D. In 2018, Alibaba plans to spend $15 billion on R&D and Amazon more than $25 billion.
On the other side, "Alexandre Bompard" CEO of "Carrefour", the most significant European supermarket chain in Europe and the 68th company in the Fortune Global 500, announced €2.8 billion of investment in the digital for the next five years, which brings the investment to €500 Million in 2018: at last 10 times less than Ali-Baba and 20 times less than Amazon.
We give this example not to blame Carrefour (or any other company) for its lack of R&D investment. We highlight that even the world's largest companies do not play in the same category than the GAFA and NATU. For the companies, unlisted in the FG 500, for the SMEs, the SMBs and the governmental organisations, this gap is wider.
Based on this evidence, what is the perspective of the companies who want to improve their architecture and take advantage of the microservice architecture? The response comes from Russ Mills, who wrote: "You are not Netflix (Amazon, Uber, Alibaba…), stop trying to be them!". In other words, Netflix architecture is accurate for Netflix requirements, designed to solve Netflix constraints and overall sponsored by Netflix R&D budget and resources. So, stop to mimic them.
As the military organisation proved its effectiveness in the worth conditions, Amazon, Google, eBay or Facebook demonstrated the microservice architecture efficiency at a very large-scale. These companies dedicate considerable resources to get this level of scalability and efficiency, unreachable in a smaller environment where budgets are restricted. This limitation demonstrates that the assertion: "any company (Whatever its budget) can deploy a microservice architecture in extenso and will succeed, because Netflix, Uber, Alibaba, Amazon did it and succeeded", is a trickery.
The architects and managers, we met, were more pragmatic and circumspect than the blog's publishers on the net. They took a step back for evaluating what we can learn from the microservice architecture success and pushed aside its parts they evaluate inaccurate for their developments.
Service independence, fine-grained interface, publication of contract (API) promoted by the microservice architecture are easily implemented in any project without overspending the budget. Our interlocutors decided to cleverly use them to improve the agility and the maintenance of their projects.
On the other side, the multi-language development, the multiplication of persistence system, the proliferation of containers, the substitution of any form of centralised systems such as the Enterprise Service Bus or the Application Servers by a fully distributed infrastructure, don't win the favours of the architects we met. The deployment of a microservice architecture would require too much efforts, resources and use the whole budget of several years to be completed. Our interlocutor decided to put aside these best practices until their company extends and affords GAFA and NATU R&D budget.
Conclusion
The legend tells us that the GAFA and NATU become huge companies thanks to the microservice architecture. The reality is different: the exceptional growth of the internet companies forces them to adopt new best practices and paradigms which define for a large part, the microservice architecture. The large internet companies demonstrated that the microservices architecture helped them to manage the huge amount of resources and projects but did not give any proof that the Microservice architecture helps smaller companies offering better services to their customers, by improving their time to market and reducing the cost of their project's maintenance and evolution.
Just like any other new technology, microservice architecture must be approached regarding our context, our budget and our background. On the ground, we met skilled architects who resist the Guru's speeches, the developers' pressure and the temptation to copy the overwhelming success of such and such companies. If their budget cannot afford a Netflix-like architecture of services, they don't fear to look ridiculous or corny by taking some distance with the current single-minded approach on architecture today. From them, we certainly learn more about the role of an architect than from the "sheep-like" architecture conferences and seminar that occurred during the last years.
https://www.thestreet.com/story/14338746/1/alibaba-15-billion-dollar-research-and-development.html
http://www.russmiles.com/essais/8-ways-to-lose-at-microservices-adoption