Après l’annonce du support de Kubernetes par Docker à la fin de l’année 2017, 2018 a été l’année de Kubernetes. Il est le premier projet a avoir atteint le statut “graduated” de la CNCF en mars et de nombreux autres projets gravitent maintenant autour: skaffold, tous les Operators (Prometheus, etcd, Kafka, …) La CNCF propose deux certifications kubernetes : la CKAD qui est la certification développeur et la CKA qui est l’équivalent côté opérationnel. Éric Briand et moi vous proposons notre retour par rapport à la certification CKA. Pourquoi passer la certification ? Nous voyons plusieurs raisons pour passer la certification : S’assurer de ses connaissances : même si on manipule kubernetes au quotidien, le sujet est tellement vaste que s’assurer de bien connaître un tronc commun est important Pour faire reconnaître ses compétences : pour sortir du lot de consultants déclarant connaître kubernetes Sortir de sa zone de confort : pour progresser et pour viser encore plus haut Enfin, ils nous a semblé intéressant de confronter notre expérience de formateur Kubernetes au cursus de la certification officielle Programme Le programme de la certification se trouve dans un repository github. Il y a beaucoup de choses dans le curriculum, mais ce qu’il faut retenir principalement, c’est : Bien maîtriser les différents types de ressources de base Savoir dépanner un cluster kubernetes Savoir créer un cluster kubernetes avec ou sans kubeadm Préparation Pré-requis hors kubernetes Pour pouvoir s’en sortir le jour de la certification, il y des prérequis à connaître hors kubernetes : vim : pour éditer et créer vos fichiers de configuration (il y a peut-être nano, ou emacs mais nous n’avons pas testé :D) systemd : pas besoin de tout connaître, mais a minima: daemon-reload, start, stop, restart, status journalctl : pour consulter les logs des services systèmes Anglais…

C’est quoi un MVP ? Le terme “MVP” (Minimum Viable Product), popularisé par le livre “Lean Startup” d’Eric Ries, tend à se vulgariser tout comme l’agilité et perd peu à peu de son essence. Un MVP est une première version d’un produit apportant un minimum de valeur, mais qui permet d’expérimenter avec les utilisateurs et d’en tirer des apprentissages. Le MVP doit permettre, à moindres frais, de répondre aux besoins/problèmes les plus importants et de valider ou non des hypothèses bâties lors de la conception du produit. Cependant, le MVP n’est pas un produit mal fini. Il doit être de qualité, simple et correctement développé. Les freins au lancement d’un MVP À Zenika Labs, nous rencontrons des entreprises qui hésitent encore à tester leur MVP. Elles craignent que leurs utilisateurs ne soient pas satisfaits, car cette première version ne couvre pas assez de fonctionnalités. Les enjeux liés au lancement d’un MVP peuvent être de taille. Voici quelques raisons qui expliquent en partie ces craintes : peur de décevoir et de perdre les clients actuels peur de construire une mauvaise réputation et de nuire à son image de marque autour d’un produit pas complètement finalisé peur d’être incompris vis-à-vis de la direction qui n’admet pas les échecs et ne comprend pas très bien cette démarche peur de … Ces freins paralysent à la fois les équipes et les décideurs, qui rechignent à se lancer. Après le MVP initial, il s’en suit un développement long et coûteux, repoussant la mise sur le marché (le “time-to-market”). Entre temps, le marché évolue et le produit ne correspond plus aux attentes des utilisateurs. Lancez-vous ! Testez votre produit sur un nombre restreint d’utilisateurs L’objectif du MVP est justement de tester directement cette version auprès des utilisateurs avant un plus large déploiement pour valider ou non…

Si vous avez suivi un petit peu l’actualité de Java vous avez dû remarquer qu’il s’est passé pas mal de choses cette dernière année : Java 9 est sorti il y a un an avec pas mal de nouveautés (dont la tant attendue modularité du JDK) et n’est déjà plus supporté depuis 6 mois, Java 10 est sorti il y a 6 mois et n’est plus supporté non plus, Java 11 vient de sortir et est LTS (Long Term Support). Oracle fournit deux distributions de Java : Oracle et OpenJDK et propose du support étendu pour ceux qui le veulent. Java 8 (la version la plus utilisée actuellement) ne sera plus supporté à partir de janvier 2019! Pour ceux qui sont un peu perdus là-dedans, cet article est fait pour vous ! Je vais tenter d’éclaircir le nouveau mode de gouvernance de Java (cycle des release, support, distribution) et de vous présenter les principales nouveautés des versions 9, 10 et 11 en faisant le focus sur les changements à destination des développeurs.