Après trois ans d’inactivité pour des raisons que l’on connait malheureusement toutes et tous, Devoxx Belgium était de retour à Anvers. Je n’avais jamais participé (en vrai) à une conférence internationale.

C’était donc une première pour moi.

Pour y aller, j’ai eu trois fois de la chance:

1. J’ai eu cette opportunité grâce à Worldline - mon employeur
2. J’ai réussi à avoir un billet pendant les cinq minutes où se sont vendus les billets lors du premier batch
3. Ma présentation au format Quickie a été retenue. J’ai présenté un talk à Devoxx!!!!!!!

Voici mon retour d’expérience des trois jours de conférence.

Dans mon dernier article, j’ai tenté de faire un état des lieux des solutions possibles pour implémenter des batchs cloud natifs.

J’ai par la suite testé plus en détails les jobs et cron jobs Kubernetes en essayant d’avoir une vue OPS sur ce sujet. Le principal inconvénient (qui ne l’est pas dans certains cas) des jobs est qu’on ne peut pas les rejouer. Si ces derniers sont terminés avec succès - Vous allez me dire, il faut bien les coder - mais qu’on souhaite les rejouer pour diverses raisons, on doit les supprimer et relancer. J’ai vu plusieurs posts sur StackOverflow à ce sujet, je n’ai pas trouvé de solutions satisfaisantes relatifs à ce sujet.

Au début de l’année, j’ai interpelé mes managers: “J’ai été retenu au Camping des Speakers”!

Unanimement, j’ai eu la même réponse: “Le QUOI ???!!!”

Oui j’en conviens le titre peut paraître à première vue tout sauf sérieux. Il faut dire que le lieu est un camping en Bretagne dans le golfe du Morbihan.

Et pourtant !

La programmation était de qualité et a tenu ses promesses.

Je vais essayer de retranscrire quelques sujets qui ont retenu mon attention. J’en oublierai sans doute beaucoup. Je m’en excuse d’avance.

Quand on parle du Cloud et de Kubernetes, généralement on pense aux APIs. Mais qu’en est-il des batchs?

Oui, depuis plusieurs années, on pensait les éradiquer, mais ils sont encore là et on en a encore besoin pour quelques années encore. Ils ont même eu une deuxième jeunesse avec le Big Data et l’explosion des volumétries dans l’IT.

Je vais essayer de faire un tour d’horizon dans cet article des batchs dans un environnement Cloud et plus particulièrement dans Kubernetes.

1 L’analyse des risques: kezako ?

Souvent utilisée dans la prise de décision, l’analyse des risques a plusieurs objectifs :

• Permettre de pondérer des risques potentiels
• Faciliter la prise de décision sur les actions à réaliser pour les prévenir ou tout du moins les atténuer.

Mais d’abord, revenons aux bases. Comment identifier un risque ?

Selon Wikipedia, voici la définition:

Le risque est la possibilité de survenue d’un événement indésirable, la probabilité d’occurrence d’un péril probable ou d’un aléa.

1 Pourquoi mettre en oeuvre des GITHUB ACTIONS ?

Comme j’ai pu l’expliquer dans mon précédent article, je suis passé de Wordpress à GITHUB Pages.

Une fois le site déployé une première fois, on voit qu’on a perdu pas mal d’automatisations qui sont réalisées par défaut dans Wordpress. Par exemple, vous devez construire votre site, publier des nouveaux articles et vérifier que tout est OK.

J’ai donc mis en oeuvre des GITHUB ACTIONS pour automatiser le plus d’actions possibles et me passer de tâches manuelles souvent rébarbatives.

L’idée me trottait dans la tête depuis quelques mois environ: migrer mon blog de Wordpress vers un site basé sur Jekyll et hébergé directement sur Github. La date de renouvellement de ma souscription Wordpress arrivant à terme, je me suis décidé à franchir le pas. s

1 L’ hébergement de sites web sur Github

Github permet via son service Github Pages d’héberger des sites statiques (c.-à-d. pas de base de données derrière) en permettant d’associer son nom de domaine. Le certificat est automatiquement généré.