1 Sep 2016

Quels sont les impacts du “as a service” pour les développeurs ?

De nombreuses entreprises, produits et équipes utilisent les services Cloud (PaaS ou SaaS), dits “managés”, pour leurs développements IT. Vous savez, ces services qui gèrent automatiquement la scalabilité, le failover, la sécurité… et sans avoir à gérer les serveurs nécessaires. Ils sont de plus en plus utilisés, si on en croit les croissances actuelles et à prévoir dans ce domaine. Certains utilisent des solutions “as a service” publiques, d’autres créent leur propre solution au sein de “leurs” datacenters. De nombreuses personnes se mettent en ordre de marche pour que ce type de services soient utilisés. Mais qu’est ce que ça change pour les devs ? On a plusieurs fois évoqué cette question.

Bye Bye Old DataCenter, Welcome as a service stuff

On découp(l)e plus souvent en fonction des besoins de scalabilité et des usages

Une compétence sera particulièrement demandée dans les projets qui utilisent des services managés; Il faut savoir créer un édifice qui réponde aux besoins à partir de briques connectées les unes aux autres, comme avec des LEGOs, sauf qu’on n’a pas de plan de montage et qu’on peut inventer nos propres briques. On avait déjà cette mission avant quand il s’agissait de choisir une base de données, un framework web, un middleware… Maintenant ces choix sont simplement plus fréquents parce qu’on découpe plus souvent et ils sont également plus nombreux car il y a encore plus de manières différentes de faire. Le développeur doit faire plus souvent des choix qui sont plus difficiles et plus complexes.

Microservices architecture beauty

Pour chaque nouveau service à développer on se demande:

  • Est-ce qu’il doit être déployé à part ou intégré avec d’autres ?
  • Quelles parties doivent scaler indépendamment ?
  • Quel cycle de vie pour ce service ?
  • Quelle solution utiliser pour développer ce service ?
  • Comment l’exploiter, le monitorer, le sécuriser ?
  • Comment le connecter aux autres ?
  • Comment gérer les indispos et les latences ?
  • Comment automatiser son déploiement ?
  • Stateless ? Statefull ? (private joke)

On a TOUJOURS eu ces questions à se poser, bien avant l’arrivée du “as a service” et du SOA. Mais avant, les réponses étaient souvent plus simples : on ajoutait le service au même endroit que les autres. Classique. Maintenant, on a plus souvent tendance à créer plusieurs modules qui sont liés entre eux.

(Je ne juge pas le choix d’archi; bien souvent une archi classique est satisfaisante, et il arrive que des projets soient complexifiés sans besoin réel, simplement pour apprendre et suivre le mouvement. Parfois une approche est plus adaptée, parfois c’est l’autre, parfois les 2. Peu importe.)

Du coup, là où on avait l’habitude d’avoir un schéma de fonctionnement basé sur quelques “monolithes” avec webapp, BDDs, load balancer, firewalls et 2–3 zones réseaux, maintenant on peut avoir des myriades de services interconnectés tel un final de feu d’artifice mais sur un schéma Visio.

monolithes to micro services

Cela complexifie donc l’architecture du SI mais c’est en contrepartie de certaines promesses de scalabilité automatisée, de taux de dispo élevés, de baisse de coûts ou de météo plus clémente (sisi).
Il faut donc être à l’aise avec l’architecture des services, ce qui nécessite de connaître certains principes d’architecture; le développeur devient donc un peu plus architecte encore, voir un peu plus ops selon le contexte. Ce qui est certain, c’est que pour les développeurs curieux, c’est une opportunité intéressante pour apprendre.

Le développement devient plus complexe et nécessite plus de réflexion et de créativité. Le développeur doit se former à l’architecture!


On doit donc intégrer plus souvent différents services ensemble

Le métier de développeur comprends donc de plus en plus de tâches d’intégration de services, car pour chacune des questions posées précédemment, les réponses sont souvent différentes et c’est autant d’intégrations spécifiques à mettre en place.

Tech20Stack20Complexity20r2628129_c2c28c1e461745e315e7388e07e841fb
Pour chaque nouvelle solution as a service, il faut l’appréhender, se documenter, la tester pour la maîtriser et pouvoir l’utiliser sur son projet. Il existe des dizaines (centaines) de fournisseurs avec pour chacun des dizaines (centaines) de services; il est quasi impossible de tous les suivre. Heureusement diront certains et malheureusement pour d’autres; souvent une entreprise utilise une petite partie de ces services disponibles, chez un ou deux fournisseurs. Au final, le dev doit, encore plus qu’avant, se tenir informé des évolutions et des nouveautés.


Capture

Un bon conseil: Vu la complexité des choix à faire, laissez du temps aux développeurs pour apprendre et tester les différentes options, sinon ils feront leurs tests en prod directement et vous ne voulez pas que votre prod devienne un bac à sable!?


Il faut utiliser les SDKs et les APIs des différentes solutions pour les faire communiquer avec notre code. Les langages utilisés et compatibles ne sont pas forcément les même que ceux avec lesquels on a l’habitude de coder. Ponctuellement, un dev .NET peut se retrouver à (re)coder en Python et un dev Java va se mettre à coder en NodeJS. On a donc plus tendance à utiliser différents langages dans un SI, on peut toujours avoir des langages qui sont majoritairement utilisés, mais on peut aussi avoir des briques d’intégration ou des modules complets codés dans d’autres langages ponctuellement. Les connecteurs à ses services sont souvent propriétaires et proposent de nombreuses options et possibilités qu’il faut maîtriser également. Le dev doit donc, encore plus qu’avant, être capable de s’adapter aux SDKs et d’apprendre de nouveaux langages. Rien d’insurmontable mais il va falloir changer un peu ses habitudes.

1-bziq833efK4SSMmXRBUO3g

En contrepartie de ces contraintes, ces solutions nous apportent des services qui réduisent la charge de travail sur d’autres aspects. Par exemple, utiliser un service de déploiement de Webapp en PaaS demande de comprendre son fonctionnement et son API, mais en échange il permet de ne pas (trop) se soucier des aspects de scalabilité par exemple. Pas besoin de gérer le failover du serveur web. Pas besoin de (trop) stresser en cas de passage média dans l’émission Capital. Pas de problème de découverte à chaud par le load balancer de l’arrivée de nouveaux noeuds dans le cluster. Bref, cela permet de signer un traité de paix entre les Devs et les Ops qui se mènent une guerre sans merci depuis des décennies sans jamais se comprendre.

Le dev dans les nuages demande de maîtriser différents nouveaux services et parfois différents langages. Cela demande du temps d’apprentissage supplémentaire! En échange, certaines problématiques sont reportées sur la responsabilité du fournisseur.

Le développeur peut donc se concentrer sur le développement applicatif comme on dit, mais c’est en délaissant ses connaissances de plus bas niveaux et en montant en compétences sur les APIs spécifiques des services managés utilisés. C’est surement l’impact le plus important sur le métier de développeur! Le futur?

Parfois le fournisseur de services peut être interne voir, le développeur peut être son propre fournisseur de services managés. Dans ces cas, c’est différent mais l’impact sur le métier est également très important! On verra les impacts des différentes stratégies Cloud dans un autre article.


On doit donc absolument automatiser le déploiement pour s’y retrouver

Avant déjà, l’automatisation était importante pour la qualité; maintenant c’est devenu obligatoire! Pour créer un nouvel environnement “manuellement”, avec des clics ou des lignes de commandes, cela peut nécessiter des heures en suivant une procédure fastidieuse et source d’erreur. C’est ingérable. Forcément, plus on a de services différents, plus leur installation va nécessiter d’actions différentes. Donc automatiser devient obligatoire et permet de créer un nouvel environnement en peu de temps.
1-Uk_qC79bOQdoeqxVDWZLWQIl devient fortement déconseillé de modifier manuellement un composant d’un environnement. Chaque environnement comprend de nombreux composants, si on les modifie manuellement, il est impossible de s’y retrouver. Il faut donc tout automatiser, pas seulement la création des composants mais leur mise à jour, leur remplacement ou tout autre changement d’état.

Les environnements doivent le plus possible être immutables, cad ne pas être modifiables une fois créés, on doit préférer leur suppression et recréation plutôt que de les modifier. Plutôt que d’aller mettre à jour les différentes instances de l’application avec une nouvelle version du code, on crée de nouvelles instances qui viennent remplacer les précédentes puis on supprime les anciennes instances. Et un environnement doit pouvoir être complètement détruit et reconstruit en quelques minutes de manière automatisée. Adieu les erreurs humaines manuelles, bonjour le debuging de provisonning automatisé.
Par exemple, on peut automatiser le déploiement avec Cloudformation chez AWS ou avec Terraform sur Google Cloud pour atteindre ce but ultime; la régénération totale de son SI en une commande ❤

Le dev nécessite, encore plus qu’avant, d’automatiser le déploiement en utilisant des solutions dites d’Infrastructure as Code.


On doit gérer plus d’environnements de développement

Avant on réservait des ressources pour les environnements de développement, ces ressources étaient constamment disponibles et on les payaient donc tout le temps. Quel que soit l’usage des CPUs, des disques, du réseau le prix était le même.

Bon les gars, on a besoin d’un carte bleue pour tester un nouveau service hipster.io!

Bon les gars, on a besoin d’un carte bleue pour tester un nouveau service hipster.io!

Maintenant ces services sont facturés en fonction de leur utilisation réelle, en fonction du nombre d’appels en lecture ou en écriture, en fonction de l’espace disque utilisé, de la bande passante réseau consommée. Certains services ne coûtent même RIEN quand ils ne sont pas utilisés.
En théorie, cela permet de baisser les coûts des environnements de développement. En pratique, comme le nombre de projets de développement en cours explose avec la transformation numérique, c’est difficile à vérifier :troll_face:

OK les coûts sont variables et non fixes, quel rapport avec le développeur ?

En fonction de la stratégie cloud utilisée, dans le cas où l’on s’appuie sur des services PaaS publics par exemple, le développeur peut avoir besoin de ressources chez le fournisseur pour développer et il ne peut pas forcément tout faire fonctionner localement sur son poste de travail. (Ceci n’est pas applicable si vous pouvez tout faire fonctionner localement avec des conteneurs par exemple.)

Il existe souvent des SDK de développement pour émuler les services PaaS en local mais cela reste une émulation et ce n’est pas toujours le cas. Par exemple, pour DynamoDB, il vous faudra DynamoDB local pour coder sur la plage de Bali sans 4G. Pour un service utilisant API Gateway et les Lambdas par contre, vous pouvez utiliser serverless ou apex qui impactent un peu la manière de développer.

Du coup, pour tester son code dans des conditions proches de la cible, le développeur va régulièrement le déployer sur un environnement dédié rien qu’à lui. Et chaque développeur peut avoir besoin de le faire. Mais comme les coûts sont maintenant variables, il faut avoir conscience du coût relatif aux actions qu’on réalise.

  • Si j’oublie de supprimer un environnement de dev pendant plusieurs jours et qu’il consomme du budget, ça peut faire déraper la facturation.
  • Si je fais un traitement long ou un tir de performance sur un environnement, la facturation va augmenter également.

Le développeur doit donc intégrer cette notion du coût variable des ressources dans son quotidien. Cela peut passer par des tableaux de bords de suivi des coûts qui est affiché dans le bureau, en passant par des alertes en cas de dépassement d’un seuil de consommation, ou une limitation de l’usage de certains services.

Outre l’aspect coût, le nombre d’environnement peut facilement augmenter si on manque de rigueur. Quand on utilise uniquement son poste de travail pour développer, chacun en est responsable. Mais si chaque développeur a son(ses) environnement(s) chez un fournisseur, il faut s’accorder sur des règles de fonctionnement pour s’y retrouver. Définir des règles de nommage, des permissions, mettre en place des tags sur les ressources etc. Exactement ce qu’on faisait déjà avant mais avec encore plus d’environnements à gérer.

Le développeur devient responsable des coûts de facturation induits et doit être gestionnaire de ses environnements.


TL;DR: L’utilisation du as a service pour le développeur modifie son quotidien en faisant appel à ses compétences d’architecture, d’intégration, d’automatisation et en lui demandant plus de rigueur, de curiosité et de créativité. Des qualités déjà requises auparavant mais qui sont tout particulièrement nécessaires maintenant. L’entreprise doit se transformer en une école permanente pour que ses développeurs puissent suivre ces transformations. Le développeur a plus de responsabilité et donc plus de pouvoir!

PS: Abonnez vous au RSS du blog, retrouvez nous sur twitter avec le hashtag #AxaWebCenter et suivez moi sur @cyril_lakech, linkedin ou medium 😉

1-liddJxLbhaZ5-HCqjsQTLw

Share