Cloud et développeurs: Acte 2download.microsoft.com/documents/France/visual_studio/...monitoring,...
82
Cloud et Développeurs Acte 2
Transcript of Cloud et développeurs: Acte 2download.microsoft.com/documents/France/visual_studio/...monitoring,...
Cloud et
Développeurs
Acte 2
1
Publication : 9 février 2015
Auteurs :
François TONIC
Stéphane GOUDEAU
2
Sommaire
Avertissement .................................................................................................. 5
Introduction ..................................................................................................... 6
Aux sources du DevOps et son ADN ............................................................ 9
I. DevOps : du constat à la définition .................................................. 9
II. DevOps : c’est aussi une question d’ADN ..................................... 11
III. L’économie des apps et des services impose le DevOps ........ 13
Continuous Delivery & DevOps ................................................................... 15
I. Le processus de Continuous Delivery ............................................. 15
II. En quoi consiste la démarche DevOps .......................................... 16
1. La culture DevOps ....................................................................... 16
2. DevOps : Perspective technologique ....................................... 17
3. Les outils DevOps ......................................................................... 18
Concevoir une application Cloud ............................................................. 20
I. Bâtir une architecture pour le Cloud .............................................. 20
1. Les services IaaS et PaaS de Microsoft Azure .......................... 20
2. Cloud Hybride .............................................................................. 21
3. Réversibilité du Cloud .................................................................. 21
4. L’évolution des services de Microsoft Azure ............................ 22
5. Vers une fusion IaaS – PaaS ? ..................................................... 24
6. Architecture blueprints ................................................................ 26
7. Cloud Design Patterns ................................................................. 27
8. Architecture Failsafe ................................................................... 29
II. Développement de sites Web ......................................................... 31
III. Développement de traitements de type « batch » ................... 33
IV. Développement de backend pour sites et apps mobiles ........ 34
V. Développement IoT (« Internet Of Things ») ................................... 35
3
1. Les prérequis d’une infrastructure IoT........................................ 35
2. L’ingestion des données ............................................................. 36
3. La transformation des données ................................................. 36
VI. L’impact pour le développeur ..................................................... 40
VII. La proposition de valeur du développement dans le Cloud ... 41
Développer une application Cloud en Continuous Delivery ................. 43
I. Introduction ........................................................................................ 43
II. Démarche agile................................................................................. 43
III. Structure organisationnelle et planification des actions ........... 44
1. Structure organisationnelle ......................................................... 44
2. Les projets ..................................................................................... 45
3. Les équipes projets ...................................................................... 45
4. Planification des actions ............................................................. 47
IV. Réduction des cycles de livraison ................................................ 48
1. Le contrôle de code source ...................................................... 48
2. Test automatisés ........................................................................... 49
3. Intégration continue .................................................................... 51
4. Automatisation des environnements ........................................ 53
5. Stratégie de branching ............................................................... 62
6. Pipeline de déploiement ............................................................ 62
7. Release Management ................................................................ 63
V. Optimisation des ressources ............................................................. 65
VI. Amélioration de la qualité et de la disponibilité ........................ 67
1. Haute disponibilité du réseau .................................................... 67
2. Haute disponibilité des données ............................................... 68
3. Services de supervision ............................................................... 68
4. Load testing .................................................................................. 70
VII. Continuous learning ....................................................................... 72
4
1. Hypothesis-driven development ................................................ 72
2. Supervision des usages via télémétrie ...................................... 74
VIII. Chaîne de production logicielle « Microsoft » ............................ 77
Conclusion ..................................................................................................... 78
Références techniques ................................................................................ 80
5
Avertissement
Ce document s’adresse aux architectes, aux développeurs, aux chefs
de projet, ainsi qu’aux responsables d’infrastructure qui souhaitent avoir
une vision plus complète sur les objectifs et les moyens liés à la mise en
œuvre d’une démarche DevOps dans Azure.
Ce document est fourni uniquement à titre indicatif. MICROSOFT
N’APPORTE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, À CE
DOCUMENT. Les informations figurant dans ce document, notamment
les URL et les références aux sites Internet, peuvent être modifiées sans
préavis. Les risques d’utiliser ce document ou ses résultats sont
entièrement à la charge de l’utilisateur. Sauf indication contraire, les
sociétés, les entreprises, les produits, les noms de domaine, les adresses
électroniques, les logos, les personnes, les lieux et les événements utilisés
dans ce document sont fictifs. Toute ressemblance avec des
entreprises, noms d’entreprise, produits, noms de domaine, adresses
électroniques, logos, personnes ou événements réels serait purement
fortuite et involontaire.
6
Introduction
Depuis la première édition de ce livre banc, « Cloud et développeurs »,
en février 2014, les services Cloud existants ont fait l’objet de
nombreuses améliorations et extensions, et de nouveaux modèles ont
émergé ou se sont confirmés. Le Cloud connaît depuis quelques mois
des mutations très fortes.
Nous pouvons en citer trois :
Le Cloud devient de plus en plus hybride que ce soit entre le on-
premise et le Cloud ou entre le IaaS et PaaS (on parle d’ailleurs
plutôt de solution Cloud « mixte IaaS-Paas »)
Une fusion, ou tout le moins, une imbrication de plus en plus étroite
entre le IaaS et le Paas : comme nous le verrons plus loin dans cet
acte 2, la frontière stricto sensu entre la plateforme et
l’infrastructure tend à devenir plus floue, voire, à disparaître.
Enfin, l’arrivée des conteneurs (ou micro-VM) : certes ce n’est pas
une nouveauté, car le principe du conteneur existe depuis de
nombreuses années, mais depuis l’émergence de Docker, les
choses évoluent très rapidement avec une forte poussée des
principaux fournisseurs d’infrastructures IaaS. Citons (liste non
exhaustive) : Google, Microsoft, VMWare, Red Hat, et tout
récemment Amazon. Le conteneur marque la porosité entre IaaS
et PaaS et permet une automatisation des déploiements de
workloads difficilement réalisable jusqu’à présent.
Les choses évoluent aussi sur les applications, les modèles de
développement et les pratiques des développeurs. Là encore, nous
pouvons nous appuyer sur plusieurs tendances. Les leaders du logiciel
misent sur le Cloud et passent en mode Cloud leur catalogue applicatif.
Parfois, pour les éditeurs non « pure players » du Cloud, on voit
apparaître l’idée de « Cloud First », c’est à dire, « pensé en premier pour
(et par) le Cloud ».
Autre évolution, le « Cloud by Design », ou comment le Cloud
(entendons par là principalement, les ressources IaaS et PaaS) s’impose
comme un élément incontournable des applications :
7
Les applications, qu’elles soient ou non mobiles, sont dotées d’un
back-end Cloud, que ce soit pour le stockage ou pour certains
traitements (ex. : les traitements 3D comme l’illustre le projet Open
Source Azure Batch. Blender).
Il est possible de concevoir des nouveaux services et logiciels 100
% Cloud, ou de n’utiliser le Cloud que pour bénéficier de ses
capacités supplémentaires afin de traiter des scénarios de type
« bursting ».
Il devient chaque jour plus facile de migrer sur le Cloud (par
exemple, avec des mécanismes de type Remote App).
Avec l’Internet des Objet (IoT), le Cloud est devenu l’ami
inséparable des objets connectés, notamment pour stocker et
traiter la masse de données provenant de ces objets.
Enfin, avec le Big Data, il s’agit non seulement du stockage, mais
également des traitements de type MapReduce qu’offrent des
solutions comme Hadoop.
Bien entendu, nous en parlions déjà dans le précédent livre blanc, le
développeur bénéficie également de la valeur ajoutée du Cloud. De
nombreux services peuvent l’aider dans son quotidien : gestion de
code, gestion de projet, intégration et déploiement continus,
monitoring, plateforme de tests, etc.
Et naturellement, DevOps n’est pas oublié : DevOps est naturellement
Cloud et de nombreuses pratiques peuvent être Cloud. Nous le verrons
en détail.
Le développeur se doit d’avoir une connaissance du Cloud. L’utilisation
du Cloud ira croissant dans les prochains mois et les prochaines années,
même si le 100 % ne se fera pas partout : il sera toujours nécessaire
d’accéder à des ressources locales et pas uniquement pour supporter
un l’existant ou pérenniser un patrimoine informatique. Le Cloud modifie
les pratiques, les modèles de développement et la manière de
concevoir les architectures. Mais cela, vous le saviez déjà.
Pour cet Acte 2, nous avons voulu reprendre les fondamentaux du
DevOps, ce n’est jamais inutile. Nous appuierons notre propos sur les
principes du processus de Continuous Delivery. C’est à dire, la nécessité
d’être dans une démarche continue de livraison des projets dans un
8
mode de développement sur des cycles très réduits. Vous verrez que
l’impact sur la disponibilité des applications et des services est très positif
si la démarche DevOps est bien menée.
DevOps ne sera pas l’unique thème abordé car le Cloud impacte
profondément le développeur et bien entendu les modèles de
développement. Le Cloud est multiforme et ses champs d’application
semblent sans limite : il suffit de constater la passion qui se manifeste, à
tort ou à raison, autour de Docker ou son utilisation dans les scénarios
de mobilité ou d’interaction avec des objets connectés….
Bonne lecture.
9
Aux sources du DevOps et son ADN
DevOps n’apparaît par hasard. Il est le résultat d’une réflexion et de
constats sur les mécanismes de développements, de déploiement et
d’administration (la partie production / opérationnelle).
I. DevOps : du constat à la définition
DevOps est un terme inventé par Patrick Desbois en 2009. Comme il le
dit lui-même : « There never was a grand plan about thinking about
DevOps as a word, I was busy working on a project which had agile
development and I was so envying these people about their
methodology and I like to do something similar in my world system
administration, so I called it initially agile system administration, but it’s
pretty long. I just picked the word DevOps as Dev and Ops working
together because agile system administration was also too narrow on
focusing on sysadmins only. ».
DevOps (Développeur / Opérationnel) peut être vu comme un pont
entre le développeur, le déploiement, les administrateurs, bref entre la
technique et la production.
La démarche DevOps est donc issue d’un constat : celui des
conséquences négatives issues de la séparation des développeurs et
des responsables opérationnels d’une organisation.
10
Parmi les obstacles fréquemment rencontrés, citons :
• La rigidité des processus liés aux transitions entre les différentes
étapes du cycle de vie logiciel.
L’absence de coordination dans la gestion des releases :
o Processus ad hoc, souvent non outillés, conduisant à un
manque de visibilité sur le statut de la release
o Insuffisance de la documentation et des artefacts de
configuration et déploiement
• L’inefficacité des outils de collaboration :
o Manque d’outils offrant des boucles de rétroaction continue
avec les utilisateurs
o Manque d’intégration entre les outils utilisés pour gérer les
charges de travail développement et opérations)
La durée trop élevée des cycles de déploiement (insuffisance de
l’automatisation de certaines opérations qui conduit à des échecs
en production)
Les différences entre environnements de production et
environnements de développement complexifiant le diagnostic et
la résolution des incidents de production
L’absence de traçabilité entre le code source et le déploiement
en production correspondant
11
La nécessité de disposer de données et des configurations de
production pour reproduire les conditions d’erreurs sur les
plateformes de tests.
L’ensemble de ces problématiques s’inscrivent dans un « Wall of
Confusion » (formule d’Andrew Clay Shafer) entre développeurs et
responsables opérationnels au sein d’une organisation.
Souvent, les développeurs se concentrent sur la réponse aux exigences
fonctionnelles par la production d’un livrable, mais pas sur la
maintenance de la solution en fonctionnement opérationnel. De leur
côté, pour limiter les risques de problèmes inattendus, les administrateurs
système tentent d’édicter des règles pour les déploiements qui
s’avèrent être des contraintes architecturales pour le développement
d’applications.
Chaque groupe optimise ce qu’il considère être son périmètre, ce qui
crée des conflits. Le développeur est à l’origine de changements, que
le responsable des opérations souhaite minimiser pour réduire le risque
de dysfonctionnement.
II. DevOps : c’est aussi une question d’ADN
Luke Kanies (Puppet Labs) est le premier à reconnaître la dimension
culturelle de du phénomène DevOps : « DevOps is real, but you can't
get it just by buying a tool ».
De même que pour la mise en œuvre d’une démarche ALM
(Application Lifecyble Management), certaines entreprises peuvent
croire qu’il suffit de déployer des outils dits DevOps (payants ou Open
Source) pour faire du DevOps. Cette approche mêle outils, méthodes,
bonnes pratiques, management et les équipes techniques et
opérationnelles, les notions « d’opérations en continu" (développement,
intégration, déploiement). D’autre part, DevOps n’est pas une entité
monolithique. Si vous le voyez comme un « tout ou rien », vous
échouerez, même chose si vous avez les outils, mais pas les méthodes
12
ou vice et versa. Sans oublier le changement organisationnel des
équipes, mais aussi au niveau de l’entreprise (nous pensons au modèle
économique et à la manière de mettre des services, des apps sur le
marché).
Il faut mener en amont une réflexion sur l’organisation et l’impact du
DevOps sur les départements, les équipes. Il ne faut surtout pas l’imposer
brutalement. Adoptez ce qui peut l’être et évoluer par itération. Les
entreprises ne sont pas toutes égales devant DevOps. Le modèle de
développement continu est l’ADN même de sociétés comme Twitter,
Netflix, Google, Facebook. Ils publient des mises à jour du code en
production, parfois plusieurs fois par jour. Les startups adoptent plus
facilement ce modèle, car elles ne possèdent pas d’historique IT, ni de
patrimoine informatique. Elles peuvent facilement utiliser les
technologies et outils les plus récents. Des entreprises installées, avec
des dizaines de personnes, une pratique IT ayant construite sa
démarche de gestion opérationnelle sur un modèle peu propice à la
collaboration intra-services, auront sans doute plus de difficulté à
basculer vers le DevOps. Ce basculement devra alors être progressif en
définissant des priorités pour cibler les évolutions dont l’impact sera le
plus visible.
Il ne faut surtout pas faire du DevOps pour en faire. Cela n’aurait aucun
sens. DevOps répond à des besoins précis et réels. La démarche doit
être pragmatique et maîtrisée. Il faut aussi l’adhésion des équipes et de
l’organisation de l’entreprise. Vous devez donc : sensibiliser, former,
accompagner. L’accompagnement au changement est une des
étapes les plus délicates à mener. Mais ce constat n’est pas nouveau
dans l’univers IT.
Vous devrez agir sur 3 éléments (en référence à la réflexion de Patrick
Dubois) : les outils, les processus, les gens.
13
III. L’économie des apps et des services impose le DevOps
Durant plus de 20 ans, les développeurs ont participé à des projets
souvent très longs, orchestrés selon des modèles « en cascade » ou de
« cycle en V » permettant de synchroniser les différentes étapes requises
pour la livraison finale de la solution : cahier des charges, spécifications,
conception, développement, validation, production, maintenance. Et
à chaque nouvelle version, ils repartaient dans un nouveau cycle de
développement. De nombreux projets subissaient alors des retards très
significatifs.
Avec le Web, cette situation ne pouvait perdurer car un site de
commerce en ligne indisponible durant plusieurs minutes, c’est non
seulement une perte de chiffre d’affaire mais c’est aussi un impact
préjuciable pour l’image de la société. L’approche « traditionnelle »
était donc inadaptée… Les méthodes agiles (XP, Scrum) ont modifié
l’organisation des projets avec un modèle plus collaboratif et des
itérations plus courtes, complétées par un souci accru de qualité
logicielle (même si ce Graal est loin d’être acquis pour l’ensemble des
projets). L’ALM a été un mouvement d’ensemble même si la complexité
initiale de la combinaison des outils associés n’a pas facilité son usage
au quotidien. Au final, ce sont les géants du Web qui ont bouleversé la
donne : Netflix, Google, Twitter, Facebook, etc en proposant des mises
à jour logicielles en continu.
Avec l’explosion des terminaux mobiles, les apps se sont imposées à
toutes et à tous. Au point de parler d’une « économie des apps ». Tout
le monde veut son application. Et avec la forte concurrence sur le
mobile, il faut déployer les apps toujours plus rapidement, ce qui ne va
sans poser des problèmes de qualité.
Or, pour pouvoir répondre à ces exigences, le DevOps apporte des
réponses sur le développement, le déploiement et la mise en
production. Et contribue à remettre de l’ordre dans la gestion des
projets et tout en apportant de la rigueur aux développements. Le
Cloud est l’autre élément accélérateur de cette « économie des apps »,
comme nous le verrons un peu plus loin. L’utilisation combinée du Cloud
et du DevOps est donc bien l’une des clés pour la mise en place réussie
d’un processus de Continous Delivery.
14
15
Continuous Delivery & DevOps
I. Le processus de Continuous Delivery
Ce processus se fonde sur l’approche de l’ALM (Application LifeCycle
Management) en regroupant de multiples pratiques destinées à
apporter de la valeur en continu. La rationalisation induite par sa mise
en œuvre permet de déployer le plus fréquemment possible de
nouvelles versions d’une application ou d’un service.
Le schéma suivant représente les différentes phases et outils d’un
processus de Continuous Delivery.
Ce processus englobe :
• L’intégration continue qui vise à réduire les efforts d’intégration en
assurant automatiquement la génération, l’assemblage et les tests
des composants de l’application
• Le déploiement continu qui consiste à automatiser le déploiement
du logiciel construit sur la plateforme cible (test, intégration, pré-
production voire production) à chaque nouvelle génération de
livrable
16
• Le suivi en continu du comportement de l’application sur le plan
technique, mais également du point de vue de son usage afin
d’améliorer l’efficacité de la solution.
II. En quoi consiste la démarche DevOps
La démarche DevOps est une philosophie. Elle vise à établir une
collaboration plus étroite et plus efficace entre les équipes de
développement et d’infrastructure en permettant une accélération des
déploiements tout en réduisant les frictions opérationnelles.
Elle représente un élément clé de la mise en place d’un processus de
Continuous Delivery et se traduit par la mise en application de différents
concepts d’ordre culturels et technologiques.
1. La culture DevOps
Une des caractéristiques de la démarche DevOps est de vouloir
changer la dynamique dans laquelle les équipes de développement et
opérations interagissent les unes avec les autres. Cette évolution est
encouragée en prônant des valeurs fondamentales comme le respect
mutuel, la confiance réciproque, la systématisation du partage de
l’information et la responsabilité.
L’objectif est de permettre aux membres de chaque organisation
d’avoir une meilleure compréhension du point de vue d’autres acteurs
avec lesquels ils sont en relation et de modifier leur comportement en
conséquence. L’ignorance délibérée des besoins de l’autre n’est plus
autorisée, car les résultats, comme la livraison d’un service livré en
production sont, en fin de compte, partagés. Cela conduit à
l’élaboration de mesures fondées sur la performance commune.
La culture DevOps favorise le développement des compétences de
l’ensemble des acteurs du système dans une recherche perpétuelle
d’amélioration (« Kaizen »). La pratique systématique de cette
approche est la condition sine qua non de cette progression.
L’organisation devient ainsi plus prompte à s’adapter et recherche le
changement plutôt que de le fuir.
17
En outre, elle propose une vision positive de l’échec. En effet, les
organisations doivent apprendre des succès, mais également de leurs
échecs. Elles doivent donc accepter de prendre des risques. L’adoption
ce type de démarche offre la possibilité d’anticiper et définir de
nouveaux besoins opérationnels résultant de cette prise de risque.
Un des exemples de mise en place de ce type d’évolution culturelle est
la démarche d’introduction volontaire de défauts dans le système
(« Fault injection testing ») afin de constater au plus tôt la capacité du
système à se remettre en service après un dysfonctionnement. Cela
permet également de définir et partager les plans d’escalade et
processus internes associés. Avec l’accélération de l’évolution vers le
Cloud, ce type de test présente un intérêt renforcé, car l’infrastructure
matérielle est de moins en moins sous contrôle des directions
informatique et la probabilité d’inter-dépendances de services liés à
des SLA différents est de plus en plus forte.
2. DevOps : Perspective technologique
Sur le plan technologique la démarche DevOps se fonde sur de
multiples principes. Les machines peuvent être automatiquement
provisionnées grâce à la virtualisation, au Cloud et par la prise en
charge par de multiples outils d’orchestration. L’environnement de
déploiement d’une application (sa configuration et sa plateforme
cible) est un élément fondamental dont va dépendre la réussite du
projet. A ce titre, il se doit d’être géré comme n’importe quel autre
livrable du projet (archivage et contrôle des mises à jour, gestion des
versions).
Le Cloud est un élément naturel du DevOps mais il ne résume pas à
cette seule spécificité.
Afin d’éviter que le code d’une application soit étroitement couplé à un profil d’infrastructure spécifique, des « blueprints » sont associés aux applications précisant les « règles », descriptives ou prescriptives, ainsi que les paramètres d’entrée qui permettent aux services Cloud de connaître les actions à effectuer au nom de l’application.
18
Cette démarche est facilitée par l’évolution technologique.
L’infrastructure est dynamiquement modifiable grâce à des API. Les descriptions de configuration peuvent donc être fournies aux services Cloud. Elles sont directement corrélées aux profils de services d’infrastructure que propose le Cloud afin de configurer un ensemble d’instances et les différentes ressources
connexes. En conséquence, les équipes de gestion opérationnelle sont
amenés à écrire du code (scripts, workflows) pour provisionner et
configurer les environnements cibles. A ce titre, il leur est recommandé
de tirer parti des pratiques issues du monde du développement (tels que
l’utilisation de référentiels partagés avec contrôle de version,
l’automatisation des tests,…)
L’instrumentation d’une solution est essentielle pour pouvoir observer
son comportement sur le plan fonctionnel (pour obtenir des informations
permettant de répondre aux besoins fluctuants des utilisateurs) et sur le
plan technique (afin de pouvoir corriger les dysfonctionnements au plus
tôt, identifier les limites en termes de performance).
3. Les outils DevOps
Parallèlement à la mise en place de ces bonnes pratiques, ont
émergées des outils « DevOps ». Ils se fondent sur la manipulation
d’objets communs, partagés entre les équipes de développement et
de production.
La mise en œuvre d’une démarche DevOps repose sur plusieurs outils,
chaque outil étant dédié à ce qu’il fait de mieux. La réussite ou l’échec
de votre démarche dépendra de la capacité d’intégration et
d’échange entre les différents outils.
Ces outils apportent une réponse à de multiples problématiques que
l’on peut regrouper par thème.
19
20
Concevoir une application Cloud
I. Bâtir une architecture pour le Cloud
1. Les services IaaS et PaaS de Microsoft Azure
Microsoft Azure est une plateforme qui propose de multiples services
adaptés à des besoins spécifiques, que l’architecte peut choisir pour
définir les différentes briques de son infrastructure.
Les services de type IaaS (Infrastructure as a Service) offrent une
virtualisation de l’infrastructure physique, du stockage et du réseau. Ils
permettent de créer, déployer, démarrer et gérer des machines
virtuelles Windows ou Linux (au format VHD). Différentes
dimensionnements d’instances sont disponibles. Chaque instance
correspond à un ensemble de ressources : processeur, mémoire vive,
stockages, entrée / sortie, bande passante. Les machines virtuelles sont
persistantes, grâce à l’utilisation d’objets blobs, hébergés dans les
services de stockage Azure.
Les services de type PaaS (Platform as a Service) étendent ces services
d’infrastructure avec la prise en charge de modèles d’environnement
prédéfinis permettant un approvisionnement sur demande, en libre-
service, et automatisé de ces modèles. L’objectif est de faciliter le
développement, le déploiement et l’exécution d’applications. La
réutilisation de ces services requiert l’utilisation de SDK mis à disposition
dans de multiples environnements de développement.
Qu’ils soient de type IaaS ou de type PaaS, ces services bénéficient des
mécanismes de contrôle intégrés dans la Fabrique Microsoft Azure :
Surveillance des ressources utilisées
Gestion élastique le de la montée en charge des ressources de
type « Compute » (environnement d’exécution des services) en
fonction de leur utilisation (« autoscaling ») par configuration selon
différents critères (CPU moyen,…)
21
Garantie de continuité de service pour les applicatifs hébergés,
même en cas de panne matérielle, de mise à jour du système
d’exploitation ou de mise à jour de l’applicatif lui-même.
La grande variété de ces services impose la définition d’une
architecture « pensée pour le Cloud ». Cette démarche supposera donc
la mise en place d’une séparation claire entre les différentes
composantes d’une application (frontaux, cache applicatif, stockage,
données relationnelles, services d’exécution de tâche en arrière-plan).
2. Cloud Hybride
Au départ, le Cloud Hybride était considéré comme un modèle de
déploiement permettant aux clients d’étendre leurs solutions à
demeure vers le Cloud pour utiliser des capacités de traitement à la
demande et bénéficier de l’élasticité de ses ressources… C’est le
principe du débordement (ou « bursting ») pour le stockage ou les
traitements, ce qui correspond principalement à un usage des services
d’infrastructure. Mais vous pouvez faire du Cloud Hybride au niveau
applicatif. L’application devient alors une agrégation de services
déployés sur le Cloud, par exemple, des services Cloud utilisés par des
applications mobiles ou encore utilisant des services de différents
fournisseurs Cloud. Ces services doivent alors être intégrés tout en
respectant les contraintes environnementales (latence du réseau,
localité de données, performance, sécurité...).
3. Réversibilité du Cloud
La réversibilité est la possibilité de revenir à un état antérieur. Par
exemple, vous avez transféré des données sur le Cloud, la réversibilité
sera la possibilité de revenir au premier état ou même de migrer vers un
autre service. C’est un point souvent critique pour les entreprises.
L’objectif est non seulement de protéger le client vis-à-vis du fournisseur
de service (par exemple, si le fournisseur de Cloud ne satisfait pas à ses
obligations), mais cela lui permet également de construire une
application hybride avec un périmètre plus évolutif en terme de
localisation de ses ressources Cloud ou à demeure.
22
Les dépendances d’une application vis-à-vis du fournisseur de services
Cloud doivent donc être réduites et parfaitement connues. Azure offre
plusieurs niveaux de réversibilité :
- Les machines virtuelles ou les containers : la virtualisation des
machines ou des environnements applicatifs au sein de containers
est une première façon d’envisager la réversibilité du Cloud
Computing.
- L’utilisation d’API commune pour des services utilisés à demeure
ou dans le Cloud. Par exemple, le Cache Redis propose les mêmes
interfaces quel que soit son contexte d’utilisation.
- Le développement de couches d’abstractions permettant
d’encapsuler les échanges avec un service dans une interface qui
peut être héritée et injectée au moment de l’exécution.
- L’emploi de services identiques sur le plan conceptuel (par
exemple, Azure Search, construit directement sur Elastic Scale).
4. L’évolution des services de Microsoft Azure
La plateforme Microsoft Azure propose régulièrement de nouveaux
services.
Cette évolution peut se traduire par la fourniture de capacités de
natures différentes qui répondent à une attente du marché. Parmi
celles-ci, on peut citer :
RemoteApp : un service offrant un accès distant sécurisé aux
applications en présentation déportée
API Management : un service destiné aux entreprises pour publier,
sécuriser et héberger leurs APIs en permettant d’appliquer des
transformations de format, de configurer la description du mode
de consommation exposé, de définir des rôles pour les
développeurs, des plans d’utilisation et des quotas, de mettre en
place un suivi analytique pour protéger les APIs d’un usage abusif,
et de contrôler et configurer des alertes.
Key Vault : un service de sauvegarde des clés cryptographiques et secrets utilisés par des applications Cloud qui permet de chiffrer les clés et les données confidentielles (telles que les clés d’authentification, clés de compte de stockage, des clés de chiffrement de données, fichiers PFX et mots de passe) en
23
utilisant ces clés protégées par des modules de sécurité matériels (HSM : Hardware Security Modules)
…
Un autre axe de développement consiste à proposer des services s’inspirant à différents degrés de solutions issues du monde Open Source :
Solution Open Source hébergée par Microsoft (par exemple : Redis
Cache)
Solution Open Source dont l’infrastructure est installée depuis
l’assistant Marketplace ou en direct (ex: Hortonworks Data
Platform)
Solution Open Source hébergée par des partenaires (par
exemple : MongoDB par MongoLabs, MongoDB par MongoDB)
Solution directement bâtie sur une solution Open Source (par
exemple : Azure Search, service construit sur Elastic Scale)
Solution proposant un service managé similaire à une solution
Open Source (par exemple, DocumentDB qui partage des
caractéristiques communes avec MongoDB)
Le nouveau portail Azure regroupe l’ensemble de ces services dans une
galerie organisée par thèmes. La copie d‘écran suivante donne un
aperçu de cette galerie, baptisée Marketplace, car elle intègre
également des services proposés par des partenaires de l’écosystème
Microsoft.
24
5. Vers une fusion IaaS – PaaS ?
Avec Microsoft Azure, les environnements d’exécution qu’ils soient de
type IaaS, PaaS (Cloud services ou Web Sites) ont, la possibilité d’être
associés par la mise en œuvre de réseaux virtuels (« VNet Azure »). La
copie d’écran suivante présente la configuration d’un VNET pour un
Azure web site.
25
De plus, les services PaaS qu’ils soient liés à la gestion des données
structurées relationnelles (« SQL Database »), non relationnelles
(« Document DB »), non structurées (« Azure Storage »), à leur analyse
(« HD Insight », « Machine Learning »), à la gestion d’identité (Azure
Active Directory), à l’intégration (« Service Bus » dans ses différentes
déclinaisons, « Biztalk Services »), ou à des besoins purement applicatifs
(« Azure Cache », « Redis », « Azure Search », « Notification Hubs »…) sont
exposés via des SDK qui peuvent être utilisés depuis des environnements
d’exécution IaaS ou PaaS.
Enfin, l’automatisation du déploiement des services, qu’ils soient IaaS ou
PaaS est rendue possibles grâce à la mise à disposition d’API REST, de
cmdlets PowerShell ou azure-cli, ou de SDK, ce qui permet, dans le
même script de provisionning de déployer conjointement ces services
de nature différente.
Ces exemples illustrent donc un premier niveau d’interaction de services
IaaS, PaaS. Mais depuis le printemps 2014, un virage important s’opère
chez certains fournisseurs Cloud. Google et Microsoft ont ouvert la
brèche en dévoilant une interaction forte entre les services PaaS et
26
l’infrastructure IaaS. L’idée est « simple » : comment provisionner
automatiquement des services et des ressources de manière
transparente pour l’utilisateur. Objectif : ne pas de soucier du back-end
Cloud. Les scénarios de déploiement deviennent ainsi plus nombreux
tout en se débarrassant des contraintes liées aux technologies et
runtimes supportés par les services IaaS et PaaS.
L’usage de conteneurs s’est imposé de facto. L’idée est de disposer de
micro-VM que l’on instancie. Elles possèdent toutes les piles techniques
nécessaires au déploiement et à la production des applications. Autre
avantage du conteneur : sa portabilité. Docker apparaît aujourd’hui
comme la solution de référence pour construire, déployer et exécuter
des conteneurs. Les fournisseurs Cloud (Amazon Web Services, Google,
Microsoft, Red Hat, VMware) offrent déjà une intégration native avec
Docker ou l’ont inscrit dans leur roadmap. Cette fusion IaaS – PaaS est
prometteuse même si les offres ne sont pas encore matures. Ainsi,
CoreOS, un des soutiens de Docker, a dévoilé sa propre solution
conteneur. Azure évolue peu à peu vers cette « fusion »…
Dans une démarche DevOps, on comprend l’intérêt de cette
imbrication : on facilite le provisionnement des environnements
d’exécution et de déploiement, on facile la production grâce à des
environnements extrêmement modulaires.
6. Architecture blueprints
Pour faciliter l’appropriation de ces concepts par l’architecte, Microsoft
propose un ensemble de diagrammes basés sur des scénarios qui vont
l’aider à construire plus rapidement des solutions de différents types :
Applications métiers
Commerce électronique B2B (Interconnexion des applications
entre partenaires commerciaux pour optimiser les flux).
Stockage Cloud hybride
Marketing multicanal
Site e-commerce (avec catalogue, extraction, analyse et
prévision)
Gaming
27
Par exemple, le diagramme suivant présente le blueprint d’architecture
pour un site d’E-Commerce.
7. Cloud Design Patterns
Microsoft propose également un guide contenant aujourd’hui 24
« design patterns » et 10 thèmes connexes. Ce guide illustre le bénéfice
de l’application de modèles en montrant comment chaque pièce peut
s’insérer dans l’architecture de l’application et en argumentant les
choix retenus. Chaque modèle est fourni dans un format commun qui
décrit le contexte et problème, la solution, les questions et
considérations relatives à l’application du modèle. Chaque modèle
comprend également des liens vers d’autres modèles liés.
La plupart des modèles sont associés à des exemples de code qui
montrent comment les implémenter en utilisant les services de Microsoft
Azure. Toutefois, ils se veulent plus universels et seraient également à
considérer sur d’autres plateformes Cloud.
Le document suivant représente sur une seule figure l’ensemble de ces
« design patterns ».
28
Considérons l’exemple du « Scheduler Agent Supervisor Pattern ». Son
objectif est de coordonner un ensemble d’actions au sein d’un
ensemble distribué de services et d’autres ressources distantes, et de
gérer l’échec éventuel de l’une de ces actions (et d’annuler le résultat
de l’action si le système ne peut pas la mener à son terme).
Ce modèle permet ainsi d’ajouter de la résilience au système distribué
et de se prémunir contre des exceptions transitoires ou de longue durée.
Par exemple, les communications pourraient être interrompues, un
service distant pourrait ne pas répondre ou être dans un état instable
ou une ressource distante pourrait être temporairement inaccessible.
Dans de nombreux cas, ces échecs sont provisoires et peuvent être
gérés en tentant un nouvel appel (« retry »). Si l’application détecte un
dysfonctionnement plus permanent dont le système ne pourra pas
facilement se remettre, elle doit être en mesure de restaurer le système
dans un état cohérent et assurer l’intégrité de toute l’opération de bout
en bout.
29
Le diagramme suivant présente ce « Scheduler Agent Supervisor
Pattern ».
8. Architecture Failsafe
Pour garantir la résilience du système, l’architecte Cloud se doit de
s’inscrire dans une démarche dite « FailSafe ». Toute solution d’échelle
significative étant sujette au dysfonctionnement, il est préférable
d’intégrer des techniques de tolérance aux pannes dès la conception
30
des services pour réduire l’impact lorsque des défaillances se
produisent.
De multiples activités de conception contribuent à optimiser la solution
et à prioriser les mesures correctives, notamment celles liées à la gestion
de son évolutivité, de sa disponibilité et de sa résilience :
Le découpage de l’application en composants fonctionnels dont
la criticité métier diffère, ce qui permet de faire des choix
technologiques en fonction de critères de priorité et coûts.
La définition d’un modèle de cycle de vie d’application décrivant
le comportement attendu en production (charge variable aux
différentes heures de la journée,…).
La définition d’un plan et d’un modèle de disponibilité permettant
d’identifier le niveau de disponibilité attendue pour une
composante de l’application et de hiérarchiser les étapes d’une
remédiation sur des modes de défaillance pré-identifiés. Ces
éléments sont susceptibles d’influencer bon nombre des décisions
prises au cours du développement de la solution.
Identifier les points de défaillance et des modes de défaillance.
Pour créer une architecture résiliente, il est important de
déterminer et documenter ce qui peut provoquer une panne.
Identifier les points sujets à panne au sein d’une solution et les
modes de défaillance qui en résultent permet de prendre des
décisions sur les stratégies de résilience et de disponibilité dès la
phase de développement. Cette démarche, baptisée « Resilience
Modeling and Analysis (RMA) » se fonde sur une analyse et une
modélisation de la résilience des services composant l’application.
L’approche RMA est issue du standard de l’industrie « Failure Mode and
Effects Analysis (FMEA). » Elle propose de créer et gérer un modèle qui
détaille les possibilités de pannes de l’application et l’ensemble des
actions qui peuvent en atténuer l’impact. RMA peut donc être utilisé
pour modéliser les différents points de l’architecture présentant un
risque de défaillance, de documenter l’impact correspondant et de
définir des contre-mesures afin de s’assurer que la panne ne puisse pas
se produire ou pour limiter son incidence.
31
II. Développement de sites Web
Une application Web se compose du contenu de l’application stocké
dans un répertoire de fichiers, associé à une ou plusieurs bases de
données d’application, et de méta-données de configuration requis
par le serveur Web. Azure propose plusieurs options pour déployer et
assurer l’exécution de ce type d’application.
Il est possible d’héberger son site en s’appuyant sur le service IaaS de
Microsoft Azure. La gestion de la machine virtuelle, l’installation et la
configuration du serveur Web et la gestion de l’application doivent alors
être gérées explicitement.
Azure proposent un modèle de Cloud Service fondé sur notamment sur
la notion de « WebRoles » qui permettent au développeur de bâtir son
application en s’appuyant sur l’utilisation de modèles d’environnement
prédéfinis. Charge au développeur de créer son application de
manière compatible avec ces modèles, de créer un package à l’aide
de Visual Studio ou d’Eclipse puis de le déployer dans Azure. Ce modèle
convient parfaitement pour un nombre relativement restreint
d’applications Web. Les développeurs et les administrateurs peuvent
aisément gérer quelques applications et s’assurer que les diverses
ressources externes et les données de configuration restent
synchronisées.
Il devient plus complexe lorsque l’on multiplie les applications Web sur
une même infrastructure ou lorsque l’application nécessite de nouvelles
32
ressources. Les approches traditionnelles de gestion d’applications Web
deviennent peu à peu inadaptées et ne permettent pas de garantir la
montée en charge et la maintenabilité nécessaire.
Microsoft Azure propose donc un modèle dédié aux Web sites avec
comme niveau de granularité le processus de travail (« worker
process ») plutôt que la machine virtuelle. Du point de vue de
l’application, rien ne change : les API standards que les développeurs
utilisent pour accéder aux ressources externes telles que des fichiers et
bases de données continuent à fonctionner comme dans le précédent
modèle. Le processus de travail responsable de l’exécution de
l’application Web est fourni avec les fichiers de configuration requis par
les applications Web. Ni l’application Web, ni le processus de travail ne
sont « conscients » du fait qu’ils s’exécutent dans Azure Web sites (et non
sur un serveur Web IIS « traditionnel »), ce qui permet de ne pas avoir à
développer ou à packager son application spécifiquement pour ce
modèle. Le service s’appuie sur le serveur Web IIS (Internet Information
Server), Windows, et son extension ARR (Application Request Routing)
pour gérer la répartition de charge.
L’architecture interne de ce service est décrite dans le schéma su ivant :
Le service Azure Web sites supporte ASP.Net, Node.js, PHP, Java, Python
permettant la construction rapide de serveurs Web et leur publication
via Git, WebDeploy, TFS, FTP, en se fondant sur des gestionnaires de
33
contenu populaires tels que Drupal, Umbraco, .NetNuke, Joomla !,
Mojo, phpBB, WordPress...
III. Développement de traitements de type « batch »
Historiquement, l’implémentation d’un service ou d’un batch dans
Microsoft Azure se fondait sur le déploiement d’une machine virtuelle
ou sur l’implémentation d’un Cloud Service de type « WorkerRole ». Un
nouveau mode de traitement est apparu avec la notion de WebJobs.
Les WebJobs permettent de déployer et exécuter du code en tâche de
fond sur les machines hébergeant les Azure Web sites. Ils héritent ainsi
de l’ensemble des caractéristiques de la plateforme Web sites (montée
en charge, remote debug, load balancing, autoscaling, supervision,
etc.).
Ils sont très utiles pour mettre en place des mécanismes asynchrones
(l’application Web envoie un message dans une file d’attente, et ce
message est dépilé et traité par un Azure WebJob s’exécutant
régulièrement de manière asynchrone) et peuvent être déclenchés
selon différents schémas d’activation :
Comme un batch planifié (exécution unique ou répétitive)
Manuellement (via l’API REST, l’utilisation d’un SDK Azure ou le
portail)
Comme un service (exécution en continu surveillée par la
plateforme et redémarrée si nécessaire : le service s’exécutera
tant que le site est considéré comme actif, état qui peut être forcé
via l’option « AlwaysOn »)
Un SDK dédié peut être utilisé pour créer ces WebJobs, par exemple
pour créer des tâches qui s’interfacent par databinding déclaratif avec
Service Bus ou le stockage Microsoft Azure. Ce SDK offre un outillage
complémentaire pour la supervision et le debugging.
Voici un exemple de message lu dans une file d’attente avec
déclenchement de l’écriture d’un fichier binaire dans Azure Storage :
public static async Task BlobNameFromQueueMessage( [QueueTrigger("persons")] Person persons, string Name, [Blob("persons/{Name}BlobNameFromQueueMessage", FileAccess.Write)] Stream output) {
34
byte[] messageBytes = Encoding.UTF8.GetBytes("Hello " + Name) ; await output. WriteAsync(messageBytes, 0, messageBytes.Length) ; }
IV. Développement de backend pour sites et apps mobiles
Les « Azure Mobile Services » ciblent la mise en place de backends
pour applications mobiles. Ils permettent en effet d’accélérer la mise
en place de l’authentification des utilisateurs, des services de
notification, du stockage et de l’exposition des données nécessaires
pour une application mobile connectée.
De multiples SDKs clients sont disponibles pour faciliter la connexion de
ce service avec les applications des différentes plateformes du
marché (Windows 8, Windows Phone 8, HTML5 Client, iPhone/iPad,
Android, Xamarin ou Apache Cordova).
De plus en plus d’apps utilisent un backend Cloud pour les fonctions
évoqués plus haut. Les scenarii seront de plus de plus nombreux et
l’étendu fonctionnel de cet backend devrait s’étendre.
35
V. Développement IoT (« Internet Of Things »)
1. Les prérequis d’une infrastructure IoT
Les objets connectés collectent et génèrent de nombreuses données
de différentes natures, de différences sources : voitures, thermostats,
ampoules, bracelets, etc. Ces objets créent des événements, des
applications mobiles capturent des données à chaque action de
l’utilisateur
Ces objets se multiplient et ils devraient être de plus en plus nombreux*.
Cette prolifération constitue un défi en raison de la variété des
plateformes et protocoles. En effet, il faudra être en mesure de proposer
une infrastructure backend scalable et hautement disponible pour gérer
ce flux de données et même pour étendre les fonctionnalités de ces
objets.
*En 2018, d’après une étude CISCO (http://globalnewsroom.cisco.com/fr/fr/press-
releases/etude-cisco-les-francais-toujours-plus-connectes-nasdaq-csco-1122921), il y aurait trois fois plus d’appareils connectés que d’habitants
Le Cloud et le Big Data apportent une réponse. Mais pour être
pleinement efficace, il faudra disposer de services et des API adaptés.
Le schéma suivant décrit l’architecture conceptuelle d’une application
IoT et les services correspondant dans la plateforme Microsoft Azure.
36
2. L’ingestion des données
L’ingestion de données peut être gérée de multiples façons dans Azure.
Parmi celles-ci, Event Hub se distingue par sa capacité à proposer un
service de réception évolutif capable de prendre en charge des profils
de charge variables ainsi que des pics causés par une connectivité
intermittente. Event Hub offre en effet un mécanisme de type
publication-souscription pouvant recevoir des millions d’événements
par seconde, tout en conservant l’ordre des événements pour chaque
appareil. La prise en charge d’AMQP et de HTTP permet à de
nombreuses plateformes de pouvoir interagir avec Event Hub. Des
bibliothèques clientes natives existent également pour les plateformes
les plus courantes.
3. La transformation des données
Le monde connecté d’aujourd’hui est défini par le Big Data. En effet,
une fois ces données collectées, il est nécessaire de les stocker et de les
transformer sachant que les devices et applications connectés peuvent
produire des volumes de données très importants. La connexion de ces
sources de données disparates tout en prenant en charge l’évolutivité
du flux agrégé représente donc un vrai défi.
37
Le traitement et l’analyse de ces données peut être réalisé « par lots »
en différé ou en « temps réel ».
a. Traitement « par lots »
Azure HDInsight Hadoop
Azure HDInsight Hadoop est une distribution Apache Hadoop
proposée sur le Cloud Microsoft Azure. Le service HDInsight est
architecturé pour gérer et analyser une quantité quelconque de
données non structurées ou semi-structurées en proposant des
extensions de programmation pour de nombreux langages tels que
C#, Java et .NET.
Azure HDInsight HBase
Azure HDInsight HBase est le service qui permet de configurer dans
Azure des clusters HBase pour stocker de gros volumes de données
directement dans le stockage Blob Azure avec une faible latence et
les analyser avec des jobs Hadoop.
HBase est une base de données Apache Open Source NoSQL
« orientée colonne » construite sur Hadoop. Elle fournit un accès
aléatoire et une forte cohérence pour grandes quantités de données
non structurées et semi-structurées. Les données sont stockées dans les
38
lignes d’une table et regroupées au sein d’une ligne par « famille de
colonne ». La scalabilité de HBase (fondé sur le modèle « BigTable » de
Google) lui permet de gérer plusieurs péta-octets de données sur des
milliers de nœuds.
L’implémentation HDInsight HBase se fonde sur l’architecture de scale-
out de HBase pour offrir un sharding automatique des tables, une forte
cohérence pour les lectures et écritures et un basculement
automatique. La performance est renforcée par la mise en cache en
mémoire sur la lecture et un débit élevé en écriture.
Azure Machine Learning
Azure Machine Learning est un service intégralement géré par
Microsoft Azure. Il permet de prévoir les futurs comportements ou
tendances, en fondant ces analyses prédictives sur des données
précédemment collectées. Azure Machine Learning offre une
expérimentation rapide pour créer un meilleur modèle avec l’aide de
bibliothèques de modèles réutilisables. Il permet une composition
visuelle de bout en bout sur le flux de données et supporte
l’environnement de programmation Open Source « R » pour les
statistiques et l’exploration de données. Enfin, il est possible de
déployer le modèle comme un Web Service hébergé dans Azure.
39
b. Analyses en temps réel
Stream Analytics
Stream Analytics est un moteur de traitement d’événements qui
permet de traiter des informations issues de multiples sources,
notamment les données en provenance d’Event Hub, afin d’analyser
en « temps réel » des millions d’événements par seconde.
Stream Analytics permet de comparer plusieurs flux en temps réel, et
d’intégrer dans l’analyse des valeurs et des modèles historiques en
bénéficiant d’un débit élevé, d’une faible latence et d’une résilience
garantie. Stream Analytics permet ainsi la détection des anomalies, la
transformation des données entrantes, l’alimentation de tableaux de
bord en temps réel et offre la possibilité de déclencher une alerte
lorsqu’une erreur ou condition spécifique apparaît dans le flux.
40
Azure HDInsight Storm
HDInsight Storm est le service qui permet de configurer dans Azure un
cluster Apache Storm managé. Apache Storm est un système de
calcul Open Source distribué et résilient, pour le traitement, en temps
réel, des données, qui dans le cas d’Azure, peuvent être issues de files
d’attente Service Bus ou Hub Event.
Les clusters HDInsight Storm peuvent également être configurées sur un
réseau virtuel d’Azure extensible avec un VPN, afin d’offrir une
communication sécurisée avec les ressources au sein d’un DataCenter
privé.
VI. L’impact pour le développeur
La multiplicité des services et des modèles ont un impact sur la manière
de développer et de déployer les applications. Le développeur est
naturellement en première ligne de l’évolution vers le Cloud et doit
donc s’adapter à ce nouvel environnement.
Toutefois, ce changement est facilité, car le Cloud est un accélérateur
de développement :
41
Rapidité de mise à disposition d’environnement d’exécution
(mutualisation et disponibilité des ressources)
Facilité d’évaluation des technologies via prototypage (Proof of
Concept) sur des environnements disponibles à la demande
Pré-installation d’environnements serveurs proposés par Microsoft
(SQL Server, SharePoint Server, Biztalk Server,...)
Partage et automatisation du déploiement de plateformes pour
les tests, les développements ou l’intégration
Activation de services applicatifs liés à la solution cible (Azure SQL
Database, Azure Active Directory, Azure Service Bus, Azure Biztalk
Services,...)
Outillage Cloud avec Visual Studio Online ciblant la construction,
l’observation du comportement et l’évolution des applications
dans le Cloud et aligné sur les bonnes pratiques du Continuous
Delivery : agilité et industrialisation des développements,
intégration continue, démarche DevOps.
VII. La proposition de valeur du développement dans le
Cloud
C’est une question des plus classiques : quelle valeur apporte le Cloud ?
Quel ROI ou TCO espérer ?
Au début du Cloud, l’un des arguments majeurs était sa capacité à
réduire les coûts liés à l’acquisition d’une infrastructure complétée par
des logiciels à demeure. Pourtant, sur la durée, le paiement à la
consommation de services Cloud peut paraître aussi coûteux, voire plus.
Mais, pour se livrer à ce type de comparaison, il faut veiller à intégrer
tous les paramètres En, effet, il serait inapproprié de considérer la
proposition de valeur du Cloud uniquement du point de vue du coût de
possession ou du retour sur investissement. En effet, il convient de
prendre en compte plusieurs éléments : les coûts directs (achats,
licences, énergie, etc.), mais aussi les coûts cachés et indirects
(maintenance, mise à jour, migration, support, gestion du parc, etc.).
N’oublions pas que le Cloud déleste le développeur et l’entreprise de
nombreuses tâches : déploiement, mise à jour, maintenance de la
solution, cycle de vie du matériel, etc.
42
Pour la production, le Cloud apporte une souplesse inégalée dans la
capacité à gérer la montée en charge et dans la possibilité de
provisionner ou dé-provisionner des ressources et d’ajuster au mieux leur
consommation. Prenons le cas du service de mise à disposition de
clusters Hadoop à la demande. Vous pouvez provisionner un cluster
pour quelques minutes seulement et payer la location de ce cluster en
fonction de cette durée. Autre exemple, l’automatisation de la montée
en charge par des mécanismes d’auto-scaling peut s’avérer
particulièrement efficace pour optimiser les coûts selon le contexte.
Pour le développeur, la proposition de valeur du Cloud est également
très significative. Elle se manifeste sous de multiples formes. Le Cloud
apporte au développeur des infrastructures prêtes à l’emploi
complétées par un ensemble de workloads et de runtimes activables à
la demande. Il peut ainsi se concentrer sur son code. D’autre part, le
développeur est tributaire de l’environnement lui permettant de gérer
les versions, partager, compiler, déployer, et tester son code. Installer à
demeure un serveur TFS ou mettre en place une infrastructure
d’intégration continue demande du temps et de solides compétences.
En mode Cloud, il devient ainsi possible d’économiser de précieuses
heures, tout en bénéficiant de services complémentaires (comme le
backup ou le déploiement d’un rig de tests à la demande pour les tests
de charge).
43
Développer une application Cloud en Continuous Delivery
I. Introduction
Le développement d’une application Cloud en Continuous Delivery
suppose la mise en place d’une démarche agile, la définition d’une
structure organisationnelle adaptée, la mise en place de processus et
d’outils permettant de réduire les cycles de livraison, l’optimisation des
ressources utilisées, l’amélioration de la qualité et la mise en place de
moyens permettant recueillir, au fil de l’eau, le maximum d’informations
sur l’usage et les attentes des utilisateurs vis-à-vis de l’application.
II. Démarche agile
Une des caractéristiques essentielles de l’agilité repose sur la mise en
place d’un cycle de développement itératif et incrémental prenant en
compte la collaboration avec le client (engagement des utilisateurs et
des parties prenantes, scénarisation, prototypage UI, modélisation,…)
plutôt que la contractualisation des relations. L’agilité se distingue
également en favorisant le travail d’équipe, l’auto-organisation et la
responsabilisation.
Les méthodes agiles décomposent les actions en petites étapes de
planification (itération de 1 à 4 semaines). Chaque itération cible un
travail d’équipe à travers un cycle de développement logiciel complet.
Cela permet de minimiser le risque global et de s’adapter rapidement
aux changements. L’objectif est d’avoir une version disponible à la fin
de chaque itération.
Parmi les méthodes agiles, citons la méthode Scrum. Scrum définit un
jeu d’activités qui permettent aux clients d’étudier, de guider et
d’influencer le travail de l’équipe de développement au cours de sa
progression. L’équipe travaille par courtes itérations (appelées aussi
sprints) et affine son plan à mesure qu’elle avance dans son travail. Ces
différents sprints ont une durée fixe, toujours identique, et fixée à l’origine
du projet. Cela permet de connaître la vélocité de l’équipe et de
44
pouvoir être toujours plus précis dans l’estimation du temps de
réalisation d’une partie de l’application.
III. Structure organisationnelle et planification des actions
L’objectif de la mise en place d’une structure organisationnelle
adaptée au Continuous Delivery est d’optimiser les cycles de
développement, la qualité du code produit, avec une visibilité claire sur
l’avancement du projet, tout en maintenant le maximum d’intérêt et de
motivation pour les équipes.
1. Structure organisationnelle
La structure hiérarchique peut être organisée en pools de domaines
d’expertise : développement de services, front-end Windows, Web,
mobile, stockage et traitement des données, automatisation,…
Chacun de ces pools capitalise sur des pratiques spécifiques à son
domaine d’expertise (réutilisation de code et frameworks, design
patterns, documents d’architecture), mais aussi sur des processus et
outils commun avec l’ensemble des équipes (environnement
collaboratif de développement Visual Studio Online, infrastructure de
test et développement déployée dans Azure,…) avec pour objectif de
maximiser la qualité et d’accélérer la production.
Cette démarche permet de garantir une perspective à long terme sur
l’ingénierie logicielle, tout en offrant une structure stable aux équipes
techniques.
45
2. Les projets
Les projets peuvent être découplés de cette structure en domaine
d’expertise.
En effet, en fonction de sa taille et de son périmètre, chaque projet peut
donner lieu à création d’une équipe autonome et éphémère (durée de
vie = la durée du projet) concentrant les talents issus des multiples
domaines d’expertise, avec d’éventuelles permutations (ce qui
implique la mise en œuvre et le partage de pratiques communes).
Au final, aucun travail n’est effectué à l’intérieur de la structure d’un
pool d’expertise : tous les travaux sont réalisés dans le cadre de ces
équipes pluridisciplinaires.
Le code et autres éléments constitutifs des solutions, sont partagés par
l’ensemble des équipes, ce qui permet à n’importe quel membre d’une
équipe technique de venir remplacer ou épauler l’un de ses collègues
si nécessaire.
3. Les équipes projets
Les équipes projets sont focalisées sur leur projet. Tous les participants du
projet peuvent faire appel aux services d’un des membres de l’équipe.
Par contre, il n’est pas possible de lui affecter une tâche sur un autre
projet pendant la période sur laquelle il est déjà engagé sur le projet en
cours.
La taille de l’équipe projet est volontairement limitée, de même que la
durée, elle-même sous-décomposée en de multiples itérations afin
d’assurer la validation incrémentale des livrables et d’obtenir aux plus
tôt les données permettant cette validation.
Le chef de projet fonctionnel est le garant du respect des exigences et
des délais de livraisons. Il définit les priorités. Au sein de l’équipe projet,
un « Tech Lead », doté de multiples compétences techniques a la
responsabilité de conduire l’exécution technique. Il est le garant de la
qualité des livrable et l’interlocuteur du chef de projet fonctionnel dans
la définition du périmètre des itérations.
46
Des réunions permettant de partager les retours d’expérience sur les
projets en cours de réalisation sont régulièrement organisées, ce qui
permet également de bénéficier des suggestions de l’ensemble des
participants, qu’ils soient ou non affectés sur le projet.
Au sein de ce projet sont constituées des équipes (souvent organisées
en binôme dans l’éventualité d’une permutation, fort pratique en
période de congés…), qui visent chacune un objectif principal de
livrable. Ces équipes définissent elles-mêmes la meilleure façon
d’atteindre les objectifs qui leur sont assignés sur des périodes très
courtes.
L’ensemble des activités sur le projet et l’affectation des ressources sont
définies « en continu » par le chef de projet fonctionnel et par le « Tech
Lead ». L’ensemble des participants sont identifiés dans le référentiel
dédié au projet et publié sur Visual Studio Online.
La copie d’écran suivante présente la page d’accueil d’un projet
configuré dans Visual Studio Online.
47
4. Planification des actions
L’affectation des ressources est réalisée directement depuis l’outil Visual
Studio Online, en utilisant l’outil de planification de capacités et en
couplant son utilisation avec la ventilation des tâches sur un sprint.
L’avancement du projet est également suivi avec le Task Board et le
Burndown Chart.
Un effet de bord très positif découle de l’autonomie native des équipes,
de leur niveau de responsabilisation, et de la volonté de simplifier les
processus de coordination.
48
Visual Studio Online offre des fonctions permettant d’accompagner
efficacement la définition du périmètre cible et l’affectation des
ressources sur le projet et s’adapte parfaitement à ce modèle
organisationnel.
IV. Réduction des cycles de livraison
1. Le contrôle de code source
Le processus de développement démarre avec un outil de contrôle de
version du code source de l’application et s’achève par le déploiement
des binaires dans l’environnement de production.
Visual Studio Online propose deux modes de configuration pour ce
contrôle de code source, l’un basé sur le standard Git (qui permet très
facilement de cloner un référentiel dans lequel on peut avoir de
multiples repositories Git), l’autre fondé sur le modèle beaucoup plus
centralisé que propose TFVC (Team Foundation Version Control), le
contrôle de code source historique de TFS.
49
2. Test automatisés
Durant les différentes étapes du développement, de nombreux types
de tests doivent s’exécuter. Tester un logiciel va d’abord consister à
lancer les composants logiciels ciblés dans un contexte d’exécution
permettant de mesurer les résultats obtenus afin de déterminer si les
objectifs de ces composants sont atteints.
Mais détecter les erreurs du logiciel et les exposer pour correction n’est
pas suffisant, car les erreurs ne se limitent pas aux erreurs de code ; elles
peuvent se produire à différentes étapes du cycle logiciel (y compris
dans les étapes préliminaires de spécification fonctionnelle et de
conception).
C’est pourquoi, au-delà de l’examen des résultats de l’exécution du
composant ciblé, le test logiciel englobe tout le processus associé, ce
qui inclut la définition de la nature et la portée de ces tests en
correspondance avec les exigences fonctionnelles (parfois avant
même le développement des composants logiciels concernés (« Test
Driven Developpement » ou « Test First Programming »), ainsi que
50
l’attribution de rôle de responsable des tests au sein de l’organisation
de l’équipe de production logicielle,…
Une démarche de test logiciel se doit donc de respecter plusieurs
impératifs : la définition des politiques définissant les modalités
d’applications de ces tests (planification dans les différentes phases du
cycle de vie de l’application, fréquence et conditions d’exécution, rôle
de chaque membre de l’équipe), le déploiement de l’infrastructure
(matérielle et logicielle) permettant la mise en œuvre de ces politiques
ainsi que les processus assurant le contrôle du respect des politiques.
Des environnements de déploiement dédiés sont nécessaires pour
l’intégration fonctionnelle et la mise en œuvre de tests de performances
pertinents. Le Cloud offre une réponse particulièrement adaptée à ce
type d’usage, avec sa capacité à cloner et déployer des configurations
à la demande.
Un logiciel spécialisé est nécessaire pour la gestion du plan de tests, la
création de données fonctionnelles et de tests de performances, et les
tests unitaires.
Cependant, la mise en œuvre de ces tests suppose deux prérequis :
D’un point de vue technique, s’assurer que les développeurs ont
facilement accès aux différents types de tests et que leur écriture
ne se traduit pas par une contrainte, mais par un réel gain de
productivité.
D’un point de vue organisationnel, rapprocher le monde des
testeurs fonctionnels de celui des développeurs responsables de
la correction de bogues, en simplifiant et fluidifiant leur
communication. Et c’est là l’une des valeurs ajoutée de Visual
Studio Online qui permet de gérer des campagnes de tests
définies dans un référentiel commun.
La création d’un projet de test peut donc être réalisée par n’importe
quel membre de l’équipe technique, au travers de l’assistant de
création de projet de Visual Studio. Une fois créé, le projet de test
ressemble à tout autre projet de développement .Net : il possède des
références vers le Framework de test de Microsoft et peut contenir des
types de fichiers spécifiques représentant des tests.
51
À l’aide de Visual Studio 2013 (et bientôt 2015), il est possible de créer
différents types de tests automatisés ou manuels. Parmi les tests
automatisés, on trouve notamment :
Tests unitaires: le plus classique, qui permet de tester du code
en .Net, avec un squelette généré.
Tests unitaires de base de données : équivalent du test unitaire .Net
mais en T-SQL
Tests Web : capture et rejoue un scénario de navigation Web.
Concrètement, le test Web permet de décrire un ensemble de
requêtes HTTP (GET / POST) et se charge de rejouer celles-ci en
assurant que les requêtes et le contenu HTML renvoyé par le
serveur sont celles attendus.
Test d’interface utilisateur (« Coded UI »).
Tests de charge : permet de rejouer en boucle un ou plusieurs tests
en simulant de la charge pour vérifier les performances de
l’application sous différents niveaux de stress
3. Intégration continue
Dès qu’il y a plus d’un développeur appelé à modifier le code source
de l’application, il est crucial de valider fréquemment l’intégration du
travail de chacun avec celui des autres. Pour cela, une validation
manuelle locale par le développeur lui-même ne suffit pas. L’idéal est
d’effectuer un ensemble de vérifications sur un environnement dont on
maîtrise la configuration et indépendant des postes de l’équipe de
développement. Chaque intégration est vérifiée par une génération
automatisée (y compris le test) pour détecter les erreurs d’intégration
dès que possible.
Le processus qui permet d’effectuer cette validation est couramment
appelé « Chaîne d‘intégration continue ». Ce processus comprend en
général les étapes suivantes :
52
Le développeur fait évoluer le code et procède à des tests
localement sur son poste de travail. Cela inclut l’écriture de tests
unitaires automatiques. Le code est archivé dans le contrôle de
code source.
Un serveur de builds extrait la dernière version disponible du
code depuis le contrôleur de code source, il compile, exécute
les tests unitaires pour s’assurer de la qualité du code produit et
crée des packages de déploiement selon l’environnement de
déploiement cible.
Les packages sont déployés sur la plateforme cible déployée
sur Azure
De tests supplémentaires sont automatique lancés (tests
d’interfaces graphiques automatisés, tests de vérification du
bon déploiement,…)
Généralement, ce processus, est déclenché le plus fréquemment
possible : à chaque mise à jour du référentiel de code source. Il peut
cependant être effectué régulièrement sans pour autant le faire à
chaque archivage…. Idéalement, les phases d’intégration explicite
deviennent optionnelles puisque le code est toujours intégré.
L’automatisation du processus de génération des livrables est un facteur
déterminant de la mise en place de ce workflow. Elle garantit le principe
d’une opération reproductible, fiable et prévisible.
Le service propose une intégration native avec différents contrôleurs de
code source ou outils de déploiement : Visual Studio Online, GitHub, Git
Local, CodePlex, Bitbucket ou encore Dropbox, ce qui permet
d’implémenter très simplement un processus d’intégration continue.
L’utilisation combinée des solutions Microsoft Azure et de Visual Studio
Online, grandement facilitée par leur intégration native, est un parfait
exemple d’outillage permettant de gérer ce type de processus. Par
exemple, il est très rapide de configurer un déploiement automatique
de la dernière version de l’application Web dans un environnement
53
Azure Web sites de test/pré-production à chaque fois qu’un build est
réussi.
4. Automatisation des environnements
L’automatisation de la mise à disposition des environnements
correspond à la dimension « Infrastructure as code » de DevOps.
a. Provisioning d’infrastructure
L’objectif est de déployer un service un environnement d’exécution
pour une instance de système d’exploitation spécifique choisie par
l’utilisateur à partir d’une liste d’images pré-définies.
Le fonctionnement varie alors considérablement suivant que ce
« provisioning » soit réalisé sur des serveurs virtualisés (avec ou sans
Cloud) ou des instances de système d’exploitation natif. Il est en effet
possible de produire automatiquement un environnement entier à partir
d’un environnement « bare-metal » avec des outils comme System
Center Virtual Machine Manager (SCVMM) ou de cibler un hyperviseur
disposant d’un référentiel d’images virtuelles. Dans un cas comme dans
l’autre, l’outil de « provisioning » doit permettre de réserver et configurer
les ressources CPU, le stockage, tout en prenant en compte d’autres
services, telles que l’authentification.
Le « provisioning » est réalisé sur la base de « modèles d’infrastructure »
qui vont pouvoir être partagés et répliqués sur les différentes
plateformes (développement, intégration, recette, pré-production,
54
production) dans des configurations qui pourront varier en termes de
dimensionnement. L’intérêt d’automatiser le provisioning
d’infrastructure est non seulement d’accélérer la mise à disposition des
environnements d’exécution, mais aussi de pouvoir répondre à
d’éventuels changements si nécessaire.
Le choix de tel ou tel autre outil pourra se faire sur de nombreux critères :
Système d’exploitation sur lequel est lancé le « provisioning »
(exemple : les commandes PowerShell s’exécutent dans
Windows, même si elles permettent de provisionner des
machines virtuelles en se basant sur des distributions Linux).
Type d’usage (Vagrant cible plutôt les tests ou le
développement)
Gestion de configuration : la plupart des outils ne se limitent
pas à un simple « provisioning »
Parmi les logiciels de provisioning disponibles aujourd’hui, citons :
Ansible, Chef, Puppet, Salt, Vagrant, Skytap, Cfengine, Cmdlet
PowerShell Azure, Microsoft Deployment Toolkit (MDT), System Center
Virtual Machine Manager (SCVMM).
Une fois qu’une instance de système d’exploitation minimale est en
cours d’exécution et dispose d’une connectivité réseau, il est alors
temps de faire appel à l’outil de configuration du système.
Le provisioning de ressources Windows et Linux peut être directement
assuré par la mise en œuvre des différents SDK Azure, des Cmdlets Azure
PowerShell, de l’API REST de management, ou du langage de scripting
Azure Cross-Platform Command-Line Interface.
PowerShell est le langage de scripting et d’automatisation proposé par
défaut sur la plateforme Windows. Un module Azure est disponible pour
enrichir ce langage de multiples Cmdlets permettant d’automatiser le
provisioning des différentes ressources Azures.
Azure Cross-Platform Command-Line Interface (xplat-cli) est le langage
de scripting en ligne de commande pour les environnements Windows,
Mac et Linux. Il est développé en javascript et nécessite l’installation de
node.js.
55
La figure suivante présente différentes commandes xplat-cli.
b. Gestion de configuration
La gestion de configuration suppose la création d’un modèle de
déploiement unique partagé entre les développeurs et les équipes de
gestion opérationnelle.
Il est nécessaire de s’assurer que les environnements de
développement, de test et de production sont tous configurés de la
même manière. Cela garantit qu’il n’y a pas de surprises liées aux
subtiles différences entre les environnements. Il faut donc offrir la
possibilité d’encoder ces configurations dans un langage permettant
de les créer et les faire évoluer.
Parmi les autres caractéristiques des outils de gestion de configuration
citons :
La validation de la bonne exécution d’une configuration
La capacité à pouvoir appliquer plusieurs fois la même
configuration sans provoquer d’erreur ni en modifier le résultat
(idempotence)
56
La possibilité d’effectuer un rollback sur une configuration
précédente
Il est souvent plus simple et plus rapide de relancer les opérations de
« provisioning » et configuration que de tenter de réparer un
environnement présentant un défaut.
Les objectifs de maintien de configurations système et d’application
sont souvent en désaccord. Les configurations système doivent
généralement être maintenues aussi cohérentes que possible, tandis
que les configurations d’application peuvent changer constamment
selon l’évolution des besoins commerciaux et des cycles de
déploiement. Ces besoins opposés sont une des raisons pour lesquelles
Le déploiement reconnaît une séparation conceptuelle entre la gestion
de la configuration des systèmes et des applications.
Cette distinction se retrouve dans les outils de gestion de configuration :
Configuration système : PowerShell DSC, Puppet, Chef, Salt,
Ansible, CFEngine, Juju, Docker,…
Configuration d’application : Capistrano, Fabric, Func,
ControlTier, Docker
Bien que les outils Open Source présents dans cette liste aient été à
l’origine conçus pour automatiser la configuration de systèmes
d’exploitation Linux, leur arrivée dans le monde de l’entreprise a permis
leur extension vers les environnements Windows.
La configuration système des environnements Windows peut être
réalisée grâce au Windows Management Framework (version 5
aujourd’hui disponible en preview) qui regroupe différentes
technologies parmi lesquelles les DSC et OneGet.
La version 4.0 de PowerShell proposait déjà une évolution majeure avec
« Desired State Configuration » (DSC). La version 5.0 du Windows
Management Framework vient enrichir les DSC. Le principe de DSC est
de définir l’état d’une instance de serveur de Windows dans le code,
en utilisant des blocs de configuration pour spécifier les composantes
57
Windows à installer et les compléments associés (entrées de clés de
Registre, création de fichiers, routines d’installation…).
Un script de DSC est idempotent. Grâce à DSC, il est maintenant
possible de gérer dans un référentiel de code source les multiples
versions d’une configuration des informations permettant de déployer,
configurer et gérer des services logiciels et l’environnement dans lequel
ils sont exécutés. Pour ce faire, DSC fournit un ensemble de ressources
baptisées modules, permettant de spécifier de façon déclarative la
configuration de l’environnement logiciel.
Parmi celles-ci, le module « xAzure » propose un ensemble de ressources
permettant de déployer des machines virtuelles dans Microsoft Azure
en appliquant une configuration depuis un ordinateur local. Ce module
comprend six ressources DSC qui automatisent la fourniture de
différentes ressources Azure, comme xAzureQuickVM (création de
machines virtuelle), xAzureService (création de service de Cloud),
xAzureStorageAccount (création de compte de stockage en ligne), ou
xAzureSqlDatabase (création de base de données Azure SQL
Database).
Windows PowerShell OneGet est une technologie dont l’objectif est de
simplifier considérablement la découverte et l’installation de logiciel sur
les machines Windows.
Avec OneGet, il est possible de :
Gérer une liste de dépôts de logiciels dans lequel les packages
logiciels peuvent être recherchés, acquis et installés
Installer et désinstaller silencieusement des packages d’un ou
plusieurs référentiels avec une seule commande PowerShell
OneGet fonctionne avec le référentiel communautaire « Chocolatey »
qui recense plus de 1 700 logiciels uniques. La prise en charge de dépôts
supplémentaires sera proposée dans des versions ultérieures.
Pour l’utiliser, il suffit d’importer le module OneGet dans PowerShell.
On dispose alors des commandes OneGet suivantes :
58
c. Provisioning et configuration avec « Azure Resource Manager »
A l’origine, la gestion d’une ressource Azure (base de données,
machine virtuelle, compte de stockage, site Web) était « unitaire ».
Cette situation rendait complexe la gestion d’une application
composée de plusieurs ressources.
En effet, il était difficile de :
Déployer ou de mettre à jour un groupe de ressources de façon
récurrente
Gérer les permissions sur un groupe de ressources
Disposer d’une représentation offrant des informations de
supervision technique et de facturation pour un ensemble de
ressources
Il est maintenant possible de créer et gérer des groupes de ressources
grâce au « Azure Resource Manager » qui permet de déclarer une
entité de gestion dans laquelle sont intégrés des regroupements de
multiples ressources de même type ou non. L’appartenance à un
groupe de ressources est exclusive. Les ressources peuvent être multi-
régions.
Dans ce contexte, un groupe de ressources est un conteneur logique
destiné à faciliter la gestion du cycle de vie d’un regroupement de
multiples ressources, comme dans le cas d’une application construite
autour d’un site Web, d’une base SQL Database et d’une machine
virtuelle.
59
La solution proposée pour le déploiement et la configuration d’un
groupe de ressources est déclarative afin de faciliter la configuration
des ressources, de leurs dépendances, de leurs interconnexions, de la
gestion d’identité entre ces ressources, et de leur facturation. Elle se
fonde sur l’utilisation d’un modèle baptisé « Azure Template » qui va
pouvoir garantir l’idempotence, simplifier l’orchestration, la gestion du
cycle déploiement, le retour sur une version antérieure.
Ces templates sont implémentés en JSON et peuvent donc être gérés
dans un contrôleur de code source. Ils peuvent être directement édités
depuis une extension d’édition JSON disponible dans Visual Studio 2013.
De multiples templates sont déjà disponibles dans la galerie de
templates de ressources Azure. Pour les « récupérer », on peut s’appuyer
sur le code suivant :
$templateFile = "C:\temp\template.json"
Add-AzureAccount
Switch-AzureMode -Name AzureResourceManager
Get-AzureAccount
Get-AzureResourceGroupGalleryTemplate | Format-Table Identity
Save-AzureResourceGroupGalleryTemplate -Identity Microsoft.WindowsServer2012R2Datacenter.0.2.26-preview -Path $templateFile
60
Le fichier correspondant est composé de multiples sections, l’une
décrivant les paramètres (« parameters ») du fichier template, l’autre les
ressources Azure associées au modèle.
Visual Studio permet également, grâce à une extension baptisée
« Azure Resource Manager Tools, de générer les scripts de déploiement
et les fichiers JSON associés à une topologie Cloud cible.
61
Lorsqu’il s’agit de ressources Azure de type « Machine virtuelle », la
solution proposée avec « Azure Resource Manager » est extensible
grâce à l’utilisation du « VM agent » qui permet d’installer et gérer des
extensions pour interagir avec la VM, à l’emploi de Windows
Management Framework V5 (DSC, OneGet) au sein de la VM, ou à la
mise en œuvre de solutions comme Puppet, Chef, Ansible, Salt, par
exemple, dans le cas de Machines virtuelles Linux.
Il devient alors possible de déployer d’un simple click une application
composée de multiples ressources depuis le nouveau portail Azure
(disponible en preview à l’adresse : https://portal.azure.com)
Pour les systèmes non Windows, Microsoft fonde sa stratégie DevOps sur
l’utilisation de technologies Open Source reconnues par le marché,
comme Puppet (Puppet Labs) et Chef (Opscode) dont les capacités
fonctionnelles sont relativement similaires.
62
5. Stratégie de branching
Il peut s’avérer complexe de gérer et faire évoluer efficacement des
fichiers sources lorsque plusieurs développeurs travaillent simultanément
sur des mises à jour de fichiers correspondant à différents états et
différentes versions du logiciel (correctifs, évolutions fonctionnelles,…).
Un élément clé du contrôle de version est donc la capacité à créer des
branches qui permettent un développement simultané de ces mises à
jour tout en assurant l’ordre et la cohérence des versions.
Classiquement, on retrouvera trois branches de code : une branche
« Main », une branche « Release » correspondant au code en
production (pour les hotfixes) et une branche « Dev » pour l’ajout de
nouvelles fonctions.
La génération du code à destination du pipeline de déploiement passe
d’abord par une étape de fusion du code au niveau de la branche
Main.
6. Pipeline de déploiement
Le pipeline de déploiement joue un rôle clé dans le Continuous Delivery
en offrant une visibilité sur l’état d’avancement de l’application et sur
les goulots d’étranglement dans le processus de livraison.
Beaucoup de systèmes utilisent le code source contenu dans le système
de contrôle de version comme l’élément de référence permettant la
transition entre les différentes étapes de la production logicielle. Le
code est alors compilé à plusieurs reprises dans différents contextes :
pendant le processus d’intégration, lors des tests de validation,… et
pour chaque déploiement cible.
Cette approche est contraire à deux principes importants :
Le premier principe est de maximiser l’efficacité du pipeline de
déploiement afin d’obtenir les retours des différentes équipes dès
que possible. La recompilation ne respecte pas ce principe, car
elle peut prendre du temps, surtout pour les applications
complexes donnant lieu à beaucoup de tests automatisés.
Le deuxième principe est de toujours s’appuyer sur le même
livrable : mais chaque fois que le binaire est généré, nous courons
63
le risque que certains changements soient introduits, comme un
changement de librairie ou de configuration dans la chaîne de
compilation, et que le fichier binaire mis en production soit
différent de celui testé. Les fichiers binaires déployés en production
doivent être exactement les mêmes que ceux qui ont été validés
au cours des tests d’acceptation.
Il est donc préférable de construire les binaires et de les conserver une
fois qu’ils ont été validés, pour permettre de les acheminer dans le
pipeline de déploiement.
Un important corollaire de ce principe est qu’il doit être possible de
déployer ces binaires sur chaque environnement, ce qui oblige à
séparer ces binaires, qui restent identiques quelque soient les
environnements, de la configuration qui diffère entre ces
environnements.
7. Release Management
La gestion des livrables suppose la mise en place d’outils permettant
d’échanger les données appropriées dans un format cohérent et
exploitable. Elle doit également offrir la capacité de recréer le même
ensemble d’objets en cas d’erreurs de production.
64
Idéalement, il ne devrait y avoir aucun transfert entre les différentes
équipes du livrable en parallèle du système mis en place. Les éléments
correspondant aux livrables devraient donc être globalement partagés
dans un référentiel unique commun contenant les différents livrables
(binaires, dépendances, fichiers de configuration, fichiers de
déploiement, fichiers de test et résultats associés).
Ce référentiel devrait offrir un contrôle de version, ainsi qu’un tableau
de bord permettant de suivre l’état d’avancement du déploiement des
différentes versions des applicatifs déployés) comme le propose
Microsoft Release Management.
Il faut également un outil permettant de construire et gérer un pipeline
de gestion des livrables dans lequel développeurs et responsables
système vont pouvoir définir les actions et critères de déploiement, de
vérification et de validation avec contrôle manuel ou automatique. Ce
pipeline devrait pouvoir utiliser des objets partagés et communs.
Idéalement il devrait être totalement automatisé.
65
La définition du pipeline de déploiement et de la configuration associée
peut être gérée directement depuis Visual Studio 2013 grâce à
l’extension « Release Management for Visual Studio 2013 ».
V. Optimisation des ressources
La virtualisation des machines est le fondement du Cloud Computing tel
que nous le connaissons. Dans ce contexte, l’optimisation des
ressources peut donc être assurée par :
Des solutions permettant une gestion unifiée des ressources
virtuelles, qu’elles soient à demeure ou dans le Cloud (comme le
66
permettent des solutions comme System Center ou des
alternatives fondées sur des technologies tiers-parties).
L’autoscaling des services de compute PaaS, IaaS ainsi que des
Web Sites ou des Web Jobs, ainsi que des services de base de
données via l’API Azure SQL Database Elastic Scale.
Il semble qu’un nouvel axe d’optimisation soit à considérer aujourd’hui.
En effet, les grands acteurs du Cloud public s’intéressent de plus en plus
aux containers (comme nous l’avons évoqué précédemment), ainsi
qu’aux solutions permettant de les gérer plus efficacement. Parmi
celles-ci, le projet Open Source Docker suscite une forte adhésion.
Docker se fonde sur les mécanismes de container LXC, une technologie
de virtualisation sous Linux.
Si le container d’application offre de multiples analogies avec celui du
transfert maritime (empaquetage de tout type d’application et de ses
dépendances, exécution sur n’importe quel environnement,
isolation,…), Docker, lui s’inspire directement de son homologue
portuaire en facilitant le chargement et le déchargement de ces
fameux containers, sa finalité étant de garantir une cohérence et une
simplification des modèles de déploiement.
Un container Docker se présente comme un répertoire intégrant les pré-
requis lié à l’exécution d’une application. Chaque container est isolé
des autres containers qui peuvent s’exécuter simultanément sur le
même système. Cette approche offre une meilleure utilisation des
ressources et permet d’envisager une plus grande densité
d’applications.
Un container est créé à partir d’une image Docker. Docker permet ainsi
aux développeurs de créer, personnaliser et composer des images
d’application accessibles en lecture seule et de les télécharger vers des
référentiels privés ou publics (Docker Hub), participant ainsi à la
construction de tout un écosystème que les acteurs du Cloud pouvaient
difficilement ignorer…
Ainsi, Microsoft propose de déployer des environnements Dockers sur
des machines virtuelles Ubuntu ou CoreOS déployées dans Azure et
offre un outil Open Source de visualisation des clusters Kubernetes pour
gérer des containeurs Docker à grande échelle.
67
Côté Windows, en complément du Client Docker, une nouvelle
technologie de container sera incluse dans la prochaine version de
Windows Server pour laquelle Microsoft proposera également une
implémentation Open Source de Docker. Il deviendra alors possible de
gérer des applications composées sur la base d’images Linux et
Windows depuis le même environnement Docker client. Enfin, les
images Docker Hub seront fédérées dans la MarketPlace du nouveau
portail Azure.
VI. Amélioration de la qualité et de la disponibilité
L’amélioration de la qualité et de la disponibilité des services est offerte
par différentes composantes de l’offre Azure.
1. Haute disponibilité du réseau
Microsoft Azure Traffic Manager permet de contrôler la distribution du
trafic utilisateur sur les services spécifiés (services Cloud ou Web Sites
exposés ou non dans Microsoft Azure), en appliquant un moteur
configurable sur la base de stratégies pour les requêtes DNS ciblant les
ressources qui peuvent s’exécuter dans de multiples DataCenters.
68
2. Haute disponibilité des données
La géo-réplication est nativement disponible pour les bases Azure SQL
Database Premium. Cette fonction est conçue pour des applications
nécessitant des fonctions de haute disponibilité ne se limitant pas au
périmètre d’un seul DataCenter. Avec cette fonction, il est possible de
créer jusqu’à quatre bases secondaires accessibles en lecture et
déployées dans différentes régions. Ces bases secondaires sont
maintenues comme des copies en continu de la base primaire.
3. Services de supervision
Avec la réduction de la durée d’un cycle de production logicielle
induite par la mise en œuvre d’un processus de « Continous Delivery », il
devient encore plus important de recueillir des informations techniques
en phase de tests, mais aussi en production.
L’application doit pouvoir s’adapter en permanence aux besoins de ses
utilisateurs et il est nécessaire de s’assurer que les services proposés
fonctionnent comme prévu. Il existe de multiples de solutions pour
assurer la supervision de la performance et de la disponibilité des
services, et le suivi des exceptions.
Parmi les produits disponibles sur ce créneau citons des solutions Open
Source comme Zabbix et Nagios ou propriétaires comme System Center
Operations Manager (SCOM), Visual Studio Online Application Insights,
ainsi que la composante Insights du nouveau portail Azure. Ces
mécanismes sont clé pour améliorer en permanence l’application. Ils
permettent de garantir la qualité du service proposé en continu.
Application Insights est une composante de Visual Studio Online qui
offre la possibilité de définir des tableaux de bord pour avoir une vue
d’ensemble de l’application qui regrouperait de multiples
composantes.
69
Avec Visual Studio Online Application Insights (ou l’un des autres
systèmes de monitoring applicatif comme AppDynamics ou New Relic),
il est également possible d’observer le système d’un point de vue
applicatif, afin de constater un éventuel dysfonctionnement ou une
perte de disponibilité et même de faire le lien avec la version du Build
correspondante ou la ligne de code concernée grâce à Visual Studio
Online.
Visual Studio Application Online Application Insights permet l’affichage
des informations de performances et de disponibilité des applications
en considérant la connectivité à ces applications depuis des points
d’observation localisés dans le monde entier et définition de seuils
d’alerte. Cette affichage est maintenant intégré dans le nouveau
portail Azure, comme l’illustre la copie d’écran suivante.
70
Le portail permet également de superviser les sites hébergés en
proposant des métriques sur les performances et l’utilisation de
l’application, et en offrant un accès rapide aux fichiers de logs des
requêtes et aux diagnostics de panne…
La collecte d’informations au moyen de mesures externes peut
également être réalisée à l’aide de produits tels que System Center
Global Service Monitor.
4. Load testing
Deux cas fréquents d’utilisation des tests de charge existent :
- Pour valider une infrastructure cible avant une mise en production :
s’assurer que l’infrastructure et l’application vont supporter la charge
utilisateur visée
71
- Pour assurer une qualité en continu de l’application : s’assurer
quotidiennement qu’il n’y ait pas de régression en termes de
performances de l’application afin de pouvoir réagir immédiatement
en cas de soucis
L’application déployée aura donc fait l’objet de mesures permettant
de garantir son bon comportement en charge avant même d’être mise
en production.
Les tests de charge permettent de vérifier que la solution fonctionne
correctement avec un grand nombre d’utilisateurs. Le périmètre
couvert par ces tests regroupe :
• Les tests caractéristiques de performances : comment la réactivité
de l’application est affectée en augmentant la charge
• Les tests de stress : comment la solution gère les niveaux extrêmes
de charge
• Les tests d’évolutivité : comment la solution réagit en fonction du
modèle de « scaling » (« scale-up » ou « scale out »)
• Les tests de durée : comment se comporte la solution si une charge
est appliquée sur une période prolongée de test
• Test de la continuité d’activité : comment la solution gère une mise
en échec partielle de son infrastructure logicielle ou matérielle.
Les tests de charge dans Azure peuvent être implémentés grâce à
Visual Studio et Visual Studio Online en s’appuyant sur des injecteurs
directement montés dans Azure. Grâce à ce service, il est possible de
se concentrer sur la définition des tests : Azure et Visual Studio Online
fournissent l’infrastructure nécessaire à leur exécution.
72
VII. Continuous learning
1. Hypothesis-driven development
Le développement piloté par les hypothèses se construit comme une
série d’expériences visant à déterminer si un résultat escompté sera
atteint. Le processus est réitéré sur jusqu’à ce qu’un résultat souhaitable
est obtenu ou jusqu’à ce que l’idée soit considérée comme non viable.
La solution implémentée pour répondre à un besoin est décrite comme
une hypothèse sur le nouveau produit ou le service en cours de
développement, sur le business model, sur la façon dont le code
s’exécutera et comment il sera utilisé par le client. Ce principe
expérimental s’applique également dans le développement piloté par
les tests qui consiste à d’abord écrire le test, puis utiliser le test pour
valider que le code est correct. Il offre la possibilité de mesurer le résultat
de l’expérimentation et d’acquérir de l’information sur l’expérience qui
a été menée, de façon à faire évoluer le développement en intégrant
ces connaissances.
Sur le plan technique ce type de démarche peut être complété par des
solutions permettant de recueillir des retours d’expérience de la part des
73
utilisateurs (Workitems de type Feedback, intégration UserVoice via les
ServiceHooks de l’API REST de VSS).
La logique peut également être appliquée sur des tests en production
dans le contexte de scénarios A/B Testing ou de Canary Releases. Le
nouveau portail Azure permet d’ailleurs de définir des tests en
production pour les Azure web sites.
74
2. Supervision des usages via télémétrie
La mise en place de mécanismes de supervision technique et de
télémétrie permet de savoir comment les solutions sont utilisées et la
façon dont elles fonctionnent.
Application Insights est disponible aujourd’hui dans deux versions :
• Application Insights composante de Visual Studio Online (VSO)
• Application Insights inclus dans Microsoft Azure Preview
Aujourd’hui, les deux versions permettent de superviser les applications
Web, mais seule la version VSO permet de superviser les applications
Windows Store and Windows Phone.
Quoiqu’ayant un périmètre plus réduit (le Web), la nouvelle version
(Azure Preview) propose certaines optimisations :
• L’absence de nécessité d’installer un agent : le collecteur de
données est intégré au projet et installé lorsque l’on déploie
l’application.
• Une analyse plus poussée des métriques et événements
• Les APIs de tracking ont également été modifiées.
Instrumenter une application peut se faire directement depuis Visual
Studio en installant l’extension « Application Insights ». Celle-ci permet
d’automatiser la création de l’application dans le portail Applications
Insights VSO, et de spécifier la configuration (en particulier les
caractéristiques des profils d’utilisation, et le profil actif) décrite dans le
fichier ApplicationInsights.config.
Lorsque le complément Application Insights est ajouté à un projet de
développement d’application pour le Store, la génération du code
nécessite alors de cibler la plateforme (x86, ARM ou x64). L’ajout de
l’extension n’ajoute pas les assemblées permettant d’instrumenter
l’application dans les références du projet. Toutefois, cela présente
l’avantage de cibler les versions souhaitées depuis le Nuget Package
Manager.
Dans le cas d’une application Windows Store, il suffit de se limiter à
l’ajout de
75
• Application Insights Core API : les fonctions permettant la
transmission des informations de télémétrie.
• Application Insights Telemetry API for Windows 8.1 Store
applications.
Pour initier la session de télémétrie, il faut explicitement la démarrer dans
le code, en utilisant l’identifiant de l’application.
public App() { InitializeComponent() ; Suspending += OnSuspending; ErrorManagementService.Init() ; ClientAnalyticsSession.Default.Start("Identifiant de l’application") ; }
Le suivi de la durée d’exécution d’un ensemble de tâches s’appuie sur
un objet de type TimedAnalyticsEvent que l’on peut donc déclarer
avec une portée globale sur l’application (par exemple en l’exposant
comme propriété au niveau de l’App).
public static TimedAnalyticsEvent TimedAnalyticsEvent { get; set ; }
Par défaut, Windows 8 interdit la remontée des données vers
Applications Insights. Il faut donc explicitement autoriser ces transferts.
Visual Studio notifie alors le développeur du succès de l’envoi du
premier message de télémétrie.
76
L’onglet Streaming Data du portail Application Insights VSO permet alors
d’afficher la durée des tâches instrumentées et la remontée
d’exceptions sérialisées au format JSON.
La démarche est similaire pour une application Web. Les données liées
à l’usage du site peuvent être affichées dans le nouveau portail Azure.
77
VIII. Chaîne de production logicielle « Microsoft »
Le schéma synthétise les différentes composantes d’une chaîne de
production logicielle entièrement fondée sur des produits et des
technologies Microsoft.
78
Conclusion
Le Cloud et le développeur sont-ils compatibles ? La réponse est
clairement oui. Le développeur doit cependant s’adapter et acquérir
de nouvelles compétences, ainsi que des bonnes pratiques liées à
l’environnement Cloud. Mais ce pré-requis s’applique à l’entreprise
toute entière. Et il remet en question le rôle des départements IT, car il
est maintenant possible de transposer dans le Cloud toute une partie
de l’infrastructure. En contrepartie, le Cloud permet aux différents
acteurs du système d’information de se concentrer sur leur métier en
accroissant ainsi la valeur ajoutée des différents services.
Le Cloud est au cœur de l’IT : le déploiement des infrastructures, la
gestion opérationnelle, la mobilité, le DevOps. Il sera donc
systématiquement présent, à différents degrés, sur les nouveaux projets.
Son utilisation doit, bien sûr, être pragmatique et répondre à des besoins
réels.
Pour les startups, la question ne se pose pas ou peu. Le Cloud permet
notamment de ne pas investir lourdement sur l’infrastructure et d’être le
plus flexible possible.
Plus généralement, sur une chaîne de production logicielle
(environnements de développement de type ALM, approche DevOps,
référentiel, etc.), le Cloud est précieux pour tous ceux qui souhaitent
éviter de perdre des heures à déployer et à configurer des
environnements complexes. Ce n’est pas au développeur de déployer
une plate-forme de tests ni de la maintenir. L’objectif est de se
concentrer sur son travail, sa valeur ajoutée.
Se posent toutefois de multiples questions comme le niveau de
disponibilité des services (SLA), le coût de possession et d’exploitation,
ou l’adhérence technique que l’on pourrait avoir envers le fournisseur
de services Cloud. Dans un contexte .Net, Visual Studio, Windows, le
choix d’Azure sera naturel, particulièrement sur les services Active
Directory, SQL, Visual Studio Online… Mais l’ouverture vers le monde
Open Source, la dimension hybride, le support natif de multiple
79
environnement DevOps permettent au développeur de se tourner vers
la plateforme Azure pour des projets bien plus hétérogènes…
80
Références techniques
Architecture
http://azure.microsoft.com/en-
us/documentation/articles/architecture-overview
Architecture blueprints
http://msdn.microsoft.com/dn630664
Cloud Design Patterns
http://msdn.microsoft.com/en-us/library/dn568099.aspx
MS OpenTech et DevOps
http://msopentech.com/blog/project-categories/DevOps
Azure PowerShell
http://msdn.microsoft.com/en-us/library/windowsazure/jj156055.aspx
Desired State Configuration
http://technet.microsoft.com/en-us/library/dn249912.aspx
Déployer une configuration DSC sur une VM Azure
http://www.powershellmagazine.com/2014/04/02/pushing-desired-
state-configuration-to-an-azure-vm
Livre blanc de Marc Mercuri, Ulrich Homann et Andrew Townhill : «
Failsafe: Guidance for Resilient Cloud Architectures »
http://msdn.microsoft.com/en-us/library/windowsazure/jj853352.aspx
Ouvrage de Jez Humble et David Farley : « Continuous Delivery : Reliable
Software Releases through Build, Test, and Deployment Automation »
81
