Jusqu’à présent, les principales motivations d’adoption du Cloud computing sont les coûts (économie et modèle) et la flexibilité apportée (rapidité de provisioning, élasticité à la demande). L’étape suivante pour ces entreprises consistera sans aucun doute à se recentrer davantage sur leur cœur d’activité et à apporter plus d’innovation. Voici quelques exemples de cas d’usage de demain.

Le Cloud computing comme incubateur

L’un des usages émergents est l’utilisation du Cloud public en tant qu’incubateur. Prenons le Big data par exemple : le Cloud est une excellente opportunité pour les entreprises qui souhaitent éprouver et  expérimenter ces nouvelles technologies pendant un Proof-Of-Concept (POC), quitte à rebasculer ensuite sur un hébergement on-premise pour la phase de mise en production.

Auparavant, réaliser un POC nécessitait d’investir sur des infrastructures, de contractualiser pour disposer de licences de test, de prendre en compte les délais de mise en œuvre. Désormais, les fournisseurs Cloud proposent des offres prêtes à l’utilisation immédiatement et facturées selon l’usage qui en est fait.

Le modèle économique Cloud se prête parfaitement à ce cas d’usage et favorisera demain l’innovation technologique.

Le Cloud comme promesse d’une meilleure qualité de service

La disponibilité des applications critiques reste un enjeu majeur des DSI aujourd’hui. Les infrastructures utilisées doivent pouvoir répondre aux aléas qui surviennent, tels que les incidents ou les pics de charge. C’est l’une des promesses du Cloud, qui se concrétisera demain grâce à plusieurs leviers.

Prenons l’exemple du Plan de Reprise d’Activités (PRA) permanent. Il s’agit de répliquer l’application plusieurs fois et de simuler en continu, via un loadbalancer, la perte de l’une d’elles. Ce mécanisme permet de garantir une meilleure disponibilité du service.

Autre exemple, pour les sites web worldwide, il sera possible de répliquer les infrastructures sous-jacentes dans les différents datacenters du fournisseur et de diriger les utilisateurs qui s’y connectent en fonction de leur localisation géographique. Cette fois-ci, c’est le temps de réponse qui sera optimisé.

Dernier exemple, les entreprises commencent à implémenter des applications pour lesquelles l’infrastructure qui l’héberge pourra d’elle-même s’étendre ou se réduire en fonction des connexions réelles, voire s’éteindre en période d’inactivité. Ce mécanisme de « scale up / scale down » permet à la fois de réduire les coûts (dans un modèle de facturation à l’usage), mais également de garantir une disponibilité optimale en cas de forte activité. Cela se traduit techniquement par l’évolution des ressources même des serveurs ou de leur nombre, en fonction des socles installés dessus, mais nécessite surtout des applications dont le design est spécialement étudié pour.

Une accélération du cycle de vie des applications

Côté PaaS, de nombreuses évolutions sont encore à venir, visant principalement à réduire le time-to-market des applications, via une simplification de leur déploiement.

L’approche par containers est un premier levier visant à répondre à cet objectif. Le marché s’oriente vers des plates-formes capables d’exécuter du code quel que soit le serveur d’application sous-jacent. Cela est rendu possible par l’utilisation de containers, qui embarquent le code, l’application et les binaires du serveur d’application, et sont exécutables sur tout environnement d’exécution. Des solutions se développent pour faciliter la création et la gestion de ces containers, Docker par exemple.

Ainsi les entreprises n’auront plus à choisir entre des offres PaaS proposant  un serveur d’application ou un autre, l’utilisation de containers permettra d’exécuter le code quel que soit l’environnement utilisé. L’approche par containers est un premier levier visant à faciliter le déploiement d’applications sur les offres PaaS.

Le second moyen qui se démocratise est l’utilisation d’un gestionnaire de configuration qui permet d’automatiser le déploiement de composants logiciels. Cette industrialisation peut se faire à l’aide d’outils comme Chef, Puppet, CFEngine… et apporte de nombreux bénéfices. Ces outils en pleine expansion permettront ainsi d’accélérer le cycle de mise en production des applications pour suivre plus facilement les évolutions applicatives demandées plus fréquemment par les Métiers.

Cela ne pourra toutefois pas se faire sans une adaptation du cycle de vie des applications, pour adosser les usines logicielles aux offres PaaS qui les hébergent, et une adaptation de l’organisation et des processus existants. C’est justement l’objectif de l’approche appelée  « DevOps », qui se caractérise par une coopération étroite entre la maîtrise d’œuvre, les équipes chargées des développements, et celles de l’exploitation. Il n’y a par exemple pas d’intérêt à ce qu’une nouvelle fonctionnalité soit demandée chaque semaine et effectivement développée, si les mises en production de l’application ne sont prévues que tous les 6 mois. L’objectif de cette méthode est donc de prendre en compte dès le lancement d’un projet applicatif les besoins fonctionnels en amont, afin d’aligner ensuite les fréquences de mise à disposition de nouvelles fonctionnalités et celles de mise en production.

De nombreux cas d’usage seront rencontrés demain et les exemples présentés ici n’ont pas tous le même degré de maturité : il existe déjà quelques POC réalisés sur des plateformes Cloud, alors que la mise en œuvre du mécanisme de « scale up / scale down » reste aujourd’hui une promesse difficilement réalisable. Quant à l’évolution du cycle de vie des applications, et à l’industrialisation de leur déploiement, on voit que cela se fera une période plus longue, car une transformation des processus, des compétences et des équipes au sein de la DSI seront également nécessaires.

Cet article Cloud computing : les cas d’usage de demain est apparu en premier sur RiskInsight.

Qu’implique le déploiement automatisé ?

Un des avantages attendu est l’uniformisation des habitudes de travail de toutes les équipes ; cela implique inévitablement de changer ces au préalable les dites habitudes. Tous les acteurs des projets concernés sont affectés : MOE, MOA bien sûr, mais aussi les gestionnaires de services, les exploitants ou infogérants, et même les utilisateurs finaux qui participent aux tests. Ce changement d’habitude peut se faire progressivement, au fur et à mesure de l’implication pratique des équipes : d’abord la MOE et la MOA, et ensuite les autres équipes jusqu’à la production.

Pour que les habitudes deviennent uniformes, il faut aussi que la plate-forme de déploiement soit disponible en amont, prête avant que chaque équipe en ait besoin, et surtout qu’elle gère les fonctionnalités dont chaque équipe aura besoin.

Il peut aussi y avoir des aspects contractuels à traiter, notamment avec l’exploitant. Un exploitant qui facture à l’acte ne sera pas forcément enclin à coopérer à la mise en place d’un outil destiné à réduire drastiquement le nombre d’actes impliqués dans une installation !

Tout ceci implique qu’il faille un pilotage par le haut, et qu’il faut donc convaincre la direction du bien-fondé d’un projet de déploiement automatisé avant sa finalisation. Surtout dans un grand SI, il arrivera toujours un moment où la persuasion ne suffit pas, et il faudra imposer certaines façons de faire : ce n’est pas possible sans l’appui de la direction.

Le jeu en vaut-il la chandelle ?

Nous avons vu en première partie les gains qualitatifs et organisationnels qu’on peut attendre d’un déploiement automatisé : principalement une certaine indépendance vis-à-vis du réalisateur, une qualité technique maîtrisée, des déploiements rapides et sans risque, des habitudes communes à toutes les équipes. On aboutit ainsi à la possibilité de mettre en place des cycles rapides, avec peu de friction technique dans les allers-retours entre l’expression d’un besoin et sa mise en œuvre effective.

On reconnaît ici un aspect facilitateur d’un des principes de l’agilité : l’acceptation du changement. S’il est simple de mettre en œuvre des modifications (ce qui ne préjuge pas de la complexité de réalisation des modifications), si la distance entre un projet tel qu’il est sur le poste d’un développeur et le même projet livré de façon à être utilisable par les équipes de recette, c’est un élément de friction en moins pour des itérations rapides dans le processus de développement. La maîtrise de la qualité, notamment par des tests automatisés, réduit de plus les risques liés aux changements, et accroît d’autant l’agilité du projet.

On reconnaît également des aspects d’une autre méthodologie : le mouvement devops. Traditionnellement les objectifs de stabilité du SI s’opposent aux besoins de changement ; le mouvement devops encourage la coopération entre équipes dans le but de réduire cette opposition. Le déploiement automatisé s’inscrit tout à fait dans cette démarche : avec le partage des habitudes, les changements apportés au SI tiennent compte des exigences d’exploitation dès le début, et la stabilité ne vient plus de l’absence de changement mais de la maîtrise de ses impacts.

Qui n’a pas rêvé d’un SI adaptable, où toutes les équipes travaillent ensemble pour le bien de l’entreprise ? Le déploiement automatisé ne répond pas à toutes les problématiques derrière ce rêve, mais il constitue un bon premier pas : même s’il s’agit d’un projet à forte teneur technique, ses avantages sont tangibles à la fois pour la direction SI et pour les métiers. Il ne reste plus qu’à trouver les bons acteurs !

Cet article Le déploiement automatisé : au delà des gains, quels en sont les enjeux ? est apparu en premier sur RiskInsight.

Le déploiement automatisé : une évolution naturelle

Le déploiement automatisé, c’est l’utilisation d’une infrastructure  permettant de déployer un livrable sur un environnement cible sans intervention humaine autre que le geste initiant le déploiement. Cela implique l’automatisation de tous les gestes techniques : préparation des plates-formes, mise en place ou mise à niveau de l’environnement de base, installation des composants de support des livrables, installation des livrables eux-mêmes. D’autres aspects doivent également être pris en compte : les migrations de données et la gestion de la disponibilité notamment.

Il s’agit typiquement d’une extension de plate-forme d’intégration continue (PIC) : une fois qu’on a un SI capable de produire des livrables de façon automatique, il semble logique de vouloir les installer de façon automatique. Au-delà de la production de livrables, une PIC permet également d’exécuter des tests automatiques ; avec des tests automatisés suffisamment poussés, on pourrait  même envisager de pousser le raisonnement encore plus loin, jusqu’au déploiement en continu… Mais nous n’en sommes pas là, revenons plutôt à notre déploiement automatisé !

La plate-forme d’intégration continue, source de nombreux bénéfices

Commençons par quelques-uns des avantages d’une PIC, puisque le déploiement automatisé repose généralement dessus.

La maîtrise des sources. L’intégration d’un projet dans une PIC nécessite ses codes sources. Le fait de passer par un outil que vous hébergez pour produire les livrables vous garantit de disposer des sources correspondant aux livrables installés, et de modifier les sources et produire de nouveaux livrables, même sans le support de la MOE à l’origine du projet.

La maîtrise de la qualité. Puisque vous disposez des sources, il est possible de les auditer, et généralement une PIC propose un certain nombre d’outils appropriés. Ceci permet de mesurer la qualité du projet, si ce n’est de la maîtriser, avec notamment des tests automatisés et des métriques paramétrées selon vos normes.

L’indépendance. Cette double maîtrise du processus de construction et du code du projet permet une réversibilité plus simple, et donc une certaine liberté vis-à-vis du réalisateur.

6 bonnes raisons d’adopter le déploiement  automatisé

Il est vrai que  le déploiement automatisé apporte ses propres avantages.

1 – Des déploiements sans risque. Un déploiement automatisé est reproductible, sans intervention manuelle. Le risque d’erreur d’inattention ou d’imprécision dans les procédures d’installation et leur mise en œuvre s’en trouve fortement réduit.

2 – Des déploiements rapides. Sans intervention manuelle, on évite les temps d’attente : vérifications d’informations, saisies, procédures de contrôle manuel… On peut en outre paralléliser un grand nombre d’opérations, entre plusieurs serveurs et au sein d’un même serveur. Les temps d’installation sont réduits, et par conséquent les indisponibilités des applications lors des mises à niveau.

3 – Des habitudes communes. L’utilisation d’une seule procédure de livraison pour toutes les plates-formes permet d’imposer des habitudes de travail communes à toutes les équipes, du développement à la production. Ceci réduit les risques au passage d’un environnement à l’autre et permet aux différents intervenants de partager un vocabulaire commun.

4 – Des cycles rapides. Avec des déploiements rapides et peu risqués on peut envisager des mises  à jour fréquentes  des applications installées. Le gain dès les phases de développement et de recette est conséquent : d’une part les cycles développement-recette-intégration ont un coût d’installation plus faible à amortir, et peuvent dès lors être raccourcis ; et d’autre part les corrections en recette peuvent être vérifiées immédiatement, ce qui réduit aussi les cycles détection-correction-vérification des défauts.

5 – Des installations déléguées. Si l’outil de déploiement est accessible à tous, ce qui ne représente pas nécessairement un risque puisque les droits sur les environnements cibles peuvent être cloisonnés, la gestion des déploiements peut être déléguée. Ainsi,  en phase de recette la MOA peut provoquer des installations, sans impliquer les équipes de développement, d’intégration ou d’exploitation.

6 -Plus de sauvegardes ! Une fois qu’un déploiement se fait sur un serveur vierge en quelques minutes, il n’est plus nécessaire de prévoir de le sauvegarder ! Tout serveur qui ne contient pas de données irremplaçables peut simplement être réinstallé en cas de désastre. L’installation d’un serveur complémentaire peut aussi être une réponse aux questions de tenue à la charge…

Si les gains sont considérables, les enjeux sont à étudier avec attention : cela fera l’objet d’un prochain article.

Cet article Le déploiement automatisé : optez pour des mises en production sereines ! est apparu en premier sur RiskInsight.