Cet article a été traduit automatiquement.
Lors de la préparation d'un nouveau projet d'application ou de la migration d'une application existante, il convient de veiller à la stabilité de l'environnement de production. L'architecture "cloud natif" part du principe que votre nouveau projet se déroulera dans le "cloud". Cela signifie que chaque décision que vous prenez doit tenir compte des besoins de l'informatique en nuage.
Les constructions de nuages natifs requièrent de l'expertise et de la pratique. Mais si vous maîtrisez ces concepts et si toute votre équipe IT y adhère, vous créerez des projets qui fonctionneront parfaitement et magnifiquement pour votre utilisateur, quelle que soit la manière dont il accède à votre travail.
Qu'est-ce que l'architecture cloud natif ?
Vous concevez un projet qui existera, au moins en partie, dans le nuage. De nombreuses options s'offrent à vous lorsque vous commencez votre travail. Vous pouvez construire de manière conventionnelle et espérer que l'informatique fonctionnera lorsqu'elle sera téléchargée dans le nuage. Vous pouvez également garder le nuage à l'esprit tout au long du processus de conception, en veillant à ce que les technologies de l'information fonctionnent de manière transparente une fois téléchargées.
Adoptez une approche d'architecture "cloud natif", et chaque choix que vous ferez sera guidé par les systèmes et les ressources qui existent dans le "cloud", et non dans votre centre de données physique. Les projets de ce type nécessitent un changement d'expertise.
Dans un environnement de conception traditionnel, vous connecterez votre base de données à des modules, et ces modules se connecteront à une API ou à une application web avant de pouvoir atteindre les consommateurs.
Mais comme votre entreprise évolue, votre application doit aussi évoluer. Chaque petite modification apportée à un module a un effet d'entraînement sur tous les autres. Bientôt, vous entrez dans ce que les experts appellent uncycle de peur "." Vous ne pouvez pas changer une petite chose sans risquer de casser tout le reste. Avec le temps, l'ensemble du projet devient si compliqué que personne (y compris vous) ne comprend vraiment les technologies de l'information.
Utilisez l'architecture "cloud natif" et votre conception consistera en de nombreux petits éléments qui fonctionnent ensemble. Vous pouvez modifier, ajouter ou remplacer l'un d'entre eux sans risquer de casser l'ensemble du système. Les composants de l'architecture cloud natif sont les suivants :
- Conteneurs
- Infrastructure immuable
- microservice
- Mailles de service
Ces pièces fonctionnent ensemble, mais vous pouvez les modifier indépendamment les unes des autres sans mettre en péril l'ensemble du système. Votre version finale est évolutive, résiliente et disponible pour tous les consommateurs.
En quoi le nuage natif diffère-t-il du nuage activé ?
De nombreuses entreprises développent des systèmes pour des environnements conventionnels et, lorsque les besoins évoluent, les transfèrent dans l'informatique dématérialisée.
Les systèmes en nuage peuvent fonctionner dans un environnement traditionnel et, en théorie, ils peuvent fonctionner dans le nuage. Vous pouvez les pousser à cet endroit et ils serviront les clients pendant un certain temps.
Mais les systèmes de ce type ne sont pas conçus pour l'informatique en nuage. Ils peuvent se briser plus rapidement que ceux construits avec une approche "cloud natif". En outre, ils ne sont pas susceptibles d'offrir les mêmes avantages en termes d'évolutivité, de fiabilité et de sécurité que ceux associés à une approche "cloud natif".
Avantages & Inconvénients de l'architecture natif du nuage
Si vous vous êtes attaqué sans problème à l'architecture traditionnelle d'un système, vous êtes peut-être réticent à l'idée d'apprendre avec une nouvelle approche de développement. Parfois, les risques ne valent tout simplement pas les avantages. Mais souvent, l'architecture natif du nuage s'accompagne d'avantages qu'un projet traditionnel ne peut tout simplement pas offrir.
Les avantages de l'architecture cloud natif sont les suivants
- Faible coût. Construisez dans un environnement standard et vos systèmes doivent toujours être opérationnels pour servir vos clients. Choisissez le nuage, et vous pourrez rediriger votre attention vers de nouvelles À la une et de nouveaux produits.
Comme l'expliquent les analystes, en cas de panne d'un système traditionnel, vous êtes au pied du mur avec vos clients. Choisissez l'informatique dématérialisée et vous pourrez économiser de l'argent et préserver votre réputation grâce à une résilience accrue et à une certaine protection contre les pannes.
- La rapidité. Dans un environnement de travail agile, vous devez toujours tester, bouger et améliorer. C'est difficile à faire si chaque changement que vous apportez risque d'endommager vos systèmes.
Construisez pour l'informatique en nuage et vous créerez un système conçu pour évoluer en permanence. Il est plus facile d'améliorer les applications et de les lancer dans le nuage.
- Options. Une conception "cloud natif" est indépendante de la plateforme. Si vous n'êtes pas satisfait de l'environnement que vous utilisez actuellement, changez les choses rapidement sans reprogrammer de bout en bout.
Les inconvénients de l'architecture natif du nuage sont les suivants :
- Débogage de la demande d'authentification. Repérer un problème dans une architecture de système traditionnelle, c'est suivre un plan linéaire. Dans une conception "cloud natif", les conteneurs interagissent et se connectent. Mais le chemin n'est pas toujours évident. Certains problèmes trouvent leur origine dans un ou plusieurs conteneurs, et il n'est pas toujours facile de trouver le problème.
- La sécurité. S'appuyer sur des opérateurs de cloud tiers revient à céder le contrôle de vos données et de leur accès. Parfois, ces entreprises ne sont pas aussi prudentes avec les données que vous pourriez l'être.
- Lacunes dans les connaissances. Écrire dans un nuage natif, c'est un peu comme apprendre une nouvelle langue. Vous devez maîtriser les concepts et perfectionner votre approche, et une petite erreur peut entraîner un problème catastrophique.
Chaque entreprise doit peser soigneusement le pour et le contre et prendre la décision qui convient à l'entreprise, aux consommateurs et à la partie prenante. Organisez des discussions de planification dès le début et assurez-vous que l'ensemble de l'équipe comprend l'approche avant le début de la construction.
Architecture de l'infrastructure cloud natif
Dans un environnement natif du nuage, de petits composants fonctionnent ensemble pour former un système plus vaste. Chaque pièce a une tâche spécifique à accomplir, et toutes fonctionnent sur le cloud. Mais vous pouvez mettre en place chaque élément individuellement plutôt que d'essayer de créer un système complet du début à la fin.
Toutes les conceptions de nuages natifs fonctionnent de la sorte. Mais plusieurs options s'offrent à vous pour concevoir le système qui convient le mieux à votre entreprise. Les options les plus courantes sont les suivantes :
- De base. Votre DNS se branche sur l'un des deux équilibreurs de charge, qui se connectent aux applications. Une base de données principale et une base de données secondaire contiennent des données clés et communiquent avec vos applications. Et l'ensemble du système est sauvegardé périodiquement dans le nuage.
- multicloud. Votre DNS peut se connecter à plusieurs plateformes en nuage via un seul composant d'application. Vous n'avez pas besoin de dupliquer les systèmes pour chaque lanceur. L'application peut fonctionner dans les deux environnements et les données sont renvoyées à votre plate-forme dans le bâtiment.
- Hybride. Votre DNS se connecte à l'un des deux équilibreurs de charge, qui communiquent ensuite avec les applications. Ces applications alimentent une base de données principale, tandis que la réplication de ces données alimente une base de données esclave sur un autre nuage ou dans votre bâtiment. Les sauvegardes instantanées permettent de garder l'ordre.
Utilisez des diagrammes et des tableaux pour aider votre équipe à comprendre à quoi ressemblera le projet une fois terminé. N'oubliez pas que les nuages d'applications sont faciles à modifier. Si un système que vous avez conçu ne sert pas votre entreprise, vous pouvez vous débarrasser de l'informatique et repartir à zéro.
Mais n'oubliez pas que les microservices sont essentiels à l'environnement en nuage. Chaque petit morceau qui fait quelque chose de différent s'attaque à une partie différente du travail. Ils travaillent indépendamment les uns des autres, mais ils sont reliés entre eux pour assurer le fonctionnement du système. Ne construisez jamais quelque chose pour l'informatique en nuage qui ne contienne pas ces éléments plus petits.
Principes de l'architecture cloud natif
Certains architectes de l'information pensent qu'ils apprennent mieux en faisant. Ils préfèrent coder et creuser les données plutôt que de lire et d'écouter. Mais il est utile de connaître les principes de ce type d'architecture, afin de savoir à quoi les experts adhèrent lorsqu'ils conçoivent ces systèmes.
Les principes communs de l'architecture natif du nuage sont les suivants
- La résilience passe avant tout. La redondance, les déploiements régionaux et la réplication des données permettent de garantir que le système reste en ligne. Dans un tel système, les défaillances sont inévitables. Les architectes doivent planifier l'informatique.
- Le système est composé d'éléments. Les architectes utilisent des conteneurs pour diviser les applications en petits morceaux qui font le travail ensemble.
- L'automatisation est importante. pour l'informatique en nuage, et vous pouvez utiliser des outils en ligne pour réduire la charge de travail et le fardeau informatique. L'automatisation est un principe clé de la construction pour l'informatique dématérialisée.
- La latence joue un rôle. De minuscules délais entre la demande d'un utilisateur et l'action du système font partie de tout système natif de l'informatique en nuage. Les architectes doivent déterminer comment réduire au maximum cette taille.
- Les sauvegardes assurent la sécurité des données. Les systèmes sont construits en parallèle, de sorte que rien n'est perdu en cas de panne ou de défaillance du système en nuage.
- La transparence fait partie de la conception du système. Les conteneurs peuvent être construits comme des boîtes noires. Mais il est important que chacun d'entre eux ait un certain niveau de pénétrabilité, afin que vous puissiez les observer et vous assurer qu'ils fonctionnent bien. Cette transparence permet également des mises à jour automatisées.
De nombreuses équipes de codage rédigent des blogs et des manuels sur la manière dont elles gèrent les architectures natives du cloud. Leur lecture peut vous donner une idée de ce que font les autres pour répondre à la même demande d'authentification que vous.
Nous pouvons vous aider
De nombreuses organisations techniques de premier plan utilisent l'architecture cloud natif pour livrer des logiciels rapidement et en toute sécurité. La capacité d'agir rapidement et de répondre aux commentaires des clients est inestimable pour les petites entreprises comme pour les grandes.
Mais certains fournisseurs de solutions en nuage ne tiennent pas les promesses de ce type d'architecture. Nous prenons vos besoins à cœur et nous avons mis en place des systèmes qui respectent les bonnes pratiques et qui fonctionnent bien. Nous serions ravis de discuter avec vous.
Références
Charte de la Cloud Computing Foundation. (Décembre 2018). La Fondation Linux.
Introduction aux applications natives du cloud. (Mai 2020). Microsoft.
3 raisons d'opter pour le cloud natif. (août 2018), Le Wall Street Journal.
Développement d'applications basées sur le nuage ou natives du nuage : Une distinction importante. (Septembre 2018). Magazine Digitalist.
5 principes pour l'architecture cloud natif : Ce qu'est l'informatique et comment la maîtriser. (juin 2019). Google.
Architecture de l'application cloud natif. (février 2019). Medium.
Comment architecturer et concevoir des applications natives du cloud. (décembre 2015). Gartner.
nuage natif Principes. IBM.