Skip to content

Ahead in the cloud (Stephen Orban)

  • Déjà il y a trop de préfaces.
  • Collection de blog posts, pour la plupart du même auteur (Stephen Orban, CHE chez AWS). La dernière partie présente des retours d'expérience d'autres ingénieurs.
  • Destinés à des leaders IT en haut de l'échelle organisationnelle
  • Très orienté AWS
  • Mais c'est quand même très intéressant

Foreword (Andy Jassy)

  • CEO de AWS
  • Avant AWS, Amazon gérait Merchant.com, un ensemble d'API pour aider des clients e-commerces à créer leur site
  • 80% du temps était perdu à créer de l'infra de base et 20% à créer ce qui différenciait vraiment les clients
  • Avant AWS: coût fixe d'infra. Avec AWS: coût variable.
  • Il n'y a pas que les boites privées qui font du cloud, le public aussi
  • Notion de "difficulté" à migrer des applis: les faciles (lift an shift), les difficiles (nécessite une re-architecture)

Foreword (Adrian Cockroft)

  • En 2000, l'idée de louer des serveurs via internet à des clients est apparue chez Sun, mais a été écartée parles leaders IT
  • Quand AWS a été lancé, les leaders IT de Sun n'aimaient toujours pas l'idée
  • En 2009, Netflix avait le choix de construire sa propre infra avec des datacenters distribués OU d'utiliser AWS. C'est le premier exemple d'utilisation du cloud large scale.
  • Ca ne marchera pas dans votre entreprise si la culture n'est pas adaptée. La bonne culture unlock DevOps + Talent
  • "on ne peut pas copier Netflix car on n'a pas les profils pour ça." Réponse: "d'où pensez-vous que viennent les profils de Netflix? D'entreprises comme la votre"

Foreword (Mark Schwartz)

  • Service d'Immigration USA: culture de la prudence extrême et de la zero prise de risque. Ce genre de culture apparait car il s'agit d'une réaction qui fonctionne bien à un certain type d'évènement (ex: ne pas apparaître dans un journal où on parle mal du Service d'Immigration USA).
  • Mais dès qu'il y a un changement dans l'industrie, ce ne marche plus: nouveau concurrent etc
  • Donc il faut être agile
  • Agilité = DevOps, Microservices, Containerization + Cloud (le cloud étant le paramètre le plus important)

Preface

  • Le livre sert à aider les leaders IT à savoir comment s'approprier cette technologie
  • Racontage de vie de l'auteur

Introduction

  • les entreprises doivent s'adapter ou périr (Kodak vs appareils photo numériques, Blockbuster (location de DVD) vs Netflix).
  • le point commun de ceux qui ont péri: ne se considéraient pas comme un entreprise "de technologie" / pas de transformation digitale. Contre-exemple: General Electrics qui a réussi sa transition.
  • But du livre: aider à influencer les gens vers le cloud.
  • fun fact: la croix rouge a réussi à monter un centre d'appel en 48h (ouragan Harvey) grace à AWS

Chapter 1

  • explications sur les premières tentative de l'auteur à faire migrer ses entreprises vers le cloud: échec à Bloomberg (sceptiscime, utilisation d'un cloud privé où tout le monde perd son temps à provisionner des trucs), début de réussite à Dow Jones (2 mois pour créer une application pilote entièrement cloud)
  • 1er argument de la migration cloud: arrêter de créer des infra basées sur la capacité de pic.
  • People, Process, Platform
    • People: former les gens existants (conférences, contribuer à l'open source, BBL avec d'autres entreprises) + engager de nouvelles personnes (en évitant les vieux qui ont la mentalité "je faisais comme ça dans mon entreprise")
    • Process: passer en livraison continue + chaque département fixe ses objectifs de KPI et en est responsable, avec budget fixe
    • Platform: ne pas construire sa propre infrastructure si on n'est pas très bon dedans, bref CLOUD
  • Les 3 principes pour la migration devops à Dow Jones:
    • la team Infra doit considérer la team Dev comme des "paying customers" : a évité la mésentente et le pointage de doigt entre les 2 équipes
    • automatiser tout et avoir une archi cloud-native (autoscaling etc). Note: ce n'étiat pas un bon principe
    • la team devops n'est pas responsable du fonctionnement / updates d'une appli, c'est la team applicative qui l'est: évite de rendre la team devops goulot d'etranglement ou passe-plat
  • DevOps day: ateliers/formations leadé par la team Devops sur 1 jour (0,5 d'AWS et 0,5 de best practices archi). Plus tard: c'est devenu une méthode d'onboarding pour de nouveaux devops.
  • Lift and shift = migration graduelle en rehostant les applis sans les modifier. Première intuition: c'est + cher que de faire du cloud native!
  • En réalité à Dow Jones = 30% d'économies (pas de changement d'architecture)
  • News Corp: 60% de la migration cloud réalisée en 4 ans, mais ont déjà pu réallouer 100 millions USD au bout de 2 ans

Part I - Etapes de l'adoption (SofA)

  • Projet: le ou les fameux projets avec lesquels on veut faire différemment. Chosir un projet suffisament important pour qu'on s'y intéresse, mais où on peut quand même expérimenter sans se faire virer
  • Fondation: équipe dédiée à la transormation "Cloud Center of Excellence" + "AWS landing zone"
  • Migration: convaincre de migrer les systèmes legacy
  • Reinvention: appliquer les nouvelles ressources découvertes au business entier
  • Cloud first: pas toujours simple de savoir quand viser / se déclarer cloud-first

Chapter 2

  • projet conseillé: une application microservice/service oriented qui est déjà virtualisée
  • il faut s'y attendre: une partie des gens seront enthousiastes, une autre partie sera sceptique
  • notion de shadow IT: des projets IT qui naissent sans approbation de la directon. Source d'innovation mais aussi de risque
  • mieux que shadow IT: le CLOUD Center of Excellence: créer des architectures de référence et les donner de façon transparente aux teams
  • autre exemple de 1er projet: migration sur amazon workspaces

Chapter 3

  • Cloud Center of Excellence ( peut aussi etre appelée DevOps team): fournit des achitectures, best practices, gardes fous etc
  • créer des scripts qui automatisent la construction des architectures de reference
  • conseil: utiliser amazon service catalog pour rendre des Stacks CloudFormation (ndt: cloudformation est AWS only, beware...) dispo en self-service pour les business teams sans qu'ils aient accès à l'AWS console
  • la mentalité "you build it you run it" = une "two pizza team" est responsable de toute l'application = les technos utilisées, la roadmap, la partie opérations
  • la formation et la "transformation de talents" est la partie la plus difficile à réaliser dans une adoption cloud

Chapter 4, 5, 6

Le chapitre 4 est juste un plan, et 5 et 6 correspondent au contenu

  • 5 phases de migration:

    • Evaluer l'opportunite: qu'est ce qu'on peut gagner à migrer? qu'est ce qu'on va faire de l'argent qu'on va économiser? Bref, avoir un but.
    • Découvrir le portfolio et le planning: qu'est ce qu'on peut migrer? dans quel ordre ?
    • Design, migration et validation de chaque application: le cloud center of bidulerie guide les équipes pour les migrations. Quelle est la stratégie de décomissionnement? Etre capable de mesurer la perf / comparer l'avant de l'après.
    • Opérations: blabla
  • autre modèle pour aider à migrer: les 6R

    • Rehosting: (lift and shift). Juste hoster ses anciennes applis dans le cloud, sans modification. Possibilité d'utiliser AWS Import/Export.
    • Replatforming: modifier des parties d'applications, ex: migrer juste les DB dans RDS, migrer vers des technos open-source
    • Repurchasing: changer de produit vers un SaaS
    • Refactoring: le pattern le plus cher (re-architecturer une vieille appli type monolithique pour etre cloud-native/scalable)
    • Retire: jusqu'a 10% du portfolio ne sera plus utile
    • Retain: ne pas tout migrer tout de suite (priorisation, application récemment stabilisée donc pas à migrer etc)

Chapter 7

  • attitude 1: "on ne migrera en cloud que si on re-architecture nos applications pour être cloud-native!"
  • attitude 2: "un data center va fermer, il faut que l'on migre au plus vite" = rehosting simple
  • souvent les entreprises commencent avec l'attitude 1, puis en voyant les couts (ou face à l'urgence) optent pour le 2.
  • conseil: rehoster en priorité les applications qui n'évolueront plus. Tenter de re-architecturer les applications qui ont besoin de nouvelles fonctionnalités où le cloud pourra aider (scalabilité etc)

Chapter 8

pourquoi simplement rehosting / lift and shift est une stratégie court terme gagnante

  • ils ont des SSD
  • possibilité de prendre l'instance maximale temporairement pour couvrir des requêtes mal optimisées, puis revert sur une petite instance une fois que les bugs sont corrigés
  • ajouter facilement un Elasticsearch à son appli
  • hoster des microservices sans se ruiner en infra

Chapter 9

Comment migrer une mainframe sur AWS

  • Rehoster une mainframe telle quelle: Amazon EC2 + Mainframe emulator. Pas de changement de techno: DB2, Cobol etc
  • Pour les batch jobs: commencer par migrer les jobs à low business value mais qui sont très consommateurs
  • Re-architecturing: utiliser des containers, Amazon Simple Queue, machine learning etc

Chapter 10

Réinvention = la dernière étape des "stage of adoption" (SofA)

Comparaison à une fontaine de jouvence pour les entreprises

Part II - 7 Best Practices

Comment porter ce changement dans l'entreprise

  • Apporter un support exécutif: que doivent faire les leaders pour aider leurs entreprises à se transformer
  • Eduquer les équipes: aller au-delà de la peur de l'inconnu
  • Créer une culture de l'expérimentation: faire en sorte que l'échec ne coute pas cher, par exemple avec des ressources IT à la demande et des infra qui se up/down rapidement
  • Choisir les bons partenaires: les partenaires intégrateurs système / consultants digitaux / PaaS / outils évoluent très vite. Ceux qui étaient bons hier ne ne sont peut-être plus aujourd'hui
  • Créer un Cloud Center of Excellence: équipe de personnes dédiées à pousser le changement
  • Passer sur une architecture hybride: le cloud ce n'est pas du tout ou rien, il ya forcément une période de transition
  • Implémenter une stratégie cloud-first: une fois que l'expérience de la team a agumenté, cela peut devenir un impératif stratégique

Best Practice 1: leader

Chapter 11

  • Notion de Chief Change Management Officer (CCMO) - le leader du changement dans l'entreprise
  • Business & Technologie doivent être pris ensemble et non séparément: se demander comment chaque fonction de l'équipe sera impactée. Avoir de l'empathie sur les buts et diffcultés de chaque équipe
  • Communiquer sur les choses importantes + de façon claire
  • Ne pas hésiter à créer / briser des règles: doit venir du leader IT, afin d'éviter que cela soit fait à chaque niveau de l'organisation sans aucun contrôle

Chapter 12

Comment chaque dirigeant voit la migration cloud:

  • CFO (finances): attirés par les coûts plus faibles + payer uniquement ce qu'on utilise. Challenge: comprendre les coûts variables, utilisation des ressources
  • CMO (marketing): attirés par les déploiements plus fréquents + quelles expériences tenter sur une fraction des utilisateurs maintenant que expérimenter ne coûts plus cher ?
  • HR (resources humaines): collaborer avec d'autres entreprises qui sont sur le chemin de la migration également. Quels sont les nouveaux profils à recruter?
  • CEO: créer une vision et utiliser la technologie pour créer quelque-chose qui n'était pas possible avant

Exemples d'actions possibles de leader IT

  • Inviter les exécutifs au déjeuner et écouter leurs frustrations + construire de l'empathie/confiance
  • Utiliser de l'aide extérieure exemple: certifications AWS, DevOps days pour évangeliser les outils et best practices
  • modifier la perception de "IT": chez Dow Jones, ils ne sont plus appelés "IT" mais "technologie"

Chapter 13

Qualités requises du CCMO:

  • Etre capable de présenter la stratégie et la rendre mesurable
  • Connaitre la place de l'équipe actuelle dans cette stratégie
  • Quels sont les points flexibles / inflexibles
  • Rester déterminé
  • Rester patient

  • Donner l'opportunité aux gens de changer de rôle dans l'entreprise par rapport à la migration

  • Différencier les objectifs absolus de ceux qui sont moins figés dans le marbre et le communiquer aux équipes

  • Les difficultés sont des opportunités d'apprentissage

  • Mais ne pas accepter 2x la même erreur
  • Dissiper le scepticisme au plus vite
  • Ne pas laisser la vision être influencée par ceux qui veulent un revert vers le status-quo

Chapter 14

  • Migration cloud = le meilleur moment pour modifier les règles du jeu de l'entreprise
  • Si l'entreprise marche actuellement sur ITIL / ITSM: conserver ce qui fonctionnait bien dans ce process, mais laisser de la place pour les nouvelles règles apportées par la migration cloud

  • Les leviers du changement: Operations, Audit IT, management financier

Operations

  • Créer un service IT qui répond aux besoins clients (internes et externes)
  • Run what you build: process peu traditionnel, qui fait peur mais beaucoup de bénéfices

Audit

  • Les audits sont nos amis (pas nos ennemis)
  • Faire comprendre à tout le monde qu'il faut établir de nouvelles règles
  • Communiquer également avec les auditeurs et leur expliquer le but que l'on cherche à atteindre

Finances

  • Expérience Dow Jones de l'auteur: les dépenses cloud augmentaient plus lentement que l'avancée du décomissionnement de l'infrastructure fixe = a attiré l'attention du service financier et a permis un rapprochement pour optimiser le budget
  • ventiler l'achat d'instances réservées sur plusieurs mois

Best Practice 2: équipe

Chapter 15

  • Transformer les employés sceptiques en employés qui supportent et accélèrent le changement
  • "Vous avez déjà toutes les personnes qu'il vous faut": utiliser les connaissances de l'équipe existante
  • Recruter de nouveaux talents marche aussi, mais à faible échelle (ne scale pas)
  • Certification AWS: toutes les personnes techniques doivent recevoir la certif AWS Technical Fundamentals (1er niveau)
  • DevOps days: montrer régulièrement les best practices, frameworks et modèles de gouvernance cloud
  • Graphique qui montre l'augmentation exponentielle des jobs AWS entre 2012 et 2016 sur une plateforme de recherche de jobs

  • Assister à des evènements cloud-related et écouter les reoturs d'expérience

  • AWS Partners Network: identifier les outils/partenaires qui répondent aux besoins
  • AWS Professional Services: identifier les rôles et les aptitudes nécessaires à exécuter une stratégie cloud
  • AWS Cloud Adoption Framework : bluepirnt gratuit sur la transformation vers cloud

  • La meilleure formation c'est l'expérience = donner l'opportunité aux équipes de travailler sur le cloud (avec contrainte de temps). Exemple: créer une API, hoster un wiki, créer un site...

Chapter 16

Astuces pour CCMO. Il y a beaucoup de répétitions des anciens chapitres: faites passer la certification AWS, démarrer avec un projet basique mais qui a de l'impact quand-même pour voir les bénéfices du cloud, aller aux events AWS, faire des devops days... etc

  • Créer une culture qui autorise l'expérimentation permet de motiver les équipes à apprendre
  • Donner aux équipes la liberté d'implémenter des projets existants de nouvelles façons
  • Créer des objectifs/KPI qui encouragent cette expérimentation: complétion de MOOC, combien de budget a été libéré
  • Contraintes de temps: ajoute un équilibre entre expérimentation et "ce que l'on sait déjà", permet aux équipes de faire des compromis et d'avancer vite au lieu d'être paralysés
  • Ecouter et essayer de comprendre les appréhensions de ceux qui résistent au changement
  • Ne pas avoir peur de donner des nouveaux roles aux gens: permet d'aider ceux qui résistent au changement en leur donnant de nouvelles opportunités

Chapter 17

  • C'est moins cher et plus efficace de transformer/enabler l'équipe actuelle.
  • Obstacle = peur de l'inconnu

Le training doit apporter les choses suivantes:

  • comment utiliser le cloud (opérer, manager et déployer)
  • obtenir un vocabulaire commun
  • prendre des décisions avec les nouveaux outils et plateformes

La certification permet de:

  • savoir qui doit être promu
  • recruter des gens déjà certifiés pour remplir des trous dans l'équipe

Infos sur les formations et certifications AWS ci-dessous:

  • Awareness Days: demander à AWS de venir dans l'entreprise pour 1 jour de propagande sur les bénéfices du cloud + comment devenir Agile
  • Role-based training: des formations différentes pour Architecte, Developpeur et Opérations. Chaque "chemin" inclut des exercices, certifications et spécifiques
  • Formation customizée: travailler de pair avec AWS pour créer une stratégie custom avec une roadmap, et qui part en formation quand
  • Formation online: conseillé lorsque l'équipe connait déjà les bases

Chapter 18

Retour d'experience de la banque CapitalOne (UK) - qui a transformé son équipe "legacy" et qui est aujourd'hui devenue 2% des ingénieurs certifiés AWS

  • Acceptation: l'équipe doit accepter qu'elle peut apprendre des aptitudes cloud.
  • Formation: AWS Technical Essentials pour tout le monde
  • Expérimentation: encourager les équipes pendant qu'elles testent les technologies. Reconnaitre que chacun aura sa courbe d'adoption différente (certains passeront par une phase de désillusion etc)
  • Création de la "2 pizza teams": l'équipe doit contenir les skills suivants. Chez CapitalOne, cette équipe se met à utiliser CloudFormation et Terraform.

    • Réseau
    • BDD
    • Serveurs Linux
    • Applications
    • Automatisation
    • Stockage
    • Sécurité
  • Amener des experts: doivent propager leurs spécialités. Chez CapitalOne, le passage d'un expert de CloudReach a permis la création d'une CI/CD par l'équipe

  • Construire quelque-chose de réel: par exemple une AMI (image AWS) pour l'entreprise. Viser une deadline en semaines pas en mois.
  • Scaler l'équipe: séparer l'équipe qui a gagné de l'expérience en 2 nouvelles équipes, et ajouter de nouvelles personnes dans chacune. Modèle de la mitose cellulaire: continuer à séparer et reformer les équipes pour propager la connaissance
  • Certification: l'auteur insiste sur ce point, et voit une correlation directe entre la certification d'un ingénieur et la construction des applications dans AWS. Note: CapitalOne a même breveté un processus qui permet de mesurer cette transformation/correlation
  • Scaler la certification: 10% de l'équipe certifiée = c'est la masse critique avant que l'effet "réseau" prenne effet. Par exemple: ces ingénieurs amélioreront la manière dont l'entreprise est vue à l'extérieur + veulent travailler avec des entreprises cloud native = l'entreprise se met à attirer du talent
  • Reconnaitre et récompenser l'expertise: fêter chaque ingénieur qui passe sa certif. Chez CapitalOne: création d'un tableau d'honneur.
  • Se challenger soi-même: le CTO de CapitalOne a également passé la certification Associate Architect.
  • Créer un portfolio des nouveaux jobs existants: les nouveaux rôles chez CapitalOne par exemple:

    • Technical Program Manager: agilité, interdépendances équipes
    • AWS Infrastructure Engineer: d'anciens ingénieurs de data center devenus experts AWS, écrivent du CloudFormation/Terraform
    • Developpeur
    • Software Quality Engineer: utilise TDD
    • Security Engineer
    • Engineering Manager: supervision

Best Practice 3: expérimentation

Chapter 19

  • D'après Wired, entre 20 et 50 entreprises sortent de la liste des Fortune 500 chaque année: le turnover est souvent dû à la technologie.
  • Ces dernières années spécifiquement, le cloud est l'enabler: une petite entreprise parvient à chambouler l'industrie. Airbnb, Pinterest, Uber, Spotify n'existaient pas il y a 10 ans.

  • Grace au cloud, l'expérimentation ce n'est pas juste pour les startups

  • L'accès au capital + une position initiale de leader n'est plus la garantie de rester au top
  • Pas besoin d'investir du capital pour expérimenter. Il faut souvent + de temps pour justifier l'investissement que de construire la première version du produit dans le cloud
  • En conséquence l'échec ne coûte pas cher

Chapter 20

  • Informer les stakeholders: quels projets sont considérés comme des expériences + objectif de l'expérience + moyen de mesure.
  • Si le projet a déjà un objectif spécifique défini par les stakeholder, ne pas en faire une "expérience"
  • Demander aux équipes de proposer des idées
  • Ne pas expérimenter si on ne peut pas mesurer
  • Culture DevOps est un plus: run what you build, tests A/B, releases rapides et rollback
  • Ne pas douter de l'équipe: sinon découragement. S'adapter ou aider au lieu de douter. Un leader qu'on veut suivre est un leader qui confiance dans le succès futur de l'équipe
  • Encourager tout le monde à participer: hackathon, proposer aux stakeholders d'aider à définir les mesures. Exemple chez Amazon: ceux qui sont capables de formuler une idée ont le droit de l'implémenter = attirer et retenir les innovateurs et builders
  • Ne pas laisser les expériences ralentir les livraisons!

Best Practice 4: partenaires

Chapter 21

  • AWS re:invent = le nombre d'exposants a doublé entre 2012 et 2015.
  • Avant: les entreprises faisaient des partenariats avec des providers importants et établis depuis longtemps. Maintenant: beaucoup de Fortune 500 font des partenariats avec des providers très jeunes et petite taille
  • Exemples de jeunes partenaires Dow Jones: 2nd Watch, Cloud Technology Partners, Minjar, New Relic, App Dynamics, chef, Puppet, Cloud Endure

Chapter 22

  • Notion de Managed Service Provider (MSP): partenaire IT à qui l'on outsource de l'hébergement / infra vidéo / centre d'appel, monitoring etc...
  • MSP traditionnels tentent de conserver leur business: découragent les clients qui pensent "à l'ancienne" avec des mesages négatifs sur le cloud (mauvaise sécurité, forte dépendance à un seul vendor)
  • Pour prouver cette assertion, l'auteur inclut un mail complet écrit par un MSP à son attention.
  • Chez le MSP Logicworks: les clients s'inscrivent à un "service bot" qui remplace le travail d'install "à l'ancienne"
  • Chez le MSP REAN Cloud: offre aux clients le "bi-modal IT" = permet à la fois de gérer de ITIL legacy et en parallèle la transformation cloud
  • Chez le MSP Cloud Technology Partners: s'identifient à des "Cloud Thérapeutes" et essaient de changer le mindset des clients. Passer de "comment faire pareil que dans mon datacenter??" à "comment créer l'infra qui aidera mes développeurs?"

Chapter 23

  • Certains MSP proposent leur expertise de migration cloud en tant que service = aident à faire la migration puis gardent le contrôle de l'infra créée
  • Mention d'un MSP peu scrupuleux qui facturait 10000$ la création d'un VPC sur AWS au client
  • AWS Managed Service Program audit: liste de MSP qui ont le niveau technique suffisant
  • Encourager ses partenaires actuels à passer le MSP audit

Best Practice 5: CCOE

Cloud Center of Excellence

Chapter 24

  • Composition equipe: dévelopeurs, admin sys, ingé réseau, ops, DBA.
  • Profil: ouverture d'esprit, motivé pour utiliser les nouvelles technos. Le manque d'expérience n'est pas un problème

Chapter 25

  • 3 à 5 personnes
  • évaluer chaque mois l'impact de la team
  • certaines entreprises mettent 1 ou 2 sceptiques dans la team devops afin de les convertir
  • à utiliser avec précaution mais peut être un multiplicateur d'effet: intégrer des leaders influents dans la team
  • La team doit être suffisament haut dans l'orgranigramme pour effectuer des changements impactants

Chapter 26

  • Quelques métriques pour la team CCOE: utilisation des ressources IT, nombre de releases par jour/semaine, nombre de projets affectés

Des points importants à adresser par le CCOE:

  • gestion des rôles / permissions: intégration avec un SSO, AD? Quelles features pour quels environnements?
  • gestion des coûts: est-ce que chaque business unit gère ses propres coûts ou centralisation?
  • comment tagger les instances: par business unit / centre de coût / environnement (dev/staging...) ? Exemple d'utilistaion: stopper automatiquement toutes les instances de dev pendant la nuit.
  • créer des architectures de référence: réutilisable sur d'autres applications du meme type
  • CI/CD
  • dashboards

Un moyen de benchmarker le CCOE: comparer leur output avec le "AWS Well-Architected Framework"

Chapter 27

  • transférer une ressource vers le CCOE: ne pas remplacer son ancien rôle, et transférer la responsabilité vers le CCOE
  • se reposer sur le CCOE pour le choix d'outils / partenaires cloud ainsi que le choix de dispatching (chaque équipe produit choisit les outils dont il a besoin ou le CCOE propose 1 seul standard)
  • définition de l'architecture hybride (situation de transition): par exemple, comment l'archi cloud peut communiquer avec l'ancienne archi on-premise

Chapter 28

Conseils pour intégrer Devops. Cet article est une répétition inquiétante de tous les autres chapitres: automatiser, commener avec une petite equipe CCOE et itérer, utiliser "run what you build" car le cloud retire le besoin d'avoir une team IT centralisée

Difficultés pour adopter Devops dans de grandes organisations: architectures monolithiques, allergie au risque, beaucoup de dette technique

Chapter 29

Le service client est la clé de Devops dans une entreprise

Clients = ceux qui consomment les produits et services d'une organisation devops.

  • Avant: on centralisait la connaissance IT sur une seule équipe.
  • Maintenant: la salle de rédaction télécharge/installe des logiciels tiers car le services IT ne fournissent pas leur propre version en premier. Le marketing font des partenariats avec des tierces parties pour publier rapidement un site web. C'est le Shadow IT
  • Shadow IT = les stakeholders sont insatisfaits ou ne savent pas comment obtenir ce qu'ils veulent de la part de la DSI
  • La DSI Devops doit devenir un enabler et pas un point de friction. Exemple: au lieu de dire "vous ne pouvez pas utiliser cet outil", demander "que souhaitez-vous atteindre comme objectif"
  • Ownership = la responsabilité du produit est sur l'équipe produit, on ne peut pas "botter en touche" à un autre service ou personne = cela crée + de motivation dans les équipes et un meilleur service client

Chapitre 30

Ce que "run what you build" apporte:

  • en IT traditionnel: architecture puis développement d'une solution puis le produit est passé aux ops. Lorsque des problèmes en production surviennent, les entités séparées sont un désavantage, surtout pour trouver la root cause
  • au lieu perdre du temps et de l'attention sur le mur entre dev et ops (ops peuvent avoir tendance à faire des quick fixes, dev peuvent avoir tendance à baisser la barre de qualité): se préoccuper du client et du produit
  • infra as code = les développeurs peuvent le comprendre, donc être plus efficace en intervention sur prod
  • l'application est conçue dès le début pour la production (IT traditionnel: la deadline approche et tout le monde court pour adapter l'application à la prod)
  • autonomie et transparence: les équipes sont proactives (ajout de monitoring, cherchent à prevenir les bugs avant qu'ils arrivent)
  • plus d'automatisation: les developpeurs détestent répéter les taches manuelles
  • clients plus satisfaits: toute l'équipe comprend le client, la connaissance n'est plus limitée à une équipe marketing, + de feedback et d'améliorations produits

Chapter 31

  • Le plus difficile dans la pratique DevOps = démarrer
  • Chez Dow Jones: démarrage DevOps avec 4 personnes et ajout de 1-2 personnes par mois. Au bout de 18 mois, la majorité des ressources IT a migré vers une DevOps team
  • DevOps ne s'applique pas qu'au developpement produit mais aussi: back-office, postes de travail, etc
  • Construire de la confiance: pour certains stakeholder, un produit qui évolue constamment eest un risque
  • Applications déployées globalement / multiple timezones : possible lorsque l'équipe a réussi à automatiser une flotte de ressources multi-régions

Best Practice 6: archi hybride

Chapter 32

Archi hybride:

Aller vers une infrastructure que l'entreprise est capable d'opérer elle-même

  • AWS Virtual Private Cloud / AWS Direct Connect: le moyen de relier une infra hébergée à une infra AWS
  • Idée reçue: il faut rester hybride de façon permanente.
  • Idée reçue: l'archi hybride permet de déplacer facilement une appli entre le mode cloud et le mode hébergé. Attention à ne pas architecturer les applications pour qu'elles soient "compatibles avec les 2" sinon limitation au plus petit dénominateur commun!
  • Idée reçue: l'achi hybride permet de faire facilement du multi-cloud. Nécessite de créer une "glue" pour que l'application fonctionne partout: diminution des gains de productivité obtenus par le cloud. Limitation au plus petit dénominateur commun aussi. L'automatisation permet de diminuer le risque: découpler l'aplication de son infrastructure.

Chapter 33

Expérience chez Dow Jones qui les a propulsé vers une archi hybride:

  • situation initiale: ils ont crée un nouveau service full AWS, mais problème: il doit communiquer avec un AD inaccessible de l'extérieur.
  • En 45 minutes: création d'un réseau virtuel avec AWS VPC, snapshot des instances externes, rapatriement vers le VPC et connexion au AD.
  • création d'une archi de référence réutilisable
  • migration de plusieurs produits similaires en mode hybride grâce à cette archi

Best Practice 7: cloud first

Chapter 34

Comment une entreprise peut se réinventer en se basant sur le cloud

  • Exemples d'entreprises cloud-first: General Electrics a une position hybride, avec GE Oil & Gas qui est le seul cloud-first. Capital One: entièrement cloud-first.
  • impacte beaucoup d'autres services que DSI/IT: finances, légal, achat, équipes produit
  • à première vue: on devrait déclarer une entreprise cloud-first lorsqu'elle a déjà beaucoup d'exppérience dans le lcoud.
  • contre-exemple: Fortune 100 avec 2000 développeurs qui a calculé le bénéfice de 1000 jours/h après formation de son équipe + migration cloud-first

Part III: retours expérience

Collection de retours d'expérience dans des entreprises

Chapter 35

Capital One

  • Migration terminée en xxxx, ranked 1er sur InformationWeek Elite 100 en innovation technologique
  • ont expérimenté avec beaucoup de services AWS + partagent leurs connaissance lors de AWS Re:Invent + partagent leur outillage en open source (Cloud Custodian)

  • 2013-2014: Project / fondation

    • phase d'expérimentation via une équipe nommée "Innovation Lab".
    • Les membres de Innovation Lab sont des ressouces hautement motivées ou qui ont déjà une première expérience AWS
  • 2015: migration

    • ajout d'enviros DEV et test à la partie AWS, et premiers déploiements en prod. 1er investissement financier: Direct Connect. Travail en partenariat avec AWS pour créer une bibliothèque de "Cloud engineering patterns"
    • La demande de personnel AWS augmente: ils créent un CCOE chargé d'auditer les équipes internes et de construire la base en vue de la formation/certification des équipes
    • Au AWS re:Invent 2015: annoncent leur objectif de réduire leurs datacenter (de 8 à 3 en 2018) = rallie toute l'entreprise autour de la simplification de l'infra
    • 100s personnes certifiées AWS Architecte ou AWS Developpeur
    • 1000s personnes formées pour utiliser AWS
  • Optimisation

    • mettent en place la réduction automatique des instances EC2 en fonction de l'utilisation
    • refacto de certaines applis vers le serverless: une équipe type CCOE est remise en place pour aider à migrer vers ce modèle

Chapter 36

Cox Automotive

Produits: applications web et services pour l'industrie automobile

Situation intiale:

  • 40+ acquisitions, 34000 personnes, présence dans 90 pays, 52 data centers
  • La croissance par les acquisitions a crée un parc très hétéroclite: Oracle, produits IBM, Java, .net, Python et MUMPS, en même temps

Migration:

  • Pas de possibilité de migration immediate pour certains projets: exemple, infra pour 2x le pic de trafic du Super Bowl avec un PRA en plus (autotrader.com) = d'après l'analyse de coût défavorable (cout > gains)
  • 2015-2016: le CCOE tests différents cloud providers puis séléction de AWS qui sera utilisé pour tout SAUF les projets trop spécialisés
  • Moment "eurêka": les leaders assistent à l'AWS re:Invent 2016.
  • Best practice principale utilisée: Support Executif
  • Livre conseillé sur le sujet du Cloud: Nicholas Carr - The Big Switch
  • Conseil: ne pas partir de l'hypothèse que tout le monde est sur le même diapason. Si la migration cloud est vue comme seulement un moyen d'économiser OU juste une initiative technologique, ça ne marchera pas
  • Migrer vers le cloud est plus complexe que juste migrer un data center = réfléchir à comment permettre aux équipes d'avoir de la flexibilité et leur éviter les discussions CapEx et OpEx (dépenses d'investissement et dépenses d'exploitation)
  • critères du 1er data center à migrer: utilisé par 1 seule business unit et équipe est à un seul endroit géographique.
  • Les 6R sont utilisés tout au long de la migration
  • Investissement important dans les fondations: formation de l'équipe, transformer les pratiques de sécu, simplifier la CI/CD + tooling, utiliser l'approche API/microservices/architecture de reference
  • A l'heure de l'ecriture du livre, leur migration n'est pas encore terminée

Chapter 37

AQR Capital Management

  • Warning sur les comparaisons de coût (TCO: total cost of ownership). Exemple: comment comparer l'achat d'un serveur physique via un MSP vs l'instance EC2 correspondante? Le serveur physique semblera moins cher.
  • Approche choisie par AQR: considérer les cas où le on-premise serait trop cher (flotte de GPU, cluster map-reduce) et où AWS serait avantageux
  • Entreprise avec bcp de chercheurs: donc culture de l'expérimentation + motivés pour travailler avec du deep leadning / big data analytics dans le cloud
  • Conseil: structure organisationnelle de l'entreprise doit changer + bénédiction des stakeholder senior. Sinon: risque de ne pas être soutenu dès les premières difficultés
  • créer une "Cloud Policy": un document qui liste les règles / exceptions pour les projets cloud. Exemples:

    • tous les comptes root sont protégés par du 2FA
    • pas d'utilisation de AWS Internet Gateway
  • s'entourer d'une firme de consulting pour initier ce document

  • sans ce document: multiplication des erreurs / divergence du standard / risque pour le projet AWS

  • multi-cloud: c'est un obstacle MAIS ne pas être trop dépendant d'un seul vendor. Donc développement de stratégies de contournement:

    • multi-région + failover (diminue le risque si jamais une région AWS tombe)
    • abstraction de l'OS des machines AWS avec Docker: plus simple à migrer vers un autre cloud
    • automatisation des déploiements et infra as code: plus simple de changer de provider
  • création de wrappers / couches d'abstraction = adapter entre SQS (messaging asynchrone) et l'ancienne API développeur

  • utilisation de SaaS pour les applicaitons un peu isolées (ex: ticketing)
  • utilisation de consultants: il faut les évaluer (aptitude technique, adaptation à la culture entreprise, vient avec ses templates de migration cloud, vient avec ses documents de process)
  • AQR a choisi le "fail fast" sur les consultants: utiliser plusieurs partenaires en parallèle et choisir le meilleur

  • Choix de la 1ere appli à migrer:

    • il y a une valeur business à gagner si on migre cloud
    • faible risque (ex: utilise des dataset publics)
    • l'appli a besoin de features cloud: up/downscaling, serverless...
    • peu de dépendances avec des applications existantes encore hébergées on-premise

Chapter 38

New York Public Library

2016: leur équipe gagne un challenge "Cloud Innovation" au AWS City

  • Situation intiale: nouveau CTO, petites équipes, deux gros projets SaaS en cours, coupes budgétaires à l'horizon = motivation faible pour passer au cloud.
  • 1er projet cloud choisi: solution de configuration management afin d'accélérer les futurs projets. Projet terminé en 12 semaines avec l'équipe à 50% dessus.
  • pas de formation AWS mais des workshops fournis par un partenaire (Control Group)
  • environnement de sandbox AWS: AMIs, Puppet et S3. Une des expériences sandbox mémorables: une pipeline de transcoding media réalisée lors d'un hackathon interne de 24h.
  • création du CCOE et discussions sur la réorganisation des rôles
  • migration du site web vitrine sur AWS + travail sur la migration d'un site beaucoup plus important: "digital collections" (http://digitalcollections.nypl.org).
  • ne pas hésiter à poser les questions "difficiles" + se demander souvent "comment faire mieux et plus rapidement?"
  • grosse infra hébergée donc obligation de faire de l'architecture hybride.
  • décision: AWS pour tous les nouveaux projets + migration des sites legacy "faciles" (beaucoup d'enthousiasme de la direction pour la migration legacy, néanmoins il est plus judicieux d'utiliser les ressources sur les nouveaux projets)

Chapter 39

Channel 4

Situation initiale: perte d'audience, revenus pub en baisse, sites qui ne tiennent pas la charge (exemple de l'émission de Jamie Oliver où il demande aux téléspectateurs d'aller sur le site pour regarder la recette = 5 millions de visites en 30 secondes = le site tombe), les équipes business n'ont pas confiance en les équipes technologiques donc pas de collaboration.

Challenge: comment scaler pour ces évènements qui n'arrivent que quelques fois par semaine?

1er projet: Projet "scrapbook" (clone de pinterest):

  • trop de stakeholders: team leadership, équipe produit, équipe technologie, developpeurs, agence de design, équipe Ops de Channel 4, plus 3 partenaires - ThoughtWorks + AWS + 10gen (en charge de faire une migration MongoDB sur le cloud)
  • principe 1: le succès est atteint lorsque toutes les entités ont atteint le succès =création d'une culture collective au lieu de pointer du doigt les équipes ou individus
  • faire travailler les 8 entités dans le même batiment
  • principe 2: tout le monde a fait du mieux qu'il pouvait au vu des ressources et de la situation et de leurs aptitudes = aide les retrospectives à bien se passer et permet d'itérer / amélioration continue
  • même pour AWS et 10gen: le cas de Channel 4 était une première pour eux (passer de 0 à 5 millions en quelques secondes). Besoin d'écrire de nouveaux drivers MongoDB.
  • projet Scrapbook lancé au bout de 19 semaines avec sucès + changement radical de la mentalité des équipes + source de revenus pour l'entreprise
  • 2 livres ont été écrits par les équipes de Channel 4 suite à ce projet :

    • Barry O'Reilly - Lean Enterprise
    • Kief Morris - Infrastructure as Code

Chapter 40

Capital One (oui, encore)

  • pour l'auteur: l'arrivée du cloud est la 4e Révolution Industrielle
  • IT traditionnel: les compétences on-premise sont sur une seule équipe, silos
  • Après AWS: tous les ingénieurs discutent ensemble avec un langage commun (briques AWS)

Chapter 41

SGN

  • La migration cloud n'est pas déclenchée par un département IT, mais par la direction (raisons économiques): demande d'une migration totale de l'entreprise, pas d'archi hybride
  • Pour la direction: opportunité de réorganiser la partie IT et mettre en lumière les process inefficaces qui étaient masqués depuis
  • Meilleure innovation car barrière d'entrée plus faible pour l'expérimentation
  • Fin du cycle "procure-to-pay" (si on ne paie pas le service est coupé)
  • Nouveau modèle financier: moins de CapEx et ++ d'OpEx

Chapter 42

American Red Cross

Tornade Harvey 2017: déploiement Croix Rouge avec ouverture d'abris + distribution de nourriture + centre d'appel qui doit scaler

  • Création d'une team transverse le lendemain de la tornade: leaders, partenaire Voice Foundry, Amazon
  • Amazon Connect: création d'un call center supplémentaire en 48h. Dé-provisionné 2 semaines plus tard quand la charge redescent.

Chapter 43

Audit puis accompagnement d'une entreprise qui perd des clients

Situation initiale:

  • le business model a évolué mais pas la technologie
  • le travail "business" est toujours prioritaire sur les tâches de nettoyage dette technique
  • infra complexe + dette technique = problèmes lors du dev, du déploiement = travail supplémentaire
  • la solution palliative trouvée par l'entreprise: chantier QA = ajoute rencore du délai sur les plannings de release
  • consequence: lenteur (peu de nouveaux produits lancés par an)

Mise en place solution:

  • 1er projet + création d'une équipe transverse de 13 personnes: prototype terminé en 90j sur AWS (sans expérience préalable de l'équipe sur AWS)
  • Puis création de projets qui bénéficient aux anciennes équipes:

    • opérations de sécurité informatique automatisées et répétables
    • utilisation d'un framework de process pour aider la partie business
  • Création d'un "navigational chart" = roadmap à peu près basée sur les Stage of Adoption, transmis ensuite aux équipes qui n'ont pas encore fait le saut

Chapter 44

"Pourquoi le secteur privé devrait apprendre du secteur public"

Homeland Security

Situation initiale

  • résistance au changement
  • beaucoup de process
  • releases tous les 6 à 12 mois

Situation finale

  • réduction de l'infra de 75% en passant par AWS
  • plusieurs releases par semaine
  • Netflix Chaos Monkey utilisable sur la production pour tests de résilience

Principes

  • Si ça marche dans le secteur public, alors ça marchera partout (tous les problèmes de communication, bureaucratie, multi-stakeholders, peur du changement sont amplifiés ds le secteur public)
  • créer une vision et la maintenir: l'auteur insiste sur la partie "maintenance", car chaque petit échec / compromis peut dissoudre la motivation
  • avancer incrémentalement mais dans le concret: ne pas faire des réunions / powerpoint mais plutot se demander quel est le plus petit pas que l'on peut faire pour avancer concrètement
  • provoquer le changement: ensuite, il suffit d'observer les réactions / obstacles / choses à apprendre sur le sujet provoqué

Chapter 45

Edmunds.com (vente de voitures)

  • 2012 projet de migration totale de l'entreprise
  • à cette époque, peu de consulting / retour d'expérience disponible, seul Netflix avait réalisé une migration totale.

  • step 1: tenter de migrer directement le site Edmunds.com vers le cloud (pas de POC ou de 1er projet facile avant) = 6 mois de migration. Donne une crédibilité indéniable au projet.

  • step 2: création du modèle financier avec pour but (à minima) la parité de coût avec l'ancien modèle data center.

    • Résultat: même le modèle "pire cas" (plan de migration de 2 ans vers AWS + synchronisation vers un data center) permet de réaliser des économies, même sans compter les économies côté achat de matériel
    • Aujourd'hui, l'auteur conseille AWS Cloud Economics pour aider à réaliser le modèle financier
  • step 3: choix des outils de migration. Au départ, Edmund.com voulait uniquement utiliser S3 + EBS + EC2 (services bas niveau), mais a ensuite découvert RDS, Cloud Watch et DynamoDB (services plus haut niveau)

  • 2016: fermeture du dernier data center. Dépenses IT réduites de 30%.

Principes:

  • La règle des 2 semaines: si on peut refactorer un composant en 2 semaines, alors on le fait avant de le migrer dans le cloud
  • Pas d'équipe all-stars: Edmunds.com n'a engagé aucun personnel extérieur pour la migration (pas besoin de "cloud specialist"). Le leader de la CCOE chez Edmunds était l'ancien lead de l'équipe des tests automatisés.

Chapter 46

Friedkin Group

L'auteur de ce chapitre a une expérience précedénte dans le domaine de l'anti-terrorisme et fait des parallèles entre cloud migraton et anti-terrorisme.

  • Vagues d'attentat-suicide: l'ennemi n'est plus une force centralisée mais un groupe de plusieurs petites cellules indépendantes. Pour les combattre, il est plus efficace d'adopter la même structure qu'eux = briser les silos en petits groupes hybrides et indépendants.
  • C'est pareil en entreprise: il faut briser les silos IT et créer une organisation en cellules

Caractéristiques de la cellule

  • Autonome, n'a pas besoin de l'aval des autres cellules
  • Contient donc une variété de spécialisations
  • MAIS utilise son pouvoir uniquement pour atteindre l'objectif du groupe
  • Comme la cellule a des ressources limitées, leurs membres prennent des responsabilités
  • Confiance entre les membres: pas de pointage de doigt, et les idées de chacun sont considérées

Comment créer des cellules

  • De quoi a-t-on besoin -> liste des fonctions
  • 1 fonction = 1 mission, 1 domaine de responsabilités
  • créer des groupes avec X personnes de chaque fonction
  • 1 groupe = des métriques afin de mesurer son avancement & difficultés
  • Séparer des rôles autrefois gérés par 1 personnes en plusieurs

Chapter 47

Dialogue avec un fournisseur IT: "quand est-ce que l'infra sera prête?", "comment peut-on réduire le budget de X?" = le métier attend IT.

Il faut tenter d'arriver à un autre dialogue, plus orienté partenaire (IT attend le métier): "construisez gotre plateforme grâce à la provision à la demande, voici l'API de sécurité à utiliser"

Chronologie des infras / architectures (avant la virtuatlisaton -> Virtualisation/Cloud Privé -> Public Cloud) (ndt: assez discutable, je ne la remets pas ici, dans son historique l'auteur part du principe que l'automatisation des déploiement ne peut venir que de l'adoption cloud lol)

Principes de migration:

  • infra as code: créer des templates réutilisables. Cela ne concerne pas que des scripts d'automatisation, mais de la description d'environnements (CloudFormation)
  • une fois en phase de réinvention: découper les applications en services réutilisables + utiliser des services plus avancés comme Kinesis (data ingestion), Lambda, Redshift (data warehouse)...

Exemples de réinvention

  • VidRoll: utilise AWS Lambda pour le transcodage video temps reel + real time bidding de pub. 2-3 ingénieurs font le travail d'une équipe de 8-10 avant.
  • FINRA avait un cluster EC2 managé avec code maison pour le traitement Big Data. Réinvention avecd Amazon EMR: découplage du stockage bigdata des cluster de computing (permet d'éteindre les instances EBS en-dehors des calculs par exemple)

Chapter 48

Questions à poser pour créer le document de principe cloud:

  • gestion des permissions: toutes les applications ont accès à tout? ou restreindre les droits
  • expérience développeur: forcer tout le monde à utiliser de l'infra as code ou permettre à des gens de provisionner manuellement?
  • système de décision: autonomie totale aux équipes ou conserver le modèle centralisé de décision pour savoir "quel service utiliser pour quel cas"?
  • le document de principe doit aider les équipes à faire des choix ou des compromis
  • le document permet également de rester honnête lors de discussions de groupe + permet de prendre du recul et avoir une vision globale de la stratégie

Exemples de principes dans le document de migration d'Accenture vers le cloud:

  • "Nous devons avoir la possibilté de provisionner et manager des services cloud aussi rapidement que si on consommait la plateforme native. Provisionner aussi rapidement qu'une transaction CB"
  • "Donner aux applications le contrôle et la possibilité de consommer des services cloud sans barrières artificielles - Si AWS l'a déployé pour le public, pourquoi on ne peut pas l'utiliser ?"

Chapter 49

Rearc, boite de conseil Devops/Cloud fondée par un ingénieur de la migration Dow Jones

Comment former un CCOE

  • Profil du membre CCOE

    • Drivé par l'expérimentation: sait itérer et apprendre de ses erreurs
    • Sans peur: il faudra pouvoir challenger le status-quo
    • Peut mener une idée de la phase d'idéation jusqu'à la réalisation
    • Peut apprendre des autres et apprendre aux autres
  • Aptitudes nécessaires dans l'équipe: réseau, dev, stockage, admin sys

  • projets quick win: exemple migrer un data center vers une région AWS, avec toutes les fonctions (réseau, réplication Asie/USA, load balancing, création des AMI...).

  • Les patterns / architecture réutilisables = de l'onboarding pour des applications. Le CCOE doit éviter les exceptions à la règle sur ces patterns => objectif de standardisation

  • Evangelisation: DevOps days, BBL, sessions de formation "Devops university", restitution sur des migrations cloud réussies, invitation de guest-stars venant d'AWS ou de Chef

  • Scaler le CCOE: ne doit pas devenir un goulot d'etranglement. Chaque équipe applicative doit avoir son petit CCOE avec des aptitudes devops

Chapter 50

Migration de Accenture vers le cloud

  • 1er projet: système legacy d'OCR/scan propriétaire, traitant des millions de documents. Création d'une appli mobile pour utiliser l'appareil photo plutot que le scanner + utilisation de S3 pour le stockage
  • 2e projet: environnements de dev et de test dans AWS + shutdown nuit & weekends
  • objectif initial: 90% de l'infra dans le cloud en 3 ans.
  • économies importantes sur tous les fronts (3.6 millions) + meilleure perf, uptime et MTTR
  • en moins d'un an:

    • 12 releases majeures
    • 20 nouveaux microservices
    • 4000 déploiements zero-downtime

Chapter 51

Compliance/Sécu vs Business

Business: veut innover et améliorer l'expérience client

Compliance: veut limiter l'exposition au risque et peut ralentir l'arrivée de features = maintien du status quo

Process de compliance = onéreux (audit annuel, exercice à faire par toutes les teams, ne génère pas de valeur directement, ajout de requirements non-fonctionnels, l'audit tombe toujours après que le développement a commencé)

Solutions:

  • AWS Shared Responsibility Model (un schéma très mal scanné est fourni dans le livre), pour partager la responsabilité de composants entre AWS et l'entreprise
  • infra as code: la validation compliance peut être automatisée et réalisée à chaque update du code + reporting automatisé
  • équipes proactives: ajouter les stories de compliance dans les backlogs et ajouter les tests de compliance dans le process de dev

Chapter 52

ce chapitre ne sert à rien

  • la sécurité sur AWS est supérieure à une on-prem: administration des clés, groupes de sécurités très granulaires...
  • migration FINRA: ont préféré AWS aux serveurs on-prem fournis par le Department of Homeland Security

Chapter 53

Etapes de migration

  • assigner un développeur et démarrer! Ex: lancer un EC2
  • assigner un leader dédié: le CIO ou une personne qui reporte directement au CIO
  • créer une 2-pizza team "Cloud Business Office" constituées de décideurs + fonctionner en agile. Membres conseillés:

    • leader (CIO)
    • chef procurement / vendor manager (achat ?)
    • chef juridique
    • chef sécurité
    • chef finances
    • chef infra
    • chef livraison
    • chef product manager du 1er projet
    • chef audit / risque
  • créer le document de principe

    • stratégie de migration: par exemple, tous les nouveaux projets vont dans le cloud, les anciens en mode "lift and shift",
    • quel partenaire cloud ?
    • objectifs de sécurité
    • modèle de commande (centralisé ou mode cellule)
  • créer une 2-pizza team "Engineering Team" constitués de doers

    • infra
    • sécu
    • développement
    • opérations
    • architecte
  • travailler sur le modèle de responsabilité

  • 1er projet: mettre un MVP en production. Cela peut mettre jusqu'a 12 semaines
  • formation / certificatoin
  • migration: utiliser les 6R (ex: peut correspondre à 6 couleurs de post-it)