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.

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.

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 GithubGithub 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.

Il y a quelques mois déjà, je discutais avec un collègue d’ observabilité, opentracing, … avec Quarkus. On est tombé sur un super exemple réalisé par Antonio Concalves. Ce projet démontre les capacités de Quarkus sur les sujets suivants: Circuit Breaker Observabilité OpenTracing Tests … Et la on peut se demander quid de Spring? Je me doutais que ces fonctionnalités étaient soient disponibles par défaut soient facilement intégrables vu la richesse de l’écosystème.