SnowCamp 2020

Dans un monde distribué, nous sommes confrontés à de nouveaux problèmes. Les notions de circuit-breaker, de retry, de timeout, de blue-green deployment, A/B testing, pool-ejection… viennent remplacer nos anciens problèmes de monolithe .

Istio est là pour nous aider sur tous ces points... et même plus !

Nous allons utiliser Istio on GKE sur Google Cloud Platfom et découvrir ensemble tout ce que nous pouvons faire pour nos petites applications. Si le traffic mirroring, Canary Release, Traffic spliting ne vous font pas peur, nous pourrons mettre cela en place très facilement ! Nous irons même jusqu'à injecter des erreurs dans notre système #ModeChaos.

Nous profiterons aussi des outils offerts par GCP pour suivre les comportements et performances de nos applications en live.

Les pré-requis pour les participants à cette université sont disponibles ici :
https://istio-in-action.training.stack-labs.com/isto-on-gke/0.0.1/01_getting-ready/01_prerequisites.html

Depuis 3 ans nous travaillons une application web composées
- d'une vingtaine d'api Node.js
- de 3 Backoffices AngularJS et Angular
- de plusieurs applications Symphony

Soucieux de la qualité nous avons monté un serveur Jenkins pour nous permettre, dans un premier temps, de construire nos livrables, lancer les tests et analyser le code. Puis est venu le temps de construire nos pipelines pour mettre en production nos livrables.

A la vue du nombre d'éléments composant l'application, l'automatisation des tâches récurrentes devint nécessaire !
Grâce à Jenkins nous pouvons,
- construire tous nos éléments
- assurer la qualité
- préparer les releases et déployer en production
- créer des environnements de dev dynamique pour valider des features

Jenkins est donc devenu un outil central pour nous aider à développer. Dans cette conférence je vous présenterai comment nous arrivons à gérer notre serveur Jenkins.
Je vous parlerai pêle mêle de création de jobs avec JobDSL, de Configration-As-Code, de tests de Pipeline Groovy....

Les slides:
https://t.co/TyQAZWfUtb?amp=1

Today, almost every Web actors have moved or are moving to the Cloud. At Sogilis, we diagnosed a (way too much widespread) design practice, that we’re calling the “reverse design methodology”, which consists in choosing a platform, and then adapt your application and business to fit it !

Typically, this implies to join the hype of Docker/Kubernetes, hire someone that we call « devops » to operate that new thing. Then move our code to this endlessly scalable wonderland, progressively, while redesigning our legacy system along the way, to fit the platform. That is the « Kubernetes Driven Development » ! And here come the hidden cost of « porting the legacy code to the cloud » (distributed logs, monitoring, race conditions, request tracking, memory sharing ….). While all these costs are normal, they are usually unpredicted by developers and architects, because they underestimate the complexity of distributed software.

This is quite a shame because battle proven guidelines exist ! They are gathered under the « Cloud Native » and « 12 factors app » paradigms, which are perfect candidates to lead to a clean, consistent and scalable application design for the Cloud.

In this talk, we propose to expose the unpredicted consequences that we diagnosed on the Kubernetes Driven developments met in our experiences, and then introduce the Cloud Native and 12 factors app principles to explain how these guidelines could protect a system design (or evolution) from having unpredicted costs.

Ces derniers mois Kubernetes est partout, en terme de *buzz word* on peut difficilement faire mieux. Et comme souvent lorsqu'un sujet est si populaire, vous avez des tutoriels, billets de blog et talks par milliers, expliquant comment bien démarrer sur Kubernetes. Tout va donc bien dans le meilleur des mondes, non ?

Et bien non, pour être honnête. Car l'immense majorité de ces tutoriels, articles et talks s'arrêtent juste après le *Hello Kube*, lorsque vous avez quelques applications tournant sur votre MiniKube sur le laptop. Et là, c'est pas la fin, mais à peine le principe...

Dans ce talk je vais parler de cet écart entre MiniKube et une infra de production, de l'intérêt des infrastructures Kubernetes managées, des pièges et du *vendor locking*, de comment arriver à faire assez confiance dans sa solution pour faire tourner du Kubernetes sur Kubernetes et d'autres sujets de ce type.

La DATA est le “nouvel or noir” ! Mais comment aborder l’enjeu qui consiste à construire de véritables raffineries, accélérant et fluidifiant le traitement des données de l’entreprise, pour produire des services innovants ? Venez découvrir le processus de fabrication d’un projet bâti sur la donnée !

En s’appuyant sur ses parents naturels que sont l’ **Agilité** et la culture **DevOps**, nous découvrirons les principes fondamentaux de la pratique **DataOps**. Notamment ce que nécessite une application dont les règles sont générées par apprentissage d’un flux de données continu. Quel est l'intérêt d’une architecture Data-Centric ? Qu'apporte le concept de Data-Fabric dans la gouvernance de la donnée ? et le ML ? Venez, et vous comprendrez !

Building a Kubernetes cloud using Raspberry PI 4.
The RPI4/4G offers enough memory and cpu to build an educative Kubernetes cluster.
The presentation will show how to put the pieces togother to get an Apache Tomcat
operator to deploy a small web application in the build RPI4 Kubernetes cloud.

Description:
We will show:
- how to build a kernel for RPI4, use it to make a bootable SD card for a RPI4.
- how to configure it to use the WIFI board
- how to prepare Docker images for ARM64
- how to join the Kubernetes master
- how to use weave plugin to get the Kernetes internal network
- how to build and install the operator for Apache Tomcat.

Veolia, référence mondiale de l'environnement, avec sa filiale IoT, Birdz, installe et exploite des modules pour radio-relever les données des compteurs d'eau. Birdz a conçu une solution portable, basée sur des conteneurs, pour traiter et valoriser les données. Mais, lorsque les collectivités souhaitent gérer leur parc de compteurs en autonomie, elles peuvent déployer et exploiter elles-mêmes la solution et les données. De plus, avec plus de 3 millions de modules sur le terrain en croissance constante et divers aléas techniques potentiels, l'utilisation d'une infrastructure extensible et autogérée est devenue indispensable pour répondre aux engagements de service.

Cloud Run répond à cette double problématique de réversibilité et d'élasticité : Cloud Run est une solution managée par Google Cloud qui permet de faire tourner des conteneurs portables, de façon serverless, et de scaler en fonction de la demande.

Cette présentation vous décrira ce retour d’expérience concret de Veolia et sa filiale Birdz, et vous en apprendrez plus sur Cloud Run, pour déployer en quelques secondes et scaler de 0 vos conteneurs dans le cloud, avec le minimum d’ops possible.

- vos applications sont composées de plusieurs services ✓
- vos services sont sous forme de conteneurs ✓
- vos services sont déployés sur un orchestrateur ✓

Attendez un instant, vos services sont déployés. Pas vos applications ?

Et d'ailleurs, avant même de les déployer, comment publiez-vous vos applications avec tous leurs services ? Et comment les mettre à jour ?

Laissez-moi vous présenter CNAB : Cloud Native Application Bundle dont la spécification ouverte vient de passer à la version 1.0, développée conjointement par Microsoft, Docker, Pivotal, Datadog et Intel entre autre.