#WeSpeakCloud : Comment coder son infrastructure sur Google Cloud Platform et Amazon Web Services ?
Le 25 juin dernier se déroulait la sixième session des "#WeSpeakCloud et si nous parlions Cloud ?" présentée cette fois-ci par Sébastien Lavayssière Flying Designer chez Wescale.
Sommaire
Au programme de cette nouvelle session des #WeSpeakCloud...
L'Infrastructure as Code est maintenant au centre de tous les discours, conférences, entretiens et certaines entreprises l'utilisent au quotidien.
Mais comment faire une infrastructure "as code" ?
Quelles sont les objectifs et les bonnes pratiques ?
Les développeurs sont ils des "dev" ou des "ops" ?
Nous allons essayer de balayer l'ensemble des pratiques et des erreurs qu'on peut croiser en ce moment dans nos missions et essayer de proposer ce qu'est l'objectif de l'IaC.
"Comment coder son infrastructure sur Google Cloud Platform et Amazon Web Services ?"
Quelques pré-requis pour profiter pleinement de ce rdv :
Bases de gitflow.
Notion d'infrastructures cloud.
Vous avez malheureusement manqué cette soirée et/ou vous souhaitez voir ou revoir cette présentation ? Pas de soucis...
La transmission et le partage des connaissances font intégralement partie de nos valeurs chez WeScale.
C’est pour cela que nous avons décidé d'organiser les #WeSpeakCloud "et si nous parlions Cloud ?", une série d'évènements gratuits où nous pourrons apprendre et discuter ensemble sur des sujets actuels qui constituent les technologies et l'environnement Cloud.
Vous avez manqué les dernières sessions des #WeSpeakCloud ?
Retrouvez ici un résumé de l'édition dédiée à l'installation de son Kubernetes en production sur AWS ?
Et ici un résumé de l'édition dédiée à la découverte interactive de Google Cloud Platform.
Et ici un résumé et la vidéo de l'édition dédiée au déploiement et l'utilisation des Big Data sur Google Cloud Platform.
Et ici un résumé et la vidéo de l'édition dédiée à l'équipement d'un cluster Kubernetes pour la production.
(String: <p style="text-align: justify;">Un post-mortem intervient en général, comme son nom l’indique, après un incident, qu’il s’agisse d’une indisponibilité de service ou de l'échec d’une opération planifiée par exemple. Le post-mortem est une pratique qui a pour but de vous aider à apprendre de vos erreurs dans une optique d’amélioration continue.</p>)
Un post-mortem intervient en général, comme son nom l’indique, après un incident, qu’il s’agisse d’une indisponibilité de service ou de l'échec d’une opération planifiée par exemple. Le post-mortem est une pratique qui a pour but de vous aider à apprendre de vos erreurs dans une optique d’amélioration continue.
Les promesses du Platform engineering sont nombreuses et alléchantes : un socle plate-forme utilisable par l’ensemble des développeurs, une meilleure productivité, une rationalisation des outils et des processus de delivery plus fluides et des « produits » à meilleure valeur ajoutée commerciale. Mais comment mettre en place cette nouvelle plateforme sans perturber le run de l’entreprise et mettre en péril l’existant ?
Platform engineering : optimiser la productivité des développeurs
Ces dernières années, la transformation digitale des entreprises s'est accélérée entraînant une généralisation du cloud dans la plupart des entreprises. Cette évolution s’accompagne de nouveaux défis : sécurité, IA, standardisation, mais aussi gestion des talents. Selon Gartner, d’ici à 2026, 80 % des entreprises d’ingénierie logicielle mettront en place des équipes de plateforme en tant que fournisseurs internes de services, de composants et d’outils réutilisables pour la distribution d’applications. Quid de ce qui se cache réellement derrière le platform engineering ?
