Si vous voulez déployer vos applications et services dans un cloud public, vers qui allez-vous vous tourner? Très probablement vers l’un des 3 acteurs majeurs au niveau planétaire. Votre choix se fera sûrement pour des raisons politiques plus que techniques ou financières. Je dédierais sûrement un article à ces choix ultérieurement. Le fait est que pour déployer une nouvelle application dans le cloud, le choix est finalement assez simple. En premier vous avez la solution déjà indiquée : un des mastodontes américains. Problème, vous ne voulez pas forcément donner vos données, vos applications et votre argent à une multinationale, quelle que soit sa position vis-à-vis des questions éthiques et légales. Et dans un climat de défiance envers la globalisation, et une tendance à la relocalisation, il semble un peu hypocrite de s’appuyer sur eux. ...

Le buzz autour de l’IA semble se cristalliser autour de deux principaux sujets : les possibilités offertes par la technologie, et les risques liés à son utilisation. La question des risques est un sujet de choix pour les détracteurs et les récalcitrants. Nombre d’articles et de livres listent les problèmes posés par l’IA et souhaiteraient nous voir jeter le bébé avec l’eau du bain, et la baignoire au passage. Ce qui me trouble beaucoup dans cette démarche, en dehors du danger que l’on fait courir aux bébés qui prennent leur bain, c’est que l’IA focalise l’attention, alors que le problème est humain avant tout. L’IA ne fait rien de nouveau ou de plus que d’autres systèmes précédents. Et même le terme IA est galvaudé, particulièrement dans ces cas-là. Prenons quelques exemples. Le plus ancien me concerne directement. Il y a une dizaine d’années, j’ai déménagé au Royaume-Uni, et j’ai voulu ouvrir un compte en banque. Nous avons choisi une banque connue et répandue. Nous avons passé quelques heures à remplir des formulaires, puis avons attendu de recevoir nos moyens de paiement. Le jour où nous les avons enfin obtenus, nous avons aussi eu un lettre nous indiquant que notre compte allait être fermé car nous n’étions pas conformes à la politique de la banque. Aucune autre information n’était donnée. Ayant noté une erreur dans le nom auquel le courrier était adressé, j’ai voulu rentrer en contact avec la banque, pour savoir quelle était la raison réelle de ce refus et vérifier s’ils n’avaient pas suivi le dossier de quelqu’un d’autre (le credit score existant dans ce pays, j’aurais pu être confondu avec une personne ayant un mauvais score). Après de multiples emails et coups de téléphone, la seule réponse que j’ai obtenu a été “le système Phoenix nous indique que nous ne pouvons pas vous octroyer un compte”. Impossible d’en savoir plus. Ce qui m’a dérangé, en bon français habitué à la CNIL, a été de me voir opposer un mur anonyme, sans avoir aucun moyen d’accéder aux données me concernant. La banque pouvait me refuser un service, sans aucune justification ni explication. Aucune IA à cette époque, quelques recherches m’ont montré que je n’étais pas le seul à avoir des problèmes avec Phoenix, et que celui-ci était un simple système de vérification qui pouvait se déclencher pour des raisons obscures. Et bien sûr impossible de faire corriger mon dossier d’application pour que le contrôle effectué corresponde bien à ma propre situation (il reste très probable que l’erreur de nom dans le courrier de refus prouve que les données de contrôle ne me concernaient pas). Pour l’épilogue, nous sommes allés dans une autre banque, avec le même dossier. Nous avons expliqué la situation, et après quelques échanges avons obtenu notre compte. Je peux utiliser d’autres exemples, comme les systèmes de logement aux US qui se basent sur des données plus ou moins publiques pour déterminer si vous êtes aptes à recevoir un logement. Je ne parle pas de système de logements sociaux, mais de sociétés privées qui fournissent des service de background check pour les bailleurs privés. L’expérience malheureuse de quelques-uns a montré que, comme dans le cas de Phoenix, il est impossible d’accéder à nos propres données, de savoir quel critère nous a rendu indésirable et encore moins de pouvoir corriger les données si jamais il y a une erreur. Ou bien pensez au système de social scoring chinois. Si vous trouvez le credit score anglo-saxon désagréable, je n’ose imaginer les dérives possibles du social scoring. Accessoirement cela peut créer des cercles vicieux, rappelez-vous l’épisode Nosedive de Black Mirror. Tant que vous êtes un blanc mouton, gentil et hypocrite, tout va bien. Au moment où un grain de sable vous fait dérailler, tout aprt de travers. Votre score se dégradant, vous vous trouvez dans des situations plus compliquées (difficultés à obtenir un prêt, un travail, un billet d’avion etc…) et le risque que votre score se dégrade augmente. Bon il s’agissait de fiction, mais finalement très proche de la réalité. Revenons au credit score américain : si votre score est mauvais, vous aurez du mal à obtenir un prêt de bonne qualité. Mais vous finirez par en obtenir un à de très mauvaises conditions, ce qui signifie souvent qu’il vous coûtera cher et que vous augmenterez le risque de défaut de paiement, même temporaire. Ce qui va dégrader votre credit score, etc. etc etc. Mais tout ceci n’est pas lié à de l’IA. Certes, parfois ce sont des algorithmes obscurs qui ne rendent pas d’explication sur leur décision. Et ce ci doit être combattu et corrigé. Mais la plupart du temps la sélection se fait sur des critères cachés mais très simples. La discrimination existe, avec ou sans IA. Ce à quoi il faut être attentif reste l’accès aux données et l’explicabilité des modèles. Pour la première, nous avons en Europe le règlement RGPD qui oblige à cette transparence (et à la protection de nos données). C’est un pas dans la bonne direction, au moins dans notre juridiction. Pour l’explicabilité des modèles, il n’existe pas encore de règle, à ma connaissance, mais cela devrait être obligatoire pour tout ce qui touche aux besoins primaires, à minima.

Alors oui, c’est une fonctionnalité dont nous parlions peu mais qui va simplifier beaucoup la vie quotidienne. L’annonce de la public preview est récente, mais la fonction marche déjà très bien, sous peu que vous utilisiez le portail Azure Preview (https://aka.ms/BastionHost). Le principe est très simple : vous avez des VMs connectée à des Vnet isolés du monde extérieur, et vous ne souhaitez pas ouvrir les ports d’administration (SSH/RDP) de ces VMs vers l’extérieur. Habituellement, vous montiez une VM dédiée, qui elle était configurée pour accepter les connexions extérieures, avec une stack spécifique lui permettant de servir de relais vers les VMs protégées. Bonjour la complexité : • D’administration d’une solution dédiée, et parfois bancale (si quelqu’un aime sshgw, qu’il se jette la première pierre!) • D’utilisation au quotidien. Dans certains cas un logiciel particulier permettait une connexion relativement simple, dans d’autres il fallait s’authentifier plusieurs fois et faire des tunnels SSH pour arriver à sa destination… Et là, libération avec Azure Bastion. Démonstration! Mettons que vous ayez déjà une VM déployée sur Azure. Lorsque vous utilisez le portail Azure pour vous y connecter, en principe, vous n’avez qu’à cliquer sur le petit bouton qui va bien. Dans mon cas une VM Linux : ...

J’admets être venu au sujet du remote Expert par accident. Une demande client sur le sujet m’a amené à creuser quelques pistes. Une fois les quelques solutions utilisées et testées, j’avais en main de quoi effectuer simplement quelques démos, parfois de manière inopinée. J’ai été convaincu très vite du potentiel de cette solution simple à mettre en œuvre. Les quelques démos effectuées au détour d’une conférence ou d’une simple discussion montrent que les clients sont convaincus aussi. Le Remote Expert (ou Remote Assist), qu’est-ce que c’est? Imaginons que vous ayez dans votre structure une flotte d’intervenants sur site pour des tâches très variées. Ceux-ci ne peuvent pas être experts dans tous les domaines, ni connaître par avance tout ce dont ils auront besoin avant d’être appelés en dépannage. D’un autre côté, vous aurez sûrement un expert du domaine, qui maitrisera parfaitement l’intervention à effectuer. Mais celui-ci ne sera pas en mesure d’être présent sur l’ensemble des sites au cours d’une journée, les pannes ne se planifiant jamais comme cela nous arrangerait. Il faudrait donc une solution permettant à l’expert de se démultiplier. Comme le clonage humain n’est pas encore au point ni éthiquement accepté, il faut trouver autre chose. Et voici le Remote Expert. Cette solution consiste à utiliser un appareil mobile sur le site de l’intervention, pour partager l’environnement de travail avec l’expert. Et surtout de pouvoir annoter et donner des indications sur cet environnement. ...

This is a second post in what might become a series regarding DevOps, and DevOps transformation. Unfortunately for you, I speak my mind when I feel like it, so there is no master plan behind my ranting. First post was about choosing a strategy when transforming a managed services team towards DevOps. This second step may not come necessarily after that first step :) You get to choose. In a way, I have the feeling that DevOps is close to what ITIL is : a toolbox where you can select which parts you would like to apply, and the way to implement them. So new topic : how to target or build the team which will start the DevOps initiative in your organization? There are several indicators that you can use to make this selection. None is an absolute, once again, these are pointers to which team would better succeed in applying DevOps principles. There is no sure shot, no magic finger method :) The obvious criteria is to pick a team, of future team members that are already aware of DevOps, and willing to make the move. Of course these would be the people that will help you succeed in the first move, and show the rest of the world that it can be done, and bring very positive outcomes. The second flag that should be raised is tied to one of the main outcome of DevOps : software delivery. If you have a team that is already struggling to get a reliable software delivery in place, and is willing to put the effort into building the organization and tools to get there, then you have a probable winner :) On the opposite, if you try to convince a team that they need to move to DevOps when they are convinced their software is delivered efficiently and reliably, you’re going to hit a wall. Basically it would come down to convincing them that they are doing a poor job and are not even aware of that. Maybe not the right target for your first DevOps project. The last one brings us to my favorite topic, outside of tech stuff : business outcome! Of course, the aim of a transformation within your organization should always be mindful of the business outcome. Imagine you pick a team that is working on a neglected piece of software that no one cares about, and of which customers are just happy of the current situation. I do not think you would get the visibility and traction, not to mention willingness if you try to initiate your DevOps transformation in there. On the other hand, if you manage to get a team working on a new flagship product, that gets the attention of the CxOs, and has a need to show modern and reliable software delivery… you have a winner! Once you’ve chosen your dream team, and start working, remember that DevOps, as always, is about people, not just tools. The key thing to take away stems from common sense, and has been given by someone who did try and implement multiple Agile/DevOps organizations: “if you start with bad people and give them a smart way to work together, they won’t become smart by themselves”. Alright, I must admit the original quote was much harsher, but I cannot write it here :) PS : I tend to keep these article short, and do not dive into each topic. This is done on purpose, not just by laziness. If you need to go deeper in each topic, just ask, or get a good read :) ...

I know, DevOps is still a buzzword. IT is often used to rebrand an old team or practice, and give more sexiness to a marketing slideset. I have seen it used to describe what is essentially an automation team within an Ops team. Good start, but missing the point. Anyway, having been a major actor in a devops transformation, and witness to many, I wanted to give some advice to anyone out there patient enough to listen to me. I think most of what I am going to say will seem trivial, but it would help a few of us to put some words on what is happening to good ol’ outsourcing. I am talking right now about DevOps transformation, but specifically when it happens to a Managed Services team, as in an outsourcing company, or an MSP. This is a difficult spot, as such teams should be able to provide support for DevOps organizations form their customers, and even help them. I will skip the contract and SLA part, as it is a very tricky subject, at least for now. I have seen two ways of approach the subject. First is full ahead transformation, no quarters, no mercy. The second is building a new team dedicated to DevOps, in parallel of the existing one. I have only experienced the second first hand. It was an opportunity as we were bringing a new set of skills and customers into an existing managed services org. I chose to break from the past, and build a new set of tools and processes almost outside of the existing system. This creates the possibility to create and prove the viability of these new ways of working and interacting with your customers. The difficult part is where you have to merge with the existing tools and processes. For example, we had to start with the monitoring tools we had, as we could not ask our 24*7 monitoring team to have multiple dashboards and tools. The fact that we were successful with the other tools and habits we developped allowed us to push for a new monitoring solution a few months after the initial move. And we kept the momentum after that :) The other way I have witnessed, to transform the whole team at once, is challenging and cannot be carried by anyone on the team. I would advise that you start this path if you have a sufficient executive weight, or support from the executive team, because it will be a disruptive path. This is good, but the cost might be high, both in terms of people inside the team being disgruntled and maybe leaving, and in terms of your existing customers (and prospects) who might not understand what you are undetaking. The uptake is that you avoid having two different teams working with different mindsets and toolsets. Obviously I would recommend reading the Devops Handbook, and the Phoenix Project, to get a basic understanding of what you are getting yourself into :) Next up, I will try and help you target which team and/or customer would be a best fit to start your devops journey, stay tuned! Je sais, tout le monde parle de DevOps, à tort et à travers, mais parfois à raison. C’est un terme souvent utilisé pour redorer une image d’équipe ou de practice, et donner une touche sexy sur un jeu de diapositives. Je le vois souvent utilisé pour décrire ce qui n’est essentiellement que de l’automatisation dans une équipe Ops/infrastructure. C’est un bon début, mais ce n’est qu’un début, pas le voyage complet. Néanmoins, ayant été acteur, parfois majeur, et témoin de plusieurs de ces transformations vers le DevOps, je voulais donner mon avis, à qui veut bien l’entendre. Ce que je vais dire va sûrement paraître trivial à certains d’entre vous, mais pourrait donner quelques indices à ceux qui se demandent où va le métier d’infogéreur. Je parle de transformation DevOps, spécifiquement lorsque cette transformation touche une équipe de Managed Services/infogérance. C’est un sujet difficile dans ce contexte, car ces équipes doivent fournir un support moderne à leur client, qui sont parfois déjà organisés en mode DevOps, et même les aider à vivre cette transformation. Je ne vais pas entrer dans les sujets contractuels et SLA, c’est un point très sensible et complexe. En tout cas, pas aujourd’hui. J’ai pu observer deux façons d’approcher ce sujet. La première est une transformation complète et radicale de l’existant, pas de quartiers. La seconde est de construire une nouvelle équipe dédiée DevOps, en parallèle de l’existant. J’ai seulement vécu la seconde méthode personnellement. Il s’agissait d’une opportunité car nous amenions tout un panel de nouvelles technologies et de clients dans une équipe d’infogérance existante. J’ai pu faire le choix de repartir d’une feuille blanche et de bâtir un ensemble d’outils et de méthodes pour desservir des nouveaux clients dans un ...

Ce qui suit est une opinion personnelle, un ressenti de mon expérience, et peut ne pas refléter la réalité ou même le ressenti de l’ensemble de mes camardes, merci de ne pas leur en tenir rigueur :) Lorsque j’ai débuté mon parcours professionnel, voire depuis mes études, nous avions une image assez négative des chercheurs en informatique. Ils étaient certes très intelligents, et avaient des connaissances approfondies, mais inutiles pour le quotidien. Savoir comment fonctionne un compilateur pouvait être passionnant, et servir dans quelques cas d’optimisation. De là à dire que c’était ce qui allait nous servir au quotidien… Durant les 15 premières années de ce siècle, la tendance a perduré. Ce que j’ai pu observer autour de moi n’était pas très glorieux pour les chercheurs et universitaires. Nous les trouvions déconnectés de la réalité, perdus dans des théories ou sur des problématiques très éloignées des nôtres. Quelques frémissements se sont fait sentir dans certains domaines avec la montée en puissance des grands acteurs actuels, Google en tête. Les questions d’analyse sémantique et de volumétrie de données à traiter ont amené ces acteurs à travailler directement avec la recherche scientifique, car aucun produit sur étagère n’était prévu pour ce genre de cas. Vu de mon fauteuil, cela aura été le début discret du changement que nous pouvons observer aujourd’hui. Les chercheurs sont sollicités, approchés, séduits. Nous avons besoin de leur vision en pointe, voire en avance sur la pointe, pour résoudre des problématiques spécifiques. Ce qui a changé, selon moi, est l’état d’esprit, probablement poussé par les start-ups et la digitalisation massive. Nous sommes passés d’une approche “produit” (qu’est-ce que je peux faire avec ce que je connais) à une approche “solution métier” (que faut-il pour résoudre le problème posé par le business). Et cela change tout. Là où nous nous limitions à utiliser les capacités de quelques produits et à les mettre en service pour des fonctions prédéfinies, désormais nous sommes en mesure de creuser la problématique métier, qui n’a souvent rien à voir avec un problème IT. Cette problématique, nous la traduisons ensuite en critères techniques, et nous allons à la recherche du meilleur compromis pour résoudre ladite problématique. Et s’il le faut nous nous tournons vers les chercheurs. Du côté des laboratoires, encore une fois selon moi, ce qui a changé en France est que ces équipes doivent maintenant aller chercher la plus grande part de leur budget dans des financements extérieurs. Et l’issue positive est que nous nous sommes rapprochés. Comme dans une belle histoire Disney de Noël (c’est de saison !), chacun a fait un pas vers l’autre et ensemble nous sommes plus forts. ;) Le marché privé se rend compte que le mode de fonctionnement et de financement de la recherche publique est particulier. Le privé est capable d’entendre cela et de s’y adapter, car cela permet de créer des nouvelles solutions, avec l’appui des meilleurs cerveaux et technologies, même si elles n’existent pas encore. Et la recherche publique a admis qu’elle devait travailler avec des projets peut-être plus précis, en termes de planning et d’objectifs, et surtout de ROI. ...

Pour avoir passé quelques années au sein d’une équipe dédiée à ce genre d’activité, il m’a été difficile d’accepter la réalité. Cependant, les faits sont là : les POCs sont mourants. Petit retour en arrière : un POC, ou proof of concept, est souvent le point de départ d’un projet de grande envergure. Son objectif est de prouver la faisabilité technique du projet, y compris la maîtrise par les divers acteurs dudit projet. Cet outil a été souvent utilisé par les constructeurs et revendeurs, afin de convaincre un client sur une nouvelle technologie. Hélas, le vent a tourné. Aujourd’hui les constructeurs, et les éditeurs, commencent à refuser les POCs. Selon moi, la cause est assez simple. Le POC était souvent financé quasi-exclusivement par le fournisseur et ses partenaires. Le but avoué, comme dit ci-dessus : valider la technologie. Sauf que quelques grains de sables sont venus perturber ce petit monde. En premier, certains clients et utilisateurs ont abusé du POC pour pouvoir s’amuser avec une nouvelle technologie, aux frais d’autrui. Et souvent sans aucun projet réel. Il s’agissait parfois de se faire mousser en interne, ou d’occuper son temps… En second, et c’est particulièrement valable sur l’IoT ou l’IA, les fournisseurs eux-mêmes avaient un objectif primaire différent du client : créer un cas client afin de pouvoir communiquer, et prouver au monde qu’ils avaient la capacité technique de délivrer cette technologie. Si on couple les deux problèmes, on voit nettement approcher la situation, vécue par beaucoup de grands comptes. Des POCs innombrables, sur les mêmes technologies, mais gérés par des entités internes et des fournisseurs différents. Cherchez un peu, en choisissant une grande entreprise au hasard, et regardez combien de POCs ont été fournis sur la même technologie, par des acteurs différents… La tendance a donc basculé, et il devient beaucoup plus difficile, avec des acteurs clairvoyants en tout cas, de réaliser des POCs. Tout n’est pas totalement bloqué, il existe des cas où le POC possède une vraie valeur. Il est même parfois nommé Proof of Value, car on étend son objectif à prouver la valeur et le ROI d’un projet, au-delà de la simple faisabilité technique. Et souvent, le financement du POC se fait de manière conjointe par l’ensemble des acteurs, y compris le client. Cela assure un intérêt réel et commun pour le projet dans sa globalité. Donc oui, la récréation est finie. Nous pouvons toutefois encore jouer un peu, avec sérieux :D Having worked in a team dedicated to them, it feels hard to admit that truth. However, the facts are here : POCs are dying. Let’s step back a little : a POC, or proof of concept, was often the starting poitn for a large project. Its point was to prove the technical feasability of the project, including the ability of the actors to deliver. This tool has often been used by vendors and providers, to convince a customer regarding e new piece of tech. Halas, winds have changed. Today vendors are pulling the plug on POCs. According to my own eminence, the cause is pretty simple. A POC is often paid almost-exclusiveley by the vendor and its partners. The acknowledged purpose, as stated before : validate the technology. But there has been a few hiccups on a smooth ride. First, a few customers or users, have abused the concept of a POC, in order to get some play material and time. They were able to get their hands on some shiny new hardware or software, and brag about it, without having any intention of deploying it for real. Second, ad this is particularly valid for IoT or AI topics, the vendors themselves had a different purpose for the POC : create some customer cases, to communicate about and prove to the world that they have the technical know-how to deliver that tech. If you search a little, choosing a large company, for communiques and testimonies about IoT for example, you will find that there are many firms that have delivered THE IoT platform for a customer, with a glowing testimony from some team from the customer. Which raises the question : how many unique and mind blowing IoT platforms does this customer need? Are they all for real? How many IoT preferred partners can a company have? The wheel has turned then, and it becomes more difficult, with clear minded actors anyway, to deliver a POC. All is not completely blocked, there are some cases where the POC has a real value. It is even known as a POV (proof of value), because its purpose is extended to prove the value and ROI of the whole project, beyond just technical feasability. ...

Et voilà, un nouveau post pour inaugurer des changements! Premièrement, vous l’aurez noté, j’écris désormais aussi en français. Le but est de pouvoir toucher aussi mes camarades français, et de pouvoir partager des informations qui parfois ne sont qu’en français, et aussi de satisfaire quelques râleurs français ayant du mal avec la langue de Freddie Mercury. Dans la mesure du possible, je ferais les deux versions de mes articles, mais ce ne sera pas systématique :) Pour le détail, j’ai créé deux tags qui permettront de trier les articles. http://cloudinthealps.mandin.net/tag/english/ http://cloudinthealps.mandin.net/tag/francais/ Ensuite, j’inaugure le français pour pouvoir m’excuser de ne pas écrire grand-chose cette semaine, mais plutôt de partager des articles déjà publiés ailleurs. Les deux premiers traitent de la vulgarisation de l’IA, et ont été écrits par Frédéric Wickert : Sway ...

About two years ago, Google announced the availability of TensorFlow processing units in its cloud. They are dedicated microcontrollers built for training and running Machine Learning models. TPU are available within Gcloud as an execution platform for ML (of course, optimized for TensorFlow). During the summer, they unveiled the edge equivalent of these TPU, which are named… Edge-TPU :) These are very specific ASIC designed to execute ML models on an edge device, i.e. a small device close to the sensors gathering the data. This allows for a fast decision, without the need to send a truckload of data back up to the cloud. But wait for it… Microsoft did just uncover a device called DataBox Edge. I know, the main purpose of this device is to provide a storage gateway to help you use Azure storage locally, and move the data between the device and Azure, hence the name. Bear with me, the path is a bit convoluted, and I would like you to enjoy every turn of it. Databox Edge is also equipped with what has been called IoT Edge. This nifty piece of technology will enable you to run Azure-based workloads on an edge device, such as Azure Functions, Azure ML, Azure Stream Analytics etc. IoT Edge has been out in the open for about a year now, to be deployed onto compatible devices. And, and that’s where we hit the Edge-TPU spot, also included in Databox Edge is a shiny new Microsoft hardware, called Brainwave. The name kind of gives away the purpose, especially after I guided you through the maze. Anyway, this chip is designed to run AI models on an edge device, and do it with impressive performance and efficiency. I know, at this point, you would point out at the fact that it might again be a case of “We did it first!” from Google. I’d like to focus a big difference between the two approaches. For once, I could not say which would win in the long term. In theory I prefer the approach from Microsoft, but that does not mean it will prevail (or that they would not change tactics and build something more like Edge-TPU). The difference is that Google built an ASIC, whereas Microsoft used Intel FPGA to deploy its Brainwave architecture. OK, this needs some explaining. First the names : ASIC means Application Specific Integrated Circuit. FPGA means Field Programmable Gate Array. You see where this is going? An ASIC is a very specific chip, designed to do only one thing, but optimized to its core. I should be able to execute one kind of job, but do it perfectly. One the other hand, an FPGA is reprogrammable after its deployment, to be able to adapt to future needs. Its performance is close to an ASIC, but not quite equal. To complete the panorama, going from specific to general use, we would then add GPU (Graphical Processing Units, as in your graphics cards) and then CPUs (ye good ol’ Pentium). Microsoft took the path of versatility, whereas Google focused on a particular use. As I mentioned, I’m not sure who has the best strategy, and whether there will even be a fight, but I am very curious to see both chips in the wild!