Codage Azure 1: Création d’applications de cloud-Native

Si vous constatez que la documentation et la formation sur la création d’une application Azure native du cloud ne vous donne pas l’aide dont vous avez besoin, le codage d’Azure a l’intention de résoudre ce problème.

Voici à quoi cette série les articles de blog concerne: toutes les étapes pour créer une application de cloud-native fonctionnelle, impliquant toutes les ressources nécessaires – de la configuration des ressources en les sécurisant et en écrivant le code nécessaire pour les utiliser. Cette série vous montrera comment procéder, en utilisant à la fois Visual Studio et Visual Studio Code et avec un seul exemple d’application comme étude de cas.

Ce qui soulève la question: pourquoi est-ce nécessaire?

La raison commerciale

Pour moi, le conducteur pour aller aux applications natifs du cloud est d’éviter de passer mon temps sur des choses qui n’améliorent pas mes clients (ou organisation). Je ne suggérerais jamais, par exemple, à mes clients que la construction de leur propre système de comptes payables est une bonne idée (en fait, j’essaierais activement de les en parler). Sauf s’il est présenté avec un moyen convaincant qu’un système AP personnalisé améliorera votre organisation, vous devriez faire AP comme tout le monde, ce qui signifie que vous devriez acheter, pas construire, votre système AP (généralement, le terme technique pour faire des comptes à payer différemment de Tout le monde est «fraude»).

Pour moi, cette même philosophie s’étend à la gestion des parties standard de votre infrastructure d’application: moteurs de base de données, stockage, gestion des serveurs, etc. En d’autres termes, toutes les choses qu’Azure vous donne.

Il y a cependant deux problèmes avec cette philosophie: d’abord, sur la base de mon expérience en tant que développeur, la création d’applications natives dans le cloud avec Microsoft Azure Resources est… difficile. Deuxièmement: Bien que vous n’ayez pas à gérer ces ressources, pour les utiliser, vous devez toujours en savoir pas mal de choses et, surtout, des choses que vous ne connaissiez pas auparavant.

L’esprit du SOLIDE Les principes sont que nous construisons des programmes complexes à partir de composants simples. Étendue au niveau d’application, cela signifie que nous construisons des systèmes compliqués à partir d’applications plus simples: les microservices. Bien qu’il existe de nombreuses définitions du microservice, les deux qui comptent pour moi est que a) un microservice est suffisamment petit pour que l’équipe qui le prend en charge puisse le comprendre et b) que les connaissances peuvent être transmises à tout nouvel ajout à l’équipe en un seul sprint.

La raison de la connaissance

Et, comme cette série va le démontrer, même une application Azure minimale native du cloud nécessite que l’équipe – ou «vous» – soit familiarisée avec plusieurs ressources Azure (services d’applications, bases de données SQL Azure, clés et plus encore). Si vous allez au-delà d’une application «minimale» pour créer une application plus fiable, évolutive, extensible et maintenable, vous devrez vous familiariser avec encore plus de ressources Azure (files d’attente et événements, par exemple).

Cela signifie non seulement savoir comment utiliser ces ressources judicieusement et comment les configurer / les configurer, mais aussi comment accéder à ces ressources à partir du code, comment écrire le code requis qui vit à l’intérieur de ces ressources et comment déployer ce code dans ceux Ressources pendant le développement à l’aide de l’ensemble d’outils typique de «Microsoft Developer» (Visual Studio et Visual Studio Code).

Mais attendez, il y a plus: vous devez être également intéressé par la meilleure façon de sécuriser votre partie de l’application. Bien que vous n’ayez peut-être pas la surveillance de la façon dont les ressources de l’application sont gérées après sa construction, vous pouvez faire votre part pour fermer autant d’opportunités que possible pour une violation de sécurité que vous créez l’application.

Mon objectif

Il est important pour moi que cette série vous aide à comprendre à la fois quoi et le pourquoi de toutes ces activités.

Pour faciliter cette compréhension, dans ces articles, je vais m’appuyer sur les différentes GUIS à votre disposition en favorisant le portail Azure sur la CLI ou le PowerShell Azure. Je n’ai rien contre les CLI pour scripter les tâches répétitives, mais elles ont tendance à obscurcir ce qui se passe. L’interaction avec les GUIS (à mon avis) favorise la compréhension de ce que vous faites exactement (et vous guider à travers ces GUIS me donne l’occasion d’expliquer les options qui vous sont disponibles).

Comprendre les options disponibles est important car, quand vient le temps pour vous d’effectuer ces tâches, vous ne ferez pas exactement Ce que mon application d’étude de cas nécessite – vous devrez modifier mes solutions pour répondre à vos besoins. Donc, pour soutenir la compréhension, je vais également éviter d’utiliser des services publics qui prennent en charge plusieurs étapes pour vous. Ces services publics sont terriblement utiles pour implémenter la solution typique, mais si vous devez faire quelque chose qui n’est pas l’implémentation typique – eh bien, vous devez comprendre ce qui se passe.

L’application d’échantillon

À propos de mon exemple d’application: je suis un développeur d’applications commerciales et les applications commerciales consistent à récupérer et à mettre à jour les données. En conséquence, mon article suivant Va configurer une base de données SQL Azure (c’est l’un des articles de cette série qui sera entièrement en configuration).

Après ce post, je vais utiliser Visual Studio pour créer une application API Web C # côté serveur en utilisant des API minimales pour récupérer les données de ma base de données. Je vais également configurer un service Azure Web App / APP et déployer ce service Web.

Une fois que ce service Web fonctionne, je vais le faire accéder à la base de données et configurer le service et la base de données afin que la seule application qui puisse accéder à la base de données soit mon service Web.

Après cela, je vais créer dans Visual Studio Code à la fois les applications côté client et côté serveur qui accédent à mon service Web et déployez ces applications dans une autre application d’application / Web. Une fois que cela fonctionne, je configurerai mon service Web afin que la seule chose qui puisse en parler sera mon frontend (et je configurerai cette application afin qu’elle ne puisse accéder qu’aux utilisateurs autorisés).

Après ces premiers articles, vous aurez tout ce dont vous avez besoin pour créer une application sécurisée à trois niveaux et pouvoir déployer votre code à partir de Visual Studio ou Visual Studio Code. En cours de route, je vais examiner certains des outils dont vous aurez besoin pour déboguer votre code, implémenter l’exploitation forestière, redéployer les ressources Azure et toutes les autres tâches de développement typiques qui surgissent.

Résumer et les prochaines étapes

Cette série est destinée à être tout ce qu’un membre de l’équipe devrait savoir pour prendre en charge un microservice minimal (à l’exception de la logique spécifique à une application – ce sera à vous).

Après cela, je vais montrer comment (pas nécessairement dans cet ordre):

• Utilisez Azure Key Vault pour contenir des secrets et des certificats (et accédez à ces ressources à partir de votre demande)
• Utilisez des fonctions Azure à la place d’un service Web hébergé dans un service d’application
• Comment tirer parti de l’API Web pour unifier, simplifier et documenter vos services Web
• Intégrer un traitement basé sur la file d’attente pour créer des applications fiables, évolutives et extensibles
• Remplacez ce traitement basé sur la file d’attente par la grille d’événements Azure pour passer à une conception publiée / abonnée, axée sur l’événement

Tous ces composants fonctionneront dans mon locataire Azure, et leur accès sera restreint (à une exception) à des clients spécifiques, également dans mon locataire Azure. Même alors, ces clients autorisés seront limités, en mesure d’effectuer des activités autorisées spécifiques sur les composants auxquels ils peuvent accéder. La seule exception à cela est le frontend de mon application, accessible par des utilisateurs autorisés qui, vraisemblablement, vivent en dehors d’Azure.

Si vous sentez que j’ai manqué un sujet dont une équipe aurait besoin, envoyez-moi un courriel (Peter.vogel@phvis.com) ou mettez une note dans les commentaires.

Et, avec tout cela à l’écart, voici le lien vers ce prochain article sur la configuration d’un Base de données Azure SQL.