Katia Himeur présente une checklist pour réussir la migration vers des applications cloud native, soulignant l'importance de la préparation, de la communication et de la culture organisationnelle. Les règles de base incluent définir des objectifs clairs, analyser les pratiques existantes, et se préparer aux imprévus. La conclusion insiste sur le fait que la migration ne doit pas être un but en soi, mais un moyen d'atteindre des objectifs commerciaux.

1. 📝✅ La checklist ultime pour
rendre vos applications cloud
native !
Katia HIMEUR 20 octobre 2023

2. Qui suis-je ?

3. Qui suis-je ?
• 🪪 Katia HIMEUR
• ☁ CTO & Cofondatrice de Cockpit io
• 🏢 Conseil, Build et Formations autour des sujets Cloud et DevOps
• 💻 Developpeuse backend ayant toujours eu un pied dans l’infra
• 👩💻 Consultante SRE/Cloud/DevOps depuis plusieurs années
❤ #Cloud #DevOps #Containers #Serverless #GitOps #IaC #CICD ❤

4. Pourquoi ce talk ?

5. Mes constats

6. • Marché mondial du Cloud
Mes constats

7. • Tendance année 2023 l’optimisation des usages et la réduction des
coûts de projets cloud
Mes constats
Tendances du taux de croissance de Q1 2020 à Q2 2023

8. Mes constats
• Parfois le déroulé du projet
n’est pas celui espéré, s’il n’est
pas bien préparé

9. Mes objectifs

10. • Partager mes retours
d’expériences.
• Partager notre méthodologie de
migration vers le cloud au sein
de Cockpit io.
• Vous donner les clés pour éviter
les pièges et mener à bien vos
projets.
Mes objectifs

11. Avant d’aller plus loin…

12. …Quelques rappels de
définitions

13. Définition #1 :
Le cloud computing

14. Qu’est-ce que le cloud computing ?
• Ressources et services fournis à la demande par le fournisseur cloud.
• Le fournisseur de services Cloud maintient le matériel physique.
• Exemples de services Cloud : Réseaux, serveurs, logiciels, bases de
données…
• 3 types de cloud :
• Cloud public
• Cloud privé
• Cloud hybride

15. Quelques avantages du Cloud
• Ce modèle offre de nombreux avantages :
• Réduction des coûts
• Réduction du Time to Market
• Agilité
• Scalabilité
• …

16. Définition #2 :
Le cloud native

17. Qu’est-ce que le cloud native ?
• Approche logicielle qui permet de :
• créer, déployer et gérer des applications dans des environnements
cloud.
• Mettre en œuvre des systèmes faiblement couplés, résilients,
manageables et observables.

18. Comment mettre en place
cette approche ?

19. Comment mettre en place cette approche ?
• D’après la Cloud Native Computing Foundation (CNCF), grâce aux :
• conteneurs,
• microservices,
• services mesh,
• APIs déclaratives,
• infrastructures immuables,
• …

20. Qu’est-ce qui se cache
derrière les “…” ?

21. Tada !
CNCF Landscape

22. La CNCF Landscape
Au 1er septembre 2023,
elle représente 1 236
outils

23. Par quoi on commence ?

24. C’est cela le secret pour
réussir sa migration ?

25. Non, sauf…

26. Si vous voulez avoir une
équipe à bout ➡

27. Choisir les outils au
hasard et …

28. …
fi
nir avec un quotidien
compliqué ➡

29. Qu’est-ce qu’il faut faire
alors ?

30. Suivre quelques règles de
base

31. Règle 1 : Ne pas se concentrer
uniquement sur la technique

32. Règle 1 : Ne pas se concentrer uniquement sur la technique
• La technique c’est important, mais ce n’est pas tout.
• La réussite d’une migration ne peut pas en dépendre uniquement.
• Le contexte dans lequel l’application évolue a aussi son importance.
Règle 1 : ✔

33. Règle 2 : Définir ses objectifs

34. Règle 2 : Définir ses objectifs
• Pourquoi choisir le cloud ?
• Quels sont les avantages dont nous souhaitons béné
fi
cier ?
• Quels sont les objectifs business que nous souhaitons atteindre ?
• Aller sur le cloud n’est pas un objectif, mais un moyen d’atteindre ses
objectifs business.
Règle 2 : ✔

35. Règle 3 : Communiquer avant,
pendant et après le projet

36. Règle 3 : Communiquer avant, pendant et après le projet (1/2)
• Tout le monde doit avoir le même niveau d’information.
• Ne pas hésiter à rappeler vos objectifs tout au long de votre projet de
migration.
• Ne pas négliger la communcation inter-équipe et intra-équipe.

37. • Éviter les zones de
fl
oues.
Règle 3 : Communiquer avant, pendant et après le projet (2/2)
Règle 3 : ✔

38. Règle 4 : Analyser votre
culture et vos pratiques

39. Règle 4 : Analyser votre culture et vos pratiques
• Avez-vous adopté la culture DevOps ?
• Avez-vous adopté les pratiques courantes du développement cloud
native (intégration continue, livraison continue…)?
• Faites le point sur vos procédures internes(déploiement, tests,
validation…).
• Faites le point sur votre degré d’automatisation (tests, releases,
déploiements, rollbacks, alerting…).
Règle 4 : ✔

40. Règle 5 : Identifier les
personnes clefs

41. Règle 5 : Identifier les personnes clefs
• Qui maitrise l’application ?
• Qui maitrise l’infrastructure ?
• Qui maitrise les déploiements ?
• Quelles sont les autres personnes clefs ?
• Qui doit leader le projet de migration (arbitrer, faciliter, communiquer…)?
Règle 5 : ✔

42. Règle 6 : Collaborer

43. • Constituer une task force multidisciplinaire.
• Casser les silos.
• Cultiver l’esprit collaboratif.
Règle 6 : Collaborer
Règle 6 : ✔

44. Règle 7 : Analyser votre
existant

45. Règle 7 : Analyser votre existant (1/2)
• Étape détérminante pour faire vos choix futurs.
• Identi
fi
er :
• L’architecture applicative (microservices, monolithiques, orientée
événements…).
• Langages, dépendances, versions.
• Persistance des données (Statefull vs Stateless).
• Les licences utilisées.

46. Règle 7 : Analyser votre existant (2/2)
• Analyser :
• Données à transférer.
• L’infrastructure existante.
• Les ressources actuelles utilisées.
• Le tra
fi
c.
• L’observabilité.
Règle 7 : ✔

47. Règle 8 : Faire un point
sécurité

48. Règle 8 : Faire un point sécurité
• Lister vos contraintes :
• réglementaires et procédures.
• Réseau : VPN, WAF,
fi
ltrages IP, réseaux fermés…
• Détection de vulnérabilités.
• Tests de sécurité automatisés.
• Identi
fi
er vos besoins en authenti
fi
cation et en autorisation.
Règle 8 : ✔

49. Règle 9 : Cadrer votre projet

50. • Scopes applicatif et infrastructure concernés.
• Choix de l’architecture cible.
• Choix du ou des fournisseurs cloud.
• Anticiper les besoins de formation des équipes.
• Anticiper le cost management et l’impact écologique (tags, région…).
Règle 9 : Cadrer votre projet (1/2)

51. Règle 9 : Cadrer votre projet (2/2)
Choisir sa stratégie de migration
Refactor /Re-architect Migrer en refactorant l’architecture de son
application.
Replatform (Lift & Reshape) Migrer en apportant quelques optimisations
uniquement.
Repurchase (Drop & Shop) Passage du on premise à un modèle SaaS.
Rehost (Lift & Shift) Migrer l’application telle qu’elle. Peut être une
étape intermédiaire.
Retain (Revisit) Pas de migration.
Retire Décomissionnement.

52. Règle 9 : Cadrer votre projet (2/2)
Choisir sa stratégie de migration
Refactor /Re-architect Migrer en refactorant l’architecture de son
application.
Replatform (Lift & Reshape) Migrer en apportant quelques optimisations
uniquement.
Repurchase (Drop & Shop) Passage du on premise à un modèle SaaS.
Rehost (Lift & Shift) Migrer l’application telle qu’elle. Peut être une
étape intermédiaire.
Retain (Revisit) Pas de migration.
Retire Décomissionnement.
Règle 9 : ✔

53. Règle 10 : Définir vos KPIs

54. Règle 10 : Définir vos KPIs
Lead time
Deployment
frequency
Change fail
percentage
Mean time to
repair (MTTR)
Mean time
between failure
(MTBF)
Availability Performance …
Règle 10 : ✔

55. Règle 11 : Préparer votre
application

56. Règle 11 : Préparer votre application (1/3)
• Selon la stratégie de migration et de l’architecture cible, adapter
votre application: développement, optimisation, choix des langages
et des frameworks, conteneurisation…
Microservices Serverless Conteneurs Monolithiques

57. Règle 11 : Préparer votre application (1/3)
• Soigner les temps de démarrages et d’arrêts.
• Adapter vos work
fl
ows de CI/CD.
• Adapter votre stack locale.
• Renforcer la sécurité de votre application.

58. Règle 11 : Préparer votre application (3/3)
• Ne stocker pas localement: le cache, les données de sessions et les
assets.
• Regrouper vos dépendances dans un
fi
chier dédié.
• Mettre à jour vos dépendances.
• Augmenter l’observabilité.
Règle 11 : ✔

59. Règle 12 : Préparer le jour J

60. Règle 12 : Préparer le jour J
• Préparer une checklist et les étapes de la migration : (DNS, transfert
de données, personnes à prévenir, rollback en cas de problème,
stratégie de déploiement…).
• Tester ce scénario.
• Tester le nouvel environnement et l’application.
Règle 12 : ✔

61. Règle 13 : Se préparer aux
surprises

62. Loi de Hofstadter
“Il faut toujours plus de temps que
prévu, même en tenant compte de la
loi de Hofstadter.”
Règle 13 : Se préparer aux surprises

63. Loi de Murphy
“Tout ce qui est susceptible d'aller mal
ira malt.”
Règle 13 : Se préparer aux surprises

64. Règle 14 : Documenter

65. Règle 14 : Documenter
• Faites-le au fur et à mesure.
• Sensibiliser vos équipes à l’importance de la documentation.
Règle 14 : ✔

66. Règle 15 : Itérer

67. Règle 15 : Itérer
• Ajuster l’infrastructure et le dimensionnement.
• Ajuster le monitoring.
• Se remettre en question.
• S’inscrire dans une démarche d’amélioration continue.
Règle 15 : ✔

68. Règle 16 : Apprendre de votre
projet

69. Règle 16 : Apprener de votre projet
• Prévoir des rétrospectives pour :
• Lister les succès sur lesquels il faudra capitaliser.
• Les axes d’amélioration.
Règle 16 : ✔

70. Règle 17 : Faites-vous
accompagner

71. Si vous n’avez la compétence en interne,
faites-vous accompagner par des
personnes expertes !
Règle 17 : Faites-vous accompagner
Règle 17 : ✔

72. Conclusion

73. Conclusion
• Le développement cloud native n’est pas uniquement question de
technique.
• La culture, les pratiques et l’organisation sont des éléments cruciaux
pour réussir vos projets de migration.
• Une migration n’est pas un objectif en soi, mais doit être un moyen
d’atteindre ses objectifs business.
• Il n’y a pas de recette magique : Adaptez-vous à votre contexte et à
vos besoins.

74. Merci
@katia_tal
@katia-tal
/in/katiahimeur/
🔗 blog.cockpitio.com
@cockpitio42
/company/cockpit-io/
Restons en contact