19 Sep 2016

Votre stratégie Cloud (PaaS, Docker, Hybrid) a des impacts sur les dévs !

Un peu de météo sur le “as a service” (Intro)

1-zb5jot03zfcwy55jvul7nwL’évolution actuelle de l’IT tend à utiliser des services dit “managés”, qui fonctionnent tout le temps, dans le “Cloud” et dont on n’a pas besoin de se soucier. Par exemple chez les fournisseurs de Cloud public on peut nommer: Elastic Cloud, Mongo Atlas, DynamoDB, Google App Engine. Tout le monde ne suit pas ce mouvement, mais c’est une tendance qui gagne du terrain. J’en parlais il y a peu:

Il y a 2 approches intéressantes qui utilisent ce type de services “managés” : soit les déléguer complètement à des tiers, soit les mettre en place soit même sur son infrastructure, en utilisant des plateformes comme Open Shift, OpenStack, Kubernetes et/ou Rancher et ainsi créer son propre PaaS privé.

D’un côté, sur notre Cloud privé, on est responsable de la mise en place de la plateforme qui permettra de créer les services “managés”, de l’autre, sur un Cloud public, on remet cette responsabilité à un tiers. Dans les 2 cas, il faudra des équipes pour gérer ces services. Dans le cas où l’on créé sa propre plateforme, l’équipe sera un peu plus conséquente et se composera de développeurs qui réaliseront des solutions pour que d’autres développeurs d’applications métier puissent déployer leur code.

Pour simplifier les choses (sic), en plus de ces 2 approches, d’autres mouvements de fond se dessinent :

  • Certains préfèrent que leurs applications s’appuient sur des services managés au niveau de l’OS, avec l’utilisation des conteneurs comme Docker par exemple. Dans ce cas, la maîtrise des couches bas niveaux est primordiale (OS, réseau, plateforme, load balancing, config et annuaire distribué…). Le dev peut créer un environnement cible en local sur son poste de travail et c’est un gros plus. On peut également configurer très finement tous les aspects techniques des environnements.
  • D’autres font le choix de s’appuyer sur les services managés au niveau applicatif avec des PaaS par exemple. Dans ce cas, le développeur se concentre sur le code applicatif et doit s’intégrer avec les services mis à disposition. Dans ce cas de figure, le dev ne peut pas vraiment créer d’environnement en local. Par contre, il se soucis moins des couches basses, c’est le service managé qui s’en charge. Les possibilités de configuration sont limitées à celles que les services managés exposent.

Ces stratégies sont compatibles entre elles, on peut faire son PaaS privé et utiliser des conteneurs pour déployer ses applis, et on peut aussi utiliser un Cloud public et utiliser des services managés. Mais on peut également créer un PaaS privé avec ses propres services managés ou encore déployer des conteneurs sur un Cloud public. Et on peut aussi utiliser des services managés comme AWS Lambda et les lier à d’autres services dans son cloud privé…

1-4ql-i2a2da-3ygeyg36u0qBref, on peut hybrider toutes ses stratégies ensembles: Avoir une application pour laquelle on réduit notre périmètre de responsabilité au maximum (Public Cloud + services managés publics) et une autre application où on gère un maximum de chose par nous même (Private Cloud + services managés faits maison). Et cerise sur le gâteau, on peut aussi hybrider ces approches au sein d’une même application, où chaque composant suit une stratégie différente. On peut choisir la stratégie qui correspond le mieux aux besoins du projet ou du module de l’application. Après, il faut savoir gérer la cohérence d’ensemble dans son SI.

Il existe également d’autres approches, comme celle de continuer sur une approche IaaS classique voir même d’aller jusqu’à gérer soit même son datacenter avec ses propres baies. Même si elles sont loin d’être insignifiantes en proportion, je les trouve moins intéressantes et c’est pour cette raison subjective que je les passe sous silence.

OK, mais dessine moi un mouton! (Exemples)

Comme c’est un peu flou et pour tenter de s’y retrouver donnons quelques exemples avec des produits existants; plaçons nous du point de vue des équipes de développement applicatif, celles qui consomment les services managés. Ce monde se découpe suivant ces 2 stratégies:

  • La responsabilité des services managés côté public ou côté privé
  • Les besoins en compétences d’infrastructure dans les équipes de devs

Ce qui donne comme légende de lecture :

  • Dev Infra — : Les besoins de connaissances Infra côté dev son moindres
  • Dev Infra ++ : Les besoins de connaissances Infra côté dev son importantes
  • PaaS Privé : On délègue la responsabilité de gestion des services à un service interne
  • PaaS Public : On délègue la responsabilité de gestion des services à un tiers

On obtient ces quelques exemples:

1-wcyjgtlyq_nrgqqb5dppcw

Exemples pour positionner des solutions et des approches suivant les 2 axes: Besoin de maîtrise des devs sur l’infra // Responsabilité du PaaS en interne vs externe

Pour simplifier, on considère dans cette répartition que pour un cloud privé, les équipes qui mettent à disposition des services managés sont différentes des équipes de développement applicatif. C’est pour cette raison que les équipes de développement applicatif ont moins de besoins en compétences d’infra. Si elles utilisent un OpenShift Container Plateform par exemple; une équipe dédiée s’occupe d’opérer la plateforme de services managés sur le cloud privé et les équipes de développement d’applicatif consomment les services mis à disposition. Bien entendu, l’entreprise a quand même besoin de compétences en infrastructure dans l’équipe dédiée au cloud privé.

Bref, il existe énormément de solutions différentes, privées, publiques, hybrides, extensibles, interconnectées, compatibles. Difficile à suivre et impossible de déterminer quelle est la meilleure approche. Tout dépend du contexte, des objectifs, des équipes en place… ce qui est certain c’est que cela impacte fortement les développeurs.

Mais en quoi ça impacte les devs ?

Souhaite t-on que les développeurs d’applications utilisent des services managés (public et/ou privés) ?

  • Avantage : moins de responsabilités pour les devs => plus de focus sur le code métier ?!
  • Inconvénient : perte de maîtrise OPS des devs => en cas de retour sur une stratégie +OPS, ça risque de piquer!?

Souhaite t-on utiliser des services PaaS sur un Cloud public ?

  • Avantage : Focus quasi-exclusif sur le code métier
  • Inconvénient : Limitation du champ d’intervention des devs => Certains peuvent fuir ce désengagement “forcé”

Souhaite t-on que les développeurs applicatifs utilisent des services managés au niveau OS (containers par exemple) ?

  • Avantage: pas de limites dans les options offertes, tout peut fonctionner sur le poste de dev, maîtrise totale de la stack
  • Inconvénient : besoins de maîtrise OPS importante chez les devs => moins de focus sur le code métier ?

Bref, l’idée était de montrer que la stratégie Cloud mise en place peut poser des questions importantes pour l’entreprise et qu’elle peut avoir un impact fort sur le métier des développeurs.

  • Quelle stratégie les développeurs préfèrent ? Posons leur la question.
  • Quelle stratégie facilite ou non le recrutement de nouveaux profils ?
  • Préfère t-on des développeurs qui maîtrisent la totalité de la stack technique utilisée ou qui focus sur les besoins métiers de l’entreprise ?

Et les devs, ils en pensent quoi ?

Les besoins de l’entreprise ne sont pas forcément les même que les besoins des développeurs. Pourtant, mieux vaut aligner ces besoins!

On peut se dire : “peu importe”. Mais les développeurs de qualité sont précieux, il faut les conserver et en attirer d’autres. Une des manières d’atteindre cet objectif est de mettre en place un environnement de travail qui leur convienne.

De nombreux développeurs préfèrent mettre les mains dans toutes les couches de l’application et prennent du plaisir à définir leur image Docker, le load-balancing, le fail-over… D’autres ne veulent pas entendre parler d’OPS et veulent se concentrer sur le développement applicatif… Certains aiment varier les plaisirs, c’est mon cas.

J’ai eu la chance de travailler dans des contextes avec des stratégies cloud différentes; PaaS Public, PaaS Privé, Datacenter interne, et je pense que c’est une bonne chose de ne pas s’enfermer dans une seule stratégie pour le moment en tant que développeur. Toutes ces approches sont intéressantes !

Les développeurs les plus connus, reconnus techniquement et les plus expérimentés ont une préférence pour une approche où ils doivent gérer un maximum de choses: Rancher, Docker, Netflix OSS, Consul, Kubernetes. Les approches PaaS public les attirent moins car il y a moins de choses à apprendre, il “suffit” de consommer la plateforme.

Nous faisons tous des choix qui peuvent complètement changer le contexte de travail du développeur, avec leurs avantages et leurs inconvénients:

  • La stratégie full PaaS public promet beaucoup de choses et pourrait permettre de consommer le PaaS comme on consomme de électricité; simplement, sans soucis, clé en main et avec une facture en fin de mois.
  • La stratégie full PaaS privé permet des gains certains de flexibilité mais demande un investissement conséquent dans l’exploitation de son propre Cloud. En cas d’échec de la stratégie Cloud public, elle mitige le risque de la fuite des ressources OPS et des développeurs les plus barbus.
  • Toutes les solutions intermédiaires sont envisageables…

Est-ce que comme le maréchal ferrant en son temps avec l’arrivée de l’automobile, le DEV+OPS sera obligé de se reconvertir ? On va le savoir bientôt 😉

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-kn4ewk751blsjismh1ybta

Share