Les innovations en informatique sont permanentes, depuis le début de son existence. Chaque période a vu ses révolutions technologiques, des grands systèmes (Mainframe) au distribué, des architectures n-tiers au serverless.
Comment s’y retrouver et être efficace dans ce contexte ? Comment arriver à proposer des architectures pertinentes quand tout change, tout le temps ? Nous allons essayer d’y répondre ensemble dans ce chapitre :)
Choisissez vos innovations technologiques raisonnablement
Comparer sur une base « équivalente » est toujours complexe, il faut donc prendre le temps de bien identifier et évaluer les avantages et inconvénients de chaque solution avant de vous lancer, qu’elle soit serverless, cloud privé ou public, micro-services…
Utilisez la méthode proposée en regardant :
L’ensemble des axes fonctionnel, applicatif, infrastructure et opérations (sujet trop souvent mis de côté) ;
Une vue projet (ex : calendrier, RACI) ;
Une vue coûts et organisation (ex : disponibilité des ressources, compétences).
Grâce à cela, vous devriez être en mesure de prendre une bonne décision.
Attention aux décisions vendues comme évidentes
On peut prendre le cas des fournisseurs de Cloud public qui vous diront que le coût global de leurs offre est inférieur à celui des équivalents hébergés dans vos datacenters. C’est peut-être vrai, si on considère l’arrêt complet de toutes les ressources partagées existantes (réseau, stockage, services d’opérations,...). Or, de nombreux cas d’usages justifient encore de maintenir des ressources on premises (localement, dans le datacenter) : sensibilité des données, dépendance à des fournisseurs, utilisation de technologies incompatibles avec le cloud (mainframe, versions de logiciels obsolètes ou exotiques)...
Sur le sujet du Cloud Public toujours, il faut bien comprendre qu’on achète un service : c’est au souscripteur de s’adapter aux « bonnes pratiques » (!), pas au fournisseur. Ce truisme est un changement profond en informatique professionnelle. On avait l’habitude d’adapter, voir parfois de bidouiller, les solutions pour les mettre en cohérence avec les attentes des entreprises.
Ici, il va falloir adapter nos architectures en fonction de ce qui est offert par les différentes fournisseurs. Attention d’ailleurs au fait que le contenu des services évolue souvent très vite : versions supportées, coûts, fonctionnalités ne sont pas gravées dans le marbre et peuvent changer du tout au tout, remettant complètement en cause les architectures définies. Également, les SLA proposés sont souvent difficiles à décrypter, et ne garantissent pas toujours une réelle disponibilité.
J’ai un exemple récent où j’avais choisi de ne pas m’appuyer sur un service PaaS de base de données, car le type de sauvegarde proposé ne me permettait pas de répondre à ma politique de sauvegarde. Le temps que l’application soit développée, l’offre a évolué pour intégrer une rétention supérieure, compatible avec mes exigences de services. J’ai pu donc faire évoluer mon architecture, en accord avec les développeurs et le chef de projet, pour intégrer le service PaaS à la place d’une base de donnée hébergée en datacenter. J’ai bien entendu documenté ces 2 étapes dans des décisions d’architectures.
Récoltez l'information aux bons endroits
Entourez-vous d'experts
Mais comment faire pour connaître toutes ces nouveautés et les évolutions ?
C’est bien entendu impossible d’avoir la connaissance en temps réel de l’ensemble des offres de tous les fournisseurs du marché, même en se limitant aux leaders.
Ma préconisation est avant tout de vous appuyer sur les différents experts, conformément à la vision du métier de l’architecte que j’ai décrite dans la première partie. Impossible pour vous, dans votre rôle transverse, de tout connaître sur tout. Par contre, à vous de faire appel au bon spécialiste, qui peut lui même être architecte, compétent sur l’ensemble des services offerts par un éditeur ou un un type de service de façon transverse sur plusieurs fournisseurs. Il pourra vous épauler dans la réflexion en prenant une partie de l’analyse (comme le ferait un architecte d’entreprise sur la couche fonctionnelle).
Toutefois, vous constaterez parfois que même les experts ne sont pas toujours à jour sur l’ensemble des offres et des nouveautés. À vous de poser les bonnes questions pour comprendre les contraintes et l’adéquation aux besoins.
Gardez votre propre culture des services à jour
Ceci dit, pour poser les bonnes questions, il faut un minimum de culture sur les modèles de service et les fonctionnalités proposées. Pour cela, je vous recommande de suivre les formations en ligne proposées par tous les grands acteurs, présentant notamment leur vocabulaire et les différents architectures-types qui existent. Si vous êtes amenés à travailler de plus près avec une plateforme, des formations architectes certifiantes existent et peuvent valoir l'investissement, afin de gagner en autonomie sur certaines réflexions.
Si vous vous sentez l’âme bidouilleur, je ne peux que vous recommander d’expérimenter, à travers la mise en œuvre d’architectures simples, ce qui vous permettra de vous rendre compte concrètement des différentes possibilités offertes et de la complexité (ou non) des choix à réaliser.
Je vous recommande également de participer au maximum aux meetups, qu’il soient devops, cloud ou autre, pour échanger avec vos pairs sur leurs retours d’expérience de ce qui peut fonctionner ou non. Gardez bien votre esprit critique affûté, car il arrive parfois que ce qui est présenté ne soit pas tout à fait représentatif de la réalité .:)
Ne vous précipitez pas
Dernier conseil sur le sujet innovation en général : à moins d’y détecter un avantage stratégique pour votre projet, il est souvent préférable d’attendre au moins quelques mois avant d’utiliser un nouveau service ou une nouvelle fonctionnalité. Les cycles très courts de déploiement impliquent une phase de test limitée, et donc des des bugs qui peuvent mettre à mal vos solutions.
En résumé
Dans ce chapitre, nous avons évoqué ensemble comment rester à jour dans un monde qui change très vite : s’appuyer sur les spécialistes, lire la presse, se former, participer aux meetups et expérimenter, tout en gardant son oeil critique et comme guide, la méthode. Facile, non ? ;)
Il me reste maintenant à insister sur un dernier sujet avant de conclure ce cours : la place prépondérante qu’ont le réseau et la sécurité dans un monde « cloudisé » et où données comme traitements peuvent être répartis partout dans le monde.
