Technologies Azure pour le processus de création

Effectué

Dans cette unité, vous découvrez la relation entre le processus d’innovation et quelques-unes des technologies du secteur qui peuvent vous aider à créer de nouvelles fonctionnalités dans les applications.

DevOps

Une fois que vous avez démarré la phase de création pour valider votre hypothèse d’innovation, les cycles de développement, d’intégration et de déploiement nécessaires doivent être aussi fluides que possible. Cette phase est là où intervient DevOps. Les DevOps peuvent être définis comme des « processus et outils visant à fournir rapidement des fonctionnalités logicielles fiables ». Voici les détails de cette définition :

• Processus et outils : DevOps, tout comme le processus d’innovation dans son ensemble, est basé sur des modèles de culture encourageant le changement. Azure et GitHub offrent d’excellents outils autour de DevOps, mais l’achat d’une licence ne suffit pas. Vos processus et la culture de votre organisation doivent évoluer pour adopter le changement et l’innovation.

• Délivrer rapidement des fonctionnalités logicielles : les processus et les outils DevOps adhèrent au concept de Fail-fast. Créer des produits minimum viables ou des prototypes pour valider rapidement le fait que la fonctionnalité en cours d’élaboration va ou non dans la bonne direction est au cœur du concept de DevOps.

• Production fiable de fonctionnalités logicielles : les organisations rétives au changement associent souvent changements rapides et temps d’indisponibilité. Cependant, DevOps promet exactement l’inverse : un rythme de changement rapide et un haut niveau de fiabilité. Cette fiabilité est rendue possible en intégrant les tests dans les premières étapes du cycle de développement, dans un processus appelé « décalage vers la gauche ».

  Si le développement d’une fonctionnalité dans le temps est vu comme une ligne allant de gauche à droite. Ensuite, un processus de développement hérité effectuerait la validation utilisateur et le contrôle de qualité à la fin du cycle de développement. À l’extrémité « droite » de cette ligne. DevOps vous conseille de tester et de valider le plus tôt possible, à la « gauche » de cette ligne chronologique.

DevOps intègre les mêmes concepts de base d’une culture de l’innovation saine. L’adoption de sa méthodologie est essentielle pour accéder à un cycle d’innovation agile.

Architectures de microservices

La modularité est une technique bien connue pour réduire la complexité de l’architecture des systèmes complexes. Si un système est une interaction complexe de nombreux composants qui ne peuvent pas être séparés les uns des autres (on parle dans ce cas souvent de « monolithe »), les interdépendances fortes des composants rendent difficiles les améliorations du système. Chaque modification doit être validée avec le reste du système, de sorte que le processus de test est complexe.

Si le système est modulaire, vous pouvez le diviser en sous-systèmes plus petits qui interagissent entre eux via des interfaces bien définies. Il est plus facile d’introduire des modifications dans un de ces sous-systèmes, car tant que son interface avec les autres modules reste constante, l’ensemble du système continue de fonctionner.

Les architectures de microservices sont des modèles d’application qui exploitent la modularité. Les applications sont subdivisées en petits composants distincts qui peuvent être développés indépendamment les uns des autres, même si vous utilisez des langages de programmation différents. Chaque composant, ou microservice, peut fonctionner de manière autonome. Vous pouvez le mettre à l’échelle si nécessaire, vous pouvez le résoudre en tant qu’unité unique, vous pouvez le modifier indépendamment des autres microservices.

Une question que les organisations se posent souvent est ce qu’il faut faire si une application est monolithique. L’organisation doit-elle reconcevoir l’application en une architecture de microservices avant d’introduire de l’innovation, ou bien les processus d’innovation et de reconception peuvent-ils être effectués en parallèle ? Il n’y a pas de réponse unique à cette question. Cela dépend de la complexité et de la pertinence pour l’entreprise de l’application considérée.

Tailwind Traders est confrontée à cette question quand elle cherche à introduire de l’innovation dans sa plateforme d’e-commerce. La société a décidé de démarrer un projet pour reconcevoir l’application d’e-commerce en une architecture de microservices, car le caractère critique pour l’entreprise de l’application justifie cet effort. Le fait de ne pas avoir une application modulaire risque de nuire à la capacité de Tailwind Traders à réagir aux tendances en évolution du marché en ligne.

Cependant, Tailwind Traders a pris la décision de s’attaquer en même temps à certaines des principales lacunes de sa plateforme. Attendre que le projet de reconception de l’application soit terminé signifierait perdre des parts de marché importantes au profit de nouvelles startups qui révolutionnent actuellement le marché de l’e-commerce.

Les projets doivent interagir les uns avec les autres, guidés par la valeur métier des innovations. Les efforts de reconception vont se focaliser sur les domaines les plus critiques de l’application, où la nécessité de modifications pour améliorer l’expérience utilisateur est la plus forte.

Conteneurs

La technologie de conteneurisation n’est pas exclusivement réservée aux architectures de microservices, mais les deux concepts fonctionnent ensemble. Les conteneurs sont un moyen d’encapsuler le code de l’application et ses dépendances, afin d’en permettre le déploiement facile sur n’importe quelle plateforme.

Les déploiements d’applications traditionnels nécessitent que l’organisation installe d’abord le logiciel, comme le runtime de l’application, des bibliothèques de programmation ou des composants externes. Cette approche aboutit souvent au problème « ça fonctionne sur ma machine » : il est difficile de répliquer le même environnement dans les phases de développement, de test, de préproduction et de production. De petites différences dans la façon dont les dépendances de l’application sont installées peuvent faire que l’application fonctionne correctement lors des tests, mais connaît des échecs quand elle est déployée en production.

Les conteneurs changent les règles du jeu. Les dépendances d’une application sont empaquetées avec le code de l’application dans une unité de déploiement autonome, appelée image conteneur. Si le conteneur d’application est déployé sur l’ordinateur portable d’un développeur ou dans un cluster de production avec des centaines de nœuds, la gestion des dépendances est exactement la même. Le conteneur fonctionne exactement de la même façon : les tests des applications sont donc plus fiables.

Les conteneurs ont beaucoup évolué depuis que Docker a publié leur code en open source en 2013. Les conteneurs prennent désormais en charge Linux et Windows ainsi que différentes architectures de processeur. Dans Azure, il existe de nombreuses offres qui permettent d’exécuter des charges de travail basées sur des conteneurs. Dans cette unité, vous découvrez certains d’entre eux.

Kubernetes et Red Hat OpenShift

Un runtime de conteneur est la technologie qui démarre les conteneurs sur un ordinateur, mais un environnement de production nécessite davantage de logique. Qui déploie plus de conteneurs si des performances plus élevées sont nécessaires ? Qui redémarre les conteneurs s’ils rencontrent des problèmes ? Si plusieurs ordinateurs sont disponibles, qui décide de celui sur lequel un certain conteneur doit être démarré ? Ces tâches parmi d’autres sont de la responsabilité d’une plateforme d’orchestration de conteneurs.

La première version de Kubernetes a été publiée en 2015 et il est devenu rapidement le standard de facto pour l’orchestration de conteneurs. Les clusters Kubernetes sont constitués de plusieurs nœuds worker. Chaque nœud Worker a un runtime de conteneur, de sorte qu’il peut exécuter des conteneurs où le plan de contrôle de Kubernetes planifie le déploiement d’applications conteneurisées. Ce plan de contrôle s’exécute généralement dans un ensemble de nœuds principaux. Il est responsable du fonctionnement correct de l’application, du scale-up ou du scale-down de l’application, et de réalisation des mises à jour nécessaires.

Une des principales raisons de la popularité de Kubernetes est l’indépendance vis-à-vis du matériel offerte par les conteneurs. Comme les applications basées sur des conteneurs peuvent être déployées de façon fiable sur n’importe quel runtime de conteneur, vous pouvez exécuter Kubernetes dans des clouds qui utilisent différents hyperviseurs. Les applications déployées doivent se comporter de façon similaire (en supposant que les ressources matérielles sous-jacentes sont également similaires). De nombreuses organisations ont adopté Kubernetes comme couche d’abstraction qui permet des processus cohérents de déploiement d’applications localement et dans des clouds publics.

Exécuter Kubernetes dans Azure est facile. Azure Kubernetes Service est simple à déployer et économique, car seul le coût des nœuds Worker est facturé au client. Microsoft prend en charge le coût et le fonctionnement du plan de contrôle qui contient les composants principaux. Microsoft applique les correctifs et met à jour le système d’exploitation des nœuds Worker, ce qui réduit encore davantage la complexité opérationnelle de la gestion d’un cluster Kubernetes pour exécuter des conteneurs Linux et Windows.

OpenShift est une plateforme de déploiement d’applications basée sur Kubernetes, développée et supportée par Red Hat. Elle intègre de nombreuses autres fonctionnalités. Certaines des organisations qui choisissent d’exécuter leurs applications sur OpenShift le font en raison de ces fonctionnalités supplémentaires et du support fourni par Red Hat. L’exécution d’OpenShift sur Azure est également simple. Azure Red Hat OpenShift est constitué d’un cluster OpenShift dont Microsoft gère un grand nombre des aspects, y compris l’intégralité du cycle de vie du cluster.

Azure App Service

Azure App Service est une plateforme où les organisations peuvent exécuter leurs charges de travail web sans devoir gérer un orchestrateur ou un système d’exploitation sous-jacent. La seule exigence est le chargement du code d’application dans le service via une des nombreuses méthodes de déploiement disponibles. Azure effectue le reste : scale-in et scale-out de l’application, mise à jour corrective et maintenance des machines virtuelles sous-jacentes, etc., ce qui vous évite de passer par la courbe d’apprentissage de Kubernetes.

Azure App Service prend en charge les charges de travail basées sur les conteneurs : vous pouvez donc charger votre image conteneur au lieu du code de l’application. Il prend aussi en charge les charges de travail Linux et Windows ainsi que de nombreux runtimes d’application différents.

Azure App Service prend en charge différents modèles de tarification, notamment une option serverless appelée Azure Functions. Dans Azure Functions, seule l’utilisation de l’application est facturée. Il n’y a pas de coûts fixes.

Le modèle serverless est intéressant pour l’innovation, car il vous permet de déployer de nouveaux microservices sans avoir à payer des factures mensuelles élevées au cas où ils ne sont pas acceptés par le marché. Ce modèle est un autre exemple de la stratégie Fail-fast, où l’innovation ne signifie pas nécessairement des dépenses importantes.

Azure App Service offre également des fonctionnalités qui prennent en charge les déploiements orientés DevOps, comme les emplacements d’application web. Les emplacements sont des zones de préproduction où vous pouvez déployer de nouvelles fonctionnalités sans affecter l’environnement de production. Ces essais à une échelle réduite sont très bien du point de vue de l’innovation, car vous pouvez rediriger une petite sélection de vos clients vers cette nouvelle version de l’application. Ensuite, vous pouvez vérifier si votre hypothèse d’innovation est correcte. Enfin, si vous voulez promouvoir le nouveau code en production, vous pouvez « permuter » des emplacements de façon que l’environnement de préproduction devienne la version de production.

Résumé

Dans cette unité, vous avez découvert comment la technologie peut venir en support de l’innovation :

• Les processus et les outils DevOps donnent à vos équipes de développement et d’exploitation un potentiel accru pour délivrer de nouvelles fonctionnalités de façon rapide et fiable.
• Vous pouvez réarchitecturer les applications en microservices pour permettre l’innovation sur leurs composants individuels, sans affecter le reste.
• Les conteneurs permettent le déploiement fiable des applications sur plusieurs plateformes et environnements.
• Kubernetes est une plateforme d’orchestration indépendante des clouds pour exécuter des applications conteneurisées.
• Azure App Service peut exécuter des charges de travail web avec une charge de gestion minimale. Il offre de nombreuses fonctionnalités, comme le serverless ou les emplacements d’application, pour accélérer le cycle de l’innovation.

Tailwind Traders a décidé de démarrer la reconception de son application d’e-commerce en une architecture de microservices. Le premier sous-système de l’application qu’ils séparent du « monolithe » est le service de paiement, car il a été identifié comme étant un point critique où la concurrence offre une meilleure valeur ajoutée aux clients.

Après le sous-système de paiement, d’autres composants d’application seront convertis en microservices indépendants. Les microservices peuvent communiquer via des API REST. Le code d’application pour chaque microservice est destiné à être conteneurisé, et les organisations de développement et d’exploitation vont adopter les bonnes pratiques de DevOps.

Comme Tailwind Traders ne veut pas dépendre d’un cloud public spécifique, ils ont décidé d’acquérir en interne une expertise de Kubernetes et de déployer l’application sur des clusters Azure Kubernetes Service. Si de nouveaux microservices doivent être développés, l’entreprise envisage d’utiliser Azure Functions comme plateforme pour le déploiement des produits minimum viables afin de réduire les coûts de développement.

Que consulter ensuite ?

Un grand nombre des concepts exposés dans cette unité sont décrits plus en détails dans les articles du Cloud Adoption Framework Favoriser l’adoption avec l’invention numérique et Kubernetes dans le Cloud Adoption Framework.