feat(IntegrationAcquiredCompany): add case study for archi devops

caseStudies/IntegrationAcquiredCompany/exercise.md

@@ -0,0 +1,72 @@
+# Intégration du SI d'une entreprise acquise
+
+## Objectif
+
+L'objectif de cet exercice est de vous mettre dans la peau d'un architecte d'entreprise "devops" qui doit intégrer le système d'information d'une entreprise acquise dans le SI de l'entreprise acquérante.
+
+## Contexte technique de l'entreprise **Alpha**
+
+L'entreprise **Alpha** est une entreprise de taille moyenne qui opère dans le secteur de la distribution de produits électroniques. Elle a récemment acquis l'entreprise **Beta**, une entreprise de taille similaire qui opère dans le secteur de la distribution de produits informatiques.
+
+L'entreprise **Alpha** dispose d'un système d'information (SI) basé sur une infrastructure cloud pilotée par Terraform. Cette infrastructure est composée de plusieurs applications front et backoffice déployées sur Kubernetes (avec autoscaler), de bases de données PostgreSQL, et d'un CDN, le tout en service managé.
+
+Les outils de développement et de déploiement utilisés par l'entreprise **Alpha** sont basés sur des technologies open source et des services managés:
+
+- Github pour le versionning des sources
+- Github Action pour l'intégration continue
+- Helm pour le packaging des applications
+- ArgoCD pour le déploiement des applications sur Kubernetes
+- ElasticSearch pour la recherche et l'analyse des logs
+- Prometheus / Grafana pour la surveillance des applications
+- Les bases de données sont sauvegardées régulièrement sur le système de stockage (bucket, blob, storage...) du provider cloud, en plus du système fourni par le service managé.
+- Les endpoints https sont exposés via un ingress controller coté Kubernetes, un LoadBalancer du provider cloud, avec un certificat SSL wildcard fourni par Let's Encrypt mis à jour via cert-manager.
+
+L'entreprise **Alpha** a également mis en place une architecture de microservices pour ses applications front et backoffice, avec une API Gateway et un OIDC pour l'authentification et l'autorisation des utilisateurs.
+
+## Contexte technique de l'entreprise **Beta**
+
+L'entreprise **Beta** dispose également d'un système d'information basé sur une infrastructure cloud.
+
+Les applications sont constituées de plusieurs fronts et d'une api backoffice monolithique, qui s'appuie sur une base de données Oracle.
+
+Une équipe Data est également en charge de l'analyse des données et de la création de rapports via des scripts shell lancés via des taches cron, les traitements étant trop consommateur de ressources pour être lancés dans la journée.
+
+L'infrastructure cloud de l'entreprise **Beta** est basée sur des machines virtuelles.
+
+Ces dernières sont créées par des scripts shell (voir manuellement) qui ne sont pas toujours à jour. Les machines virtuelles utilisent des distributions linux hétérogènes (CentOS, Debian, Fedora) et ne sont pas régulièrement mises à jour. Certains de ces systèmes sont anciens et ne sont plus supportés par les éditeurs.
+
+Ansible est utilisé à la fois comme outil de configuration des VMs et de déploiement des applications et le système de surveillance est basé sur Nagios.
+
+L'outil de versionning des sources est un Gitlab installé au sein de l'infrastructure de l'entreprise **Beta**, avec 3 VMs dédiées (Gitlab, Gitlab Runner, Gitlab CI). Il y a 2 repositories Gitlab: un pour les front et le backoffice, et un pour l'équipe Data.
+
+Les ops de l'entreprise **Beta** créent le week-end des VMs avec énormément de ressources de calcul dédiées à l'équipe Data pour qu'ils puissent traiter les données plus rapidement.
+
+Un load balancer est utilisé pour exposer les applications en https, mais le certificat SSL est signé par un service tiers (comme Gandi) qui gère aussi le domaine. A chaque renouvellement du certificat, il faut le mettre à jour manuellement sur le load balancer, ce qui a déjà causé des interruptions de service.
+
+## Tâches
+
+Présentez en 30' une stratégie d'intégration du SI de l'entreprise **Beta** dans le SI de l'entreprise **Alpha** auprès de la direction informatique.
+
+Elle doit se faire de manière progressive et sans interruption de service majeure (c'est à dire dans les heures ouvrées), mais toutefois rapidement, efficacement (dans un délai d'environs 6 mois) et de manière à réduire les coûts.
+
+## Eléments de réponse attendus de la part du candidat
+
+Globalement, le candidat doit proposer une stratégation d'intégration du SI de l'entreprise **Beta** dans le SI de l'entreprise **Alpha** en prenant en compte les éléments suivants:
+
+- Décrire la manière dont les 2 SIs vont être connectés (vpc peering si possible, vpn, LB privé, etc.)
+
+- Définir une stratégie globale de migration: bottom-up (d'abord la bases puis les applis) ou top-down. Il faut éviter de faire un mix des deux stratégies qui risque de cumuler la compléxité des deux approches.
+
+- Les applications de l'entreprise **Beta** doivent être déployées sur Kubernetes. Pour cela il faut les containeriser et mettre en place leur conf Helm. On peut faire cela en synchronisant les sources des applications de l'entreprise **Beta** avec un repository Github de l'entreprise **Alpha** et en utilisant Github Action pour construire les images Docker et les déployer sur Kubernetes.
+
+- Autorisation / habilitation: il faut que les applications de l'entreprise **Beta** puissent communiquer avec les applications de l'entreprise **Alpha**. Il faut donc permettre aux applications de l'entreprise **Beta** de s'authentifier sur l'OIDC de l'entreprise **Alpha**.
+
+- De la même manière, les scripts "cronés" de l'équipe Data de l'entreprise **Beta** doivent être containerisés et déployés sur Kubernetes via Github Action, des cronjobs, etc. Cela doit permettre de résoudre implicitement les besoins de scalabilité.
+
+- Afin d'être le plus efficace possible, il faut éviter de rentrer dans un découpage des applications existante, mais plutôt les containeriser telles quelles. Il sera toujours possible de les découper en services par la suite.
+
+- Il n'est pas nécessaire de migrer la base de données Oracle de l'entreprise **Beta** vers PostgreSQL, mais il est nécessaire de l'intégrer dans le SI de l'entreprise **Alpha** afin de profiter des services managés de sauvegarde et de monitoring.
+
+- Il n'y a pas d'intérêt à investir dans l'infrastucture de l'entreprise **Beta** (machines virtuelles, scripts shell, Nagios, Gitlab) qui sera progressivement remplacée par l'infrastructure de l'entreprise **Alpha** (Kubernetes, ArgoCD, ElasticSearch, Prometheus / Grafana, Github, etc.), sauf éventuellement sur le court terme pour assurer la continuité de service.
+
+- Pour les noms de domaines, on peut changer le fournisseur de nom de domaine de l'entreprise **Beta** pour le mettre chez le fournisseur de l'entreprise **Alpha** et ainsi bénéficier de la gestion des certificats SSL par cert-manager.