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 68^th 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.lsa-conso.fr/alexandre-bompard-devoile-la-strategie-digitale-a-5-ans-de-carrefour-analyse,278352

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

https://www.forbes.com/global2000/

Introduction

A long time ago, when the internet access was limited to the armies and universities, the teenagers had very little reliable information available about the relationship with the other sex. Our knowledge was based on rumours and hearsays. One day, one of our classmates told us that it found at home, a copy of the Kamasutra. Very quickly, he learnt by heart all the positions described in this book and enjoyed miming them before us. We were impressed and stupid as a teenager in the 80's; we thought that his first relationship would be a firework for his partner and the hearsay of this unforgettable moment will provide him all the girls of our high school.

Unfortunately for him, his first relationship was a disaster. His ephemeral conquest told the other girls of the school that he was a deviant, a sex maniac and because of the name she made to him, he had to wait for the university to find another girlfriend.

​​The story

A few years later, our company got a contract to support an English governmental organisation in architecture design. For this project, the organisation had to hire an IT architect, and during our first day on the project, we have been asked to be present to the job interviews and give our feedback on the candidates.

The complete interview was made up of three steps.

The first step was an interview led by an RH person who asked some technical questions written on a page. The first question on the list asked the candidate to give the name of five message patterns found in the book Enterprise Integration Patterns. We were surprised by this question, wondering why the question referred to this book and not another one. Moreover, we thought that an architect could be aware of a communication channel between a consumer and a provider, but ignore it is named "Message Channel Pattern" in that book. Also, the candidate can master the XSL transformation but ignore that Hohpe and Woolf named this technology a "Message Translator pattern". The interviewer who has no technical skill was unable to evaluate the knowledge of the candidate and just checked if he responded matching the answers on her page.

For the most accurate (or luckier) candidates, came the second interview led by two technical people. The first question asked of the candidate was: "What patterns do you use in your projects" and once again, the candidate had to name some pattern he/she used. The more you named the best you were. We were amazed because the interviewers did not ask any question about the main concepts used when designing an architecture: relationship with the stakeholders, the legacy integration, the scalability, the reliability, the context management, the different protocols used, the coupling between services, the data management and all the other concepts used in IT architecture. They just asked a question about design patterns and DevOps.

The last step of this process was an interview with the project manager. That day, we had the opportunity to talk with her and understand the team's obsession with design patterns. We reported our comments about the questions asked of the candidates. When we started talking about integration and services, she claimed to have a strong development background but confessed a weak skill on integration and architecture design. However, to compensate this confession, she immediately claimed that she read "a lot about Enterprise Integration patterns" and explained that integration and service-based architecture are not a big deal if you can find out the right patterns to represent the exchanges between the systems to integrate. We replied that if some parts of architecture could be described with design patterns, it requires broader such as the conformance with business services, scalability, service granularity, or reusing. So, if the design pattern concept could be an effective tool, it did not cover the multiple facets of the architecture and the integration design.

She coldly replied that her company promoted a wide use of design pattern as an industrial process for the development and the architecture and added in the same sentence that the design pattern concept is good protection against the hare-brained ideas and unstructured works of the architects. Glooouups.

No need to say that after 2 or 3 similar conversations, days of tension and considering the team management's lack of willingness to collaborate with us our inability to provide a good hand over or architecture design support, we stopped our collaboration with the project.

Design Patterns which position?

In the sixty's, when Christopher Alexander formalised the concept of design patterns, he expected to bring easiness in the repetitive tasks during the architecture design. He never aimed to stop neither the architects 'creativity nor to limit their capability to think differently.

The same rules apply to IT. Design Patterns are a nice way to formalise one of the solutions to a repetitive problem in the architecture design (Building or IT).

So, the IT architect's mission is to understand a technical or a business requirement, design or identify a solution that could fill this requirement. He/she must evaluate which technical solution is the most accurate to the customer context and consider additional constraints such as the future evolution of this context. Then, if his/her design matches a well-known pattern, the architect can use it "as a convention" to make the solution quickly understandable by the other architects or developers.

Giving a name to this solution is the cherry on the cake, but certainly not the core of the architect work. An architect works with more complex concepts than just a list of design pattern names. He is responsible for the architecture adequation with the customer requirement, its adaptability, scalability and reliability. As far as we know, these concepts are not covered by the design patterns. Strong knowledge of the basic architecture concepts is required to use the design patterns efficiently. Starting by choosing a design pattern puts the car before the horse.

So, the ones, who use the design pattern as the basis of their work, is exactly in the same situation than our classmate who thought the intercourses in term of positions but ignores what are is the touch, the feeling, the pleasure and the love. When they think about architecture, they imagine it as a pattern design list and ignore the realities of the topic.

For many years, IT discussions, seminars or exhibitions were swamped with design patterns talks. When a new technology emerges, experts and specialists race to publish books of patterns that demonstrated their skill and hindsight on that technology. Books such as enterprise design patterns, enterprise integration patterns, Java design patterns, SOA patterns, microservices patterns offers hundreds pattern description pages in modern terms, but without real innovation, compared with the original "Design Pattern" book published by the Gang of Four in 1994. If the technologies progress, the scope of possibility gets wider, but the core of the topic remains mostly the same.

Today, IT architecture projects turn into a list of design patterns to apply without any global vision of the architecture objectives. The most depressing is to be said: " Which pattern do you want to implement?" when you suggest to your colleagues an alternative view of architectural design. Our interlocutor is unable to think that a design could be something not already classified in a design pattern book.

Thinking this is the end of the architectural creativity. Alexander, Gamma, Helm, Johnson, Vlissides, Hohpe and Woolf must be sad seeing how their creative works have been distorted to limit our creativity.

Conclusion

Like a virgin reading the Kamasutra, the design-pattern-oriented zealots mix up the architectural concepts and the name of the concepts, deep learning on these concepts and the result of this hard work. Like our classmate who called himself "Don Juan", they call themselves "Architects". We think that the result of this misunderstanding has a part in the denigration of the architect role and knowledge and hope that underlining this confusion could help us to focus our efforts on the right concepts in architecture.

Paul Perez
IT Architect at Pymma 

Recently, browsing on YouTube, I re-watched the lecture given by Martin Fowler in 2014 on the microservices. As usual, Martin was a wonderful speaker, clear and concise. But in the middle of the lecture when he talked about differences between Microservices and SOA, I found his speech a bit more confusing and his conclusion on that topic was unclear and vague.

If you pay attention to his speech, before saying his conclusion on that chapter, he reported two witness statements: the first was from SOA people who developed successful SOA projects, surprised by the lack of innovation and freshness in the microservices definition and practices, and the second, from microservices people, mainly coming from big companies, fed up with SOA, who see SOA as 'Enterprise Services Bus' and 'committee that wants to lay down standards'. 

Then, Martin concludes by an evasive definition that Microservices is a subset of the SOA.

However, he did not give any border line between the two domains, but said that the term, SOA, is a too broad and the microservices is a useful subset of SOA.

With all my respect, I think that if Martin presented good arguments in his speech but did not give the real difference between microservices and SOA.

Before going forward, it is interesting to notice, that concept of microservices had a prompt success in large companies first. Surprisingly, from its inception, the microservices have been used to deprecate the 'SOA' concepts, even if the gap between both techniques was very thin or in many cases, null.

Here cHere ome a few simple questions: Why did some people try to oppose the two technologies that are so similar? Why did they want to push SOA to oblivion while they use exactly the same principles and technologies than SOA?

Martin provided in his lecture, many trails to reply to the questions, but I came to a different conclusion. If we can understand this antagonism which is not based on technical differences, maybe we will understand the differences between SOA and microservices.

To understand this antagonism, the SOA Manifesto, the abstract of the SOA philosophy, must be read once again. In the manifesto's introduction, it is written:

Through our work, we have come to prioritize:

Business value over technical strategy
Strategic goals over project-specific benefits
Intrinsic interoperability over custom integration
Shared services over specific-purpose implementations
Flexibility over optimization
Evolutionary refinement over pursuit of initial perfection

That is, while we value the items on the right, we value the items on the left more.

In this introduction, the first priorities were not technical challenges, but the Business value and the Strategic goals.

When you are concerned about Business value and Strategic goals in your project, it is in your interest to involve the most capable to define what the Business values and the Strategic goals are. This means that the SOA philosophy requires the business to collaborate and more annoyingly for IT teams, it needs a kind of leadership from the business, because Business value and the Strategic goals definitions are more accurate and efficient when defined by business people.

For years, business and IT lived in two different worlds. The communication between them was focused on budget, cost, business specifications and nothing else. It was OUT OF QUESTION that the business interfered in the IT works and the later in the business prerogatives. This antagonism between the two entities lasted for decades.

However, 10 years ago, for the first time in IT's history, a new philosophy puts the business goals and the long-term strategy as a priority. For the first time, IT people had the willingness to involve the business in the IT development process. If the business never understood what was a function, a component or an object, for the first time, SOA pushes forward a concept named 'Business Services', which had a coarse enough granularity to be understood and used by the business. So, for the first time, business and IT could exchange, and work on similar concepts.

Unfortunately, especially on larger projects, consulting companies found in this opportunity a way to impose expensive business consultants and management, to IT teams. I remember taking part in numerous meetings with high-rate business consultants who didn't have a concrete idea of what a service is, but could explain through wonderful PowerPoints, how SOA could help us to design and develop them. Pushed by the C level management and the consulting companies, a useless business predominance replaced a required and fruitful collaboration between both parties. A reaction, from the IT, to stop this predominance occurred and has been named 'Microservices'.

It is interesting to analyze, why this reaction took the name of 'Microservices' and not 'Light Services', 'Agile Services' or 'Reactive Services'?

The prefix 'micro' before 'services' that suggests services with fine granularity, does not make sense since neither SOA nor Microservices define a standard granularity for a service. Often services defined by microservices developer have a coarser granularity than the ones developed by SOA developers.So, what is the symbolism behind the prefix 'micro' and why it was so pleasant and attractive to IT people.

Wise men explained that a name, often contains the finality of the named entity or concept.

As noticed above, one of the SOA aims, was to promote Business Value and Strategic Goal. Consequently, this aim was to define services comprehensible by the business and coarse enough to be useful for business process definition. In the way IT thing, the services understandable and used by the business have a coarse granularity.

In reaction, IT people created the concept of 'Microservices'. The objective was to define small services where the granularity was too fine to be in the business scope. So, with microservices, the business cannot interfere in the IT work anymore. That is the opposite of the SOA initial philosophy.

Actually, there are no technical differences between SOA and microservices, but their fundamental difference is the interest in a relationship between business and IT.You can find this idea coming from a day to day psychology, but to be convinced, notice that neither the technical papers, nor the blogs, nor the conferences about microservices consider business concerns or simply talk about a link between microservices concepts and business concerns.

In reaction to the business predominance created by the bad use of SOA philosophy, business concerns and strategic goals have been erased from the microservices manifesto and developer objectives.

Microservices SOA Collaboration with the business Yes, please No, thank please
The border line between SOA and microservices is simple to understand and is defined by the IT wishes to work with the business. Through this dimension, Microservices is not a subset of SOA but a different domain.

Of course, the real life is not black and white and many microservices people collaborate with the business and some SOA people don't. Here, I'm not talking about people but the history, the philosophy and the concepts that generate the microservices wave. It is good to put names on things, and understand where SOA and Microservices are different. Up today, I did not find similar point of view expressed yet. I could be completely wrong, but I think, we are reluctant to this idea which associates microservices with the 80's-90's mentality and is not politically correct. So, it is difficult to express it before an IT audience who feel enthusiastic about microservices. Without this truth, we couldn't understand the increasing separation we notice today between IT and Business.

This said, everyone knows that the future of IT is to work in harmony with the business and allows it to be involved in service and process definition. We could wait for a few years, the next swing of the pendulum and then be thrilled by a new buzz name that promotes a collaboration between IT and business.

Or simply, whatever denomination we want to use for the same technology, we can retrieve a peaceful and successful collaboration that occurred a few years ago, when a strong respect existed between business and IT. That would certainly be the best choice for all of us!