BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Les équipes et les Microservices chez Amazon

Les équipes et les Microservices chez Amazon

Le pattern Microservice est en train de changer la façon de construire une application et la structure des équipes est extrêmement importante pour réussir à créer et à exploiter ces Microservices. Chris Munns a expliqué dans une présentation à la conférence "I Love APIs 2015", comment gérer les Microservices et la mise à l'échelle des équipes chez Amazon.

Munns, Business Development Manager pour les DevOps chez Amazon, s'est référé à Wikipedia pour la définition des microservices, mais a aussi accentué sur quatre contraintes qui sont :

  • Avoir un seul rôle
  • Etre connecté via des APIs
  • Echanger en HTTPS
  • Etre des boites noires face autres microservices

Lorsque qu'il a comparé les microservices avec les services SOA, Munns a décrit quelques différences bien distinctes :

Microservices SOA
  • Composants très petits et en grand nombre
  • La logique métier reste à l'intérieur du domaine du service
  • Utilise un protocole simple de communication, comme HTTP avec du XML ou du JSON
  • Orienté API avec les clients/SDKs
  • Moins de composants, mais plus sophistiqués
  • La logique métier peut être partagée sur plusieurs domaines
  • Un Enterprise Service BUS (ESB) est utilisé pour la communication entre les services
  • Middleware

Les équipes Services teams, appelées "two pizza teams", terme utilisé par Amazon pour désigner ce type d'équipe, possèdent leurs propres "primitives" qu'elles managent, qui comprend la planification du produit, les travaux de développement et les activités opérationnelles, ainsi que le support client. Elles ont la pleine responsabilité d'elles-mêmes et sont également responsables de la maintenance et de l'activité opérationnelle au jour le jour, aussi connu sous cette expression "tu le développes, tu le déploies". Cela signifie que les personnes à la QA, en astreintes et les opérations existent bien dans une équipe Service. Mais Munns tient à remarquer que certaines de ces personnes dans ces rôles peuvent être amenées à être partagées dans plusieurs équipes.

Même si cela implique énormément de liberté pour les équipes, elles sont tout de même soumises à suivre des normes élevées et à être autonomes grâce aux :

  • Formations approfondies
  • Pattern & à la pratique qui ont évolué après plus de 20 ans d'expérience
  • Revues régulières des métriques, à la fois métiers et techniques
  • Partage des nouveaux outils, services et technologies par des experts internes

En prenant en compte ce qui est important pour Amazon, comme travailler avec des petites équipes et des microservices, Munns conseille aux autres têtes des organisations de suivre le même chemin en incluant :

  • La culture ; soulignant que les propriétés et les responsabilités vont de pair, et que les grandes équipes changent généralement plus lentement que les petites équipes. Insister sur l'excellence, et non sur la façon de le faire.

  • La pratique ; soulignant l'importance de l'intégration continue (CI) et le continuous delivery (CD), ainsi que la simplification des tâches opérationnelles.

  • Les outils ; pour le point mentionné ci-dessus, pour le management des infrastructures, pour les métriques, le monitoring, la communication et la collaboration.

Munns souligne enfin l'importance d'établir un modèle pour les services et les clients, empêchant ainsi une organisation de refaire le même travail, comme pour la communication, les autorisations, la prévention des abus et le service discovery. Il note également que les métriques sur les builds, les hosts, les services, etc., sont importantes, surtout celles concernant la santé de l'infrastructure et le respect des SLAs et bien d'autres.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT