Stop moving to the Cloud, to microservices...

Introduction #

Customers are increasingly attentive to the quality of services provided. To meet this challenge, companies are stepping up their efforts to make their IT systems more performant. Many levers are available: acting on the architecture, acting on the components (horizontal and/or vertical scaling), acting on proximity (deploying the solution closer to the consumer)... There are proposals that are systematically made by consulting firms to these companies: they must move

• to Cloud Computing to deploy faster, closer to the consumer...
• To a micro-services architecture to make it more performant, scale your application, ...

But why do I—who, during my end-of-studies internship in 2011 at EDF, started my career in Cloud Computing at a time when companies were still questioning it—oppose its adoption? My internship report was used to write the first commercial brochure on Cloud Computing for the company DEVOTEAM.

Why do companies fail? #

The reasons for failure are numerous, but we have some recurring cases:

The misunderstanding #

Among the advantages highlighted for moving to Cloud Computing, we can cite financial savings. Indeed, a catchphrase of the model is 'pay as you go', in other words, pay for what you consume! This is true because we move from a CAPEX model to an OPEX model. Put simply, companies reduce investment costs (purchasing, maintenance...) in favor of operational costs. Furthermore, another principle of the Cloud is the notion of bursting, meaning the company uses its on-premise infrastructure and when it reaches its limits (activity peaks, commercial operations...), it calls upon its Cloud provider to absorb the extra traffic. Unfortunately, companies have made opposite choices thinking that by getting rid of the on-premise infrastructure they would save even more, but it's rather the reverse effect that occurred due to a misunderstanding of 'pay as you go'. They didn't understand that this meant paying for *everything* consumed, and the calculation omitted costs that were unpriced in an on-premise model: the price of network bandwidth, the price of an IPv4... Nowadays, the IT budget of some companies has exploded so much that we see different situations:

• Companies that have not implemented methods to identify the pricing difference between on-premise vs Cloud
• Companies that realized they were spending too much and decided to backtrack and leave the Cloud
• Companies that spend too much but are afraid to initiate a rollback. Probably companies that didn't take into account a basic principle of outsourcing: the reversibility plan. Obviously, a Cloud provider won't help its client jump ship: we are not in a perfect world, after all. Coincidentally, a new term emerges: FinOps. Hats off, guys. Basically, I can summarize this by saying: 'We promised you savings, that is not the case, but stay, we will give you tools to understand your expenses.' In the end, they are not wrong; with good tools, you can easily identify points of useless expenditure, but this...

  Anticipation vs forecast #

  Many companies are in an anticipation mode. They build an architecture that corresponds to a long-term or medium-term need. It's true that a long-term need can become a medium-term need in case of rapid growth. There is no doubt that a robust and resilient architecture must be built, and for many companies, this mistakenly means moving to micro-services. The French unicorn Doctolib, specialized in medical appointment booking, runs on a monolith architecture—and yes, I did say monolith, but 'modular monolith'. During the development phase, the modular monolith is identical to micro-services because the application is split into independent functional units, but the difference lies in the deployment phase where micro-services are deployed on different machines/containers, whereas in a modular monolith it is done on the same machine, but each module has its own lifecycle. Doctolib has recorded around 85 million vaccination appointments since late 2020 with this architecture, and similarly, we can also cite the company Shopify.