Les gagnants et les perdants du cloud native

À lire également : David Linthicum de Deloitte sur l’optimisation de votre multicloud 

Petit rappel : cloud native signifie que nous exploitons des services et des systèmes disponibles uniquement chez un fournisseur cloud donné.

Lorsque les développeurs et les architectes parlent de « cloud native », ils font généralement référence à des services cloud spécifiques qui n’existent pas sur d’autres clouds ou sur les plateformes traditionnelles. Ces services cloud incluent notamment la sécurité, la gestion, les bases de données, les systèmes serverless et les opérations financières (FinOps).

Nous utilisons des services cloud native au sein d’applications ou d’autres solutions, pour les raisons suivantes :

• Plus avancés. Les services cloud native sont généralement plus avancés que les services non natifs. Ils offrent un accès direct à d’autres ressources natives telles que le stockage, les capacités de calcul et les bases de données. Ainsi, le cloud native apporte des fonctionnalités plus modernes que vous n’avez pas à développer, tester et déployer.
• De meilleures performances. Les services cloud native offrent généralement de meilleures performances. Celles-ci sont généralement supérieures, car les services sont conçus et détenus par le fournisseur cloud et spécifiquement conçus pour sa plateforme mutualisée.
• Interopérabilité. Les services cloud native fonctionnent généralement bien avec d’autres services cloud native. Là encore, puisqu’ils sont conçus spécifiquement pour un fournisseur cloud donné, ils prennent généralement en charge une intégration plug-and-play avec les autres services natifs. Par exemple, un système de messagerie cloud native communique avec ses bases de données cloud native sans nécessiter d’intégration personnalisée.
• Des coûts réduits. Les services cloud native coûtent généralement moins cher que les services non natifs. Puisqu’ils sont conçus pour un fournisseur cloud donné et ne prennent pas en charge d’autres fournisseurs, ils sont généralement optimisés pour exploiter moins de ressources. La facture cloud devrait donc être moins élevée que si vous aviez utilisé des services non natifs.

Si la liste ci-dessus est exacte, pourquoi utiliserions-nous un jour des services non natifs ?

La réponse : parce que, comme dans tout le reste de l’univers informatique, rien n’est gratuit. Lorsque vous exploitez des services cloud native, il y aura des avantages et des inconvénients, des gagnants et des perdants.

À lire également : Pourquoi le cloud implique le cloud native 

Les perdants du cloud native

Certains constateront que le cloud native n’est pas une solution particulièrement adaptée à leur domaine problématique, tandis que d’autres voudront éviter l’enfermement propriétaire. Si vous exploitez les fonctionnalités cloud native d’un fournisseur cloud donné, votre application et vos systèmes de stockage de données seront moins portables d’un cloud à l’autre ou vers des systèmes traditionnels.

Si nous tirons parti des avantages des services cloud native énumérés ci-dessus, c’est une bonne chose. Toutefois, une solution cloud native ne peut pas être transférée vers un autre cloud ou une plateforme non cloud sans modifications importantes.

Ces modifications nécessiteront de supprimer tous les couplages avec les services cloud native du cloud existant. Il faudra ensuite connecter ces couplages aux services cloud native de la nouvelle plateforme cloud cible, ou exploiter des services plus ouverts disponibles sur la plupart des plateformes, ou encore des services non natifs incluant le stockage, les capacités de calcul et les bases de données.

Les entreprises qui ne prévoient pas à l’avance de déplacer une application hors d’un cloud donné, mais qui y seront contraintes ultérieurement, deviendront elles aussi des perdantes. La modification des applications pour supprimer des services cloud native spécifiques et les remplacer par d’autres services cloud native ou des services ouverts implique des coûts et des risques importants.

C’est clairement le fameux « vendor lock-in ». La plupart des applications qui migrent vers des plateformes cloud ne quitteront jamais cette plateforme pendant leur durée de vie, principalement en raison des coûts et des risques encourus.

Autre inconvénient : il vous faudra des compétences spécifiques au cloud pour tirer pleinement parti des fonctionnalités cloud native. Ces talents peuvent ne pas être disponibles en interne ou sur le marché du travail en général, et/ou ils peuvent faire exploser les coûts de personnel au-delà du budget.

La pandémie a provoqué un afflux massif vers les fournisseurs de clouds publics, ce qui a également fait exploser la demande de compétences en migration cloud, entraînant une hausse des salaires et des honoraires de conseil. En outre, la pénurie de compétences qualifiées accroît le risque de ne pas trouver les compétences nécessaires pour concevoir des systèmes cloud native et/ou de ne pas disposer du niveau de talent requis pour créer des systèmes optimisés et efficaces.

Cela entraîne certaines entreprises sur une voie inquiétante, celle des dépassements budgétaires. Il est plus que probable que les systèmes cloud native aux budgets dérapants ne répondront pas aux attentes de l’entreprise.  Ainsi, il devient souvent plus difficile et plus coûteux que prévu de tirer parti des avantages du cloud native. Le manque de talents cloud native accroît clairement le risque, ce qui pourrait à son tour rendre l’architecture et le développement cloud native trop coûteux au regard des efforts à fournir.

À lire également : Les principaux fournisseurs et entreprises de services cloud 

Les gagnants du cloud native

Bien que la valeur du cloud native puisse augmenter ou diminuer au fil du temps, toute entreprise capable d’exploiter des services cloud native avec au moins deux des facteurs de valeur énumérés ci-dessus (par exemple, les performances et les coûts) finira par compter parmi les gagnants du cloud native.

Les gagnants typiques du cloud native peuvent absorber et justifier le risque et le coût liés au passage au cloud native.  Par exemple, supposons que nous voulions migrer un système de gestion des stocks d’une pile LAMP (Linux Apache MySQL et Python) dans un centre de données vers la même plateforme LAMP exécutée sur un cloud public.

Plutôt que d’effectuer un simple lift-and-shift, l’équipe de migration a décidé d’exploiter certains services cloud native tels que la sécurité, la mise en cluster, le serverless, ainsi que la gestion et la supervision.  L’application doit donc être modifiée, testée à nouveau et redéployée pour exploiter ces services cloud native spécifiques.

L’équipe s’attend à retrouver, dans une certaine mesure, tous les avantages énumérés ci-dessus au sein de l’application migrée. Le travail supplémentaire nécessaire pour passer au cloud native augmentera les coûts d’environ 300 % par rapport à un simple lift-and-shift de l’application avec un minimum de modifications. La solution cloud native finale vaudra-t-elle les coûts et les risques engagés ?

Il est temps de prendre des paris. Premièrement, vous pariez que la dépense supplémentaire liée à l’ajout de fonctionnalités cloud native se traduira à long terme par une valeur accrue, notamment sous la forme d’avantages en matière de performances et de coûts. Deuxièmement, pour être un véritable gagnant, vous pariez également que cette valeur bénéficiera à l’entreprise pendant toute la durée de vie de l’application.

En règle générale, le coût moyen d’un passage au cloud native représente environ 300 % de celui des approches sans modification. Ainsi, si un lift-and-shift avec un minimum de modifications coûtait 50 k$ tout compris, une application cloud native coûterait environ 150 k$ pour la même application. Dans cet exemple, l’équipe de migration a parié 100 k$ que l’entreprise récupérerait au moins 100 k$ de valeur en optant pour le cloud native.

De nombreux facteurs déterminent si le pari du cloud native sera gagnant, et vous devrez examiner chaque application individuellement pour déterminer si vous gagnerez ou non. N’oubliez pas non plus le facteur imprévisible.  Si le système cloud native doit un jour migrer vers un autre cloud ou revenir aux systèmes d’origine, tous les paris sont annulés et vous redevenez un perdant du cloud native.

À lire également : Bonnes pratiques du multicloud (que les fournisseurs cloud préféreraient que vous ignoriez) 

Quelques conseils, mais aucune réponse simple

Si passer au cloud native était un choix simple et évident, tout le monde le ferait. En apparence, le cloud native offre des applications plus efficaces, dotées de fonctionnalités plus riches et consommant moins de ressources cloud. Mais il s’agit d’un autre compromis propre au monde informatique. L’équipe de migration doit prendre en compte tous les aspects de ce qui est transféré vers le cloud et fonder son pari sur le cloud native sur les caractéristiques de chaque solution de migration envisagée.

Je conseille d’établir, pour chaque projet de migration cloud, une liste comparative exhaustive présentant les avantages, les coûts et les risques associés au lift-and-shift par rapport au cloud native. À mesure que nous acquérons de l’expérience et progressons dans l’informatique cloud, nous deviendrons naturellement meilleurs pour sélectionner les applications à convertir au cloud native. Nous produirons ainsi davantage de gagnants que de perdants.

À lire également : Prévisions technologiques pour 2022 : cloud, données, cybersécurité, IA et plus encore