Culture on Cloudinthealps

La technologie, les investissements et l'antimondialisation

Wed, 29 Jan 2020 00:00:00 +0000

La technologie, les investissements et l’antimondialisation Conflits commerciaux et indus (Huawei/Google ou 5G par exemple) Quantique rapport Forteza Apple et ses fournisseurs pour les smartglasses lien vers article complet. Finalement les plus grands capitalistes du monde ne soutiennent un libre-échange que quand ils sont en position de force. Lorsque la dépendance se fait ressentir, chacun se positionne derrière ses remparts. Est-ce un bien ou un mal? Exascale, atos et eurohpc Cisco et polytechnique C’est la pandémie, le re-confinement dans beaucoup de pays, les élections aux USA, les conflits entre la Chine et ses territoires autonomes, le Brexit… jusqu’ici, tout va bien. Mais dans notre bel univers quotidien de la tech, au-delà des solutions de distanciation sociale, de contact tracing ou de port du masque, quelques tendances m’ont suffisamment intéressé pour que je me décide à écrire. Pour être honnête, j’ai pensé à ce sujet dès le début d’année, fin janvier, avant que la crise Covid ne vienne amplifier le constat. Alors commençons par une petite interrogation pour vous : qu’ont en commun la 5G, le quantique, les puces pour téléphone mobile et la réalité augmentée? Vous avez 4h.

Blameless post-mortem

Tue, 11 Sep 2018 00:00:00 +0000

Nope, my new position is not dead yet, thank you very much. What I mean by this title is usually a meeting in any IT service, after a major incident has been resolved, where all the team members who have worked on the incident gather and discuss what went wrong, and how to improve tools and processes to do better next time. I specify blameless, as it is a very good practice to avoid finger pointing, generally and particularly in these meetings. If you want people to be honest and share their best insights, you have to keep in mind that these post-mortems have to cultivate an atmosphere of trust. The aim is really to find out how the events have unfolded, which information had been gathered, what went wrong, what steps were smart, which ones did not work properly etc. For more information about that, I recommend some DevOps sessions and talks, like this one from @Jasonhand from VictorOps : It’s Not Your Fault - Blameless Post-mortems

Designing your own job

Tue, 05 Jun 2018 00:00:00 +0000

Depending on how you consider things, it is the third time that it happens to me. Being able to design, under certain limits, your own job, is an amazing opportunity. I will not go into too many details as some of it is work in progress, but the process was amazingly energizing and I wanted to share a bit of that energy. For my current job, I met my future boss on the recommendation of a former colleague. We discussed many things, from ITIL to Managed Services, and also public cloud and the need to get dev and ops team closer. We went through those kind of talks several times, at least four if memory serves. We went from a job which look like an Ops engineer/ITIL practitioner, to something closer to an Azure tech lead. In my previous position I also had the opportunity to be offered a promotion, and been able to discuss some of the content and responsibilities of the future role. I was also able to step down when time came for me to admit that it was not an ideal position, for me or for the company. Which was really appreciated, at least on my part. And once again a few weeks ago, I was called out of the blue by a colleague’s boss. He started to discuss his own future and what he was trying to design. He wanted to build something new, and was searching for a partner to build that together. And in that scheme, he discussed a position very similar to my dream job, and offered it to me. I almost fell off my chair. At that point I was ready to accept, without having any more details about the exact role and responsibilities, or even the salary. That’s where my future boss started to ask me what I would include or exclude from that job description, and how I could make it my own. My mind just froze. It took some time for me to recover and start thinking again. After some lame jokes, we discussed the position, and what we would like to build together. It took us several meetings and calls to see through the fog, as we are really going to build something new together, and we cannot rely much on what exists around us. The last funny thing to happen was that my next interview was with the CEO of the company, who was convinced by the both of us in less than 35 minutes. I could not believe my luck in getting there. Anyway, that’s it for the bragging post. I really needed to write that down to make it real (even if I signed and will start by the end of the summer :) )

Going back to my (our) roots

Fri, 18 May 2018 00:00:00 +0000

Yes, another post with an obscure reference for a title. After some time discussing tech subjects, I was of a mind of going back to something that has often been misread in the past by IT teams and IT management. And by that I mean : business. Yes, again. Do not misunderstand me, I am still a technologist, and I love learning about technology, finding out the limits and possibilities of any enw tech that is coming out. I am not a sales person, nor a marketing person. However I have been exposed to many well crafted presentations and talks over the years, and what often came out of even the most interesting ones was that : “our tech is fantastic, buy it!” All right, I love that tech. Be it virtualisation, SAN, VSAN, public cloud, containers, CI/CD, DevOps… choose whatever you like. But technology is not an end to itself in our day to day world. Whatever matters is what you will do with it for your company or customers. I will take an example. An easy shot at someone I admire. Mark Russinovich, CTO of Azure, and longtime Windows expert (I would use a stronger term if I knew one :) ). A few months ago, during a conference, he had a demo running where he could spin up thousands of container instances in a few seconds, with a simple command. First reaction : “Wow!” Second reaction : “Wooooooowwww!” Third reaction : “How can we do the same?” Fourth reaction (probably the sanest one) : “Wait, what’s the point?” And there we go. What was the point. For me, Mark’s point was to show how good Azure tech is. Which is his job, and this demo made that very clear. But Mark did go further, as he usually does, during his speech and encouraged everyone to think about the usages. Unfortunately, most of the people I have discussed with seem to miss the point. They see the Wow effect, and want to share it. But few of us decide to sit down and think about what the use case could be. And that is the difficult, and probably multi-million dollar question : how to turn amazing technology into a business benefit. Never forget that, apart from some very lucky people, we are part of a company that is trying to make money, and our role is to participate to that goal. We should always think about our customers, internal or external, and how we can help them. If doing that involves playing with some cool toys and be able to brag about it, go for it! But that is not the other way around. PS : to give one answer to how we could use Azure Container instances for the real world, especially the kubelet version of ACI, try and think about batch computing, where you would periodically need to spin up dozens or hundreds of container instances for a very short time. Does that ring any bell for you? PPS : I could not find the exact session from Mark I am describing here, but there is an almost identical session from Corey Sander and Rick Claus there : Azure Container Instances: Get containers up and running in seconds

The risk of innovation burnout

Thu, 22 Feb 2018 00:00:00 +0000

Catchy title, isn’t it? It could have been copied from a Management magazine, or CIO Monthly. Note to self : check before getting a copyright infringement lawsuit. What I wanted to write about is mostly how to deal with the fast pace of innovation in the IT cloud business. And mostly, how I deal with it, in my specific role, and how I dealt with it before. As IT pros, we need to always keep an eye on the market, to check emerging technologies, to check where the existing ones are going and which ones are dying. This serves two purposes : • Keep our company and infrastructure up to date • Keep our own profile up to date, or at least on the track for the future In french we have an expression for that : “veille technologique”, which would roughly translate to “technological watch”. In some french schools this subject is taught. It mostly describe how to identify the proper source of information to track, and how to track those. The sources are mostly tech websites and influencers. The tools are more diverse : RSS feed, Linkedin, Twitter, Facebook, Reddit… In my previous position, as an infrastructure consultant & architect, I had to keep up with a limited set of technologies, mostly around databases and virtualization. My watch was purely technical, and dealt with detailed evolution of some component : which new feature was available in the latest version of Vsphere ESX, what capabilities was expected in the future release of Oracle DB etc. In that scenario, using RSS feeds, and attending some virtual events from the software editor was enough. I could keep up with the innovation pace by investing something along the line of one day per month of my time. Today, if I consider my CTO-like role, the job is more complex. The scope I have to watch is much broader. If you consider only Microsoft Azure and the services it may provide, it is already almost impossible to keep up. For example, if you use the blog posts “Last week in Azure” which only relate to official news from the Azure blog, you get around 30 news per week (https://azure.microsoft.com/en-us/blog/last-week-in-azure-week-of-2018-02-12/). If you want to dig into each announce, and find out how it might affect you, this will take more time than you have in a week :) And that does not count anything outside of official Azure news. If you add some specific content creators, from Microsoft or not, which post also every week, and then also add news and tendencies around DevOps… you get the point. I forgot the podcasts, and videos… The main risk, as the title stated, is innovation burnout, or innovation overload. From what I have seen with colleagues, partners and customers, most of them do not want to keep up with that mass of information. Fortunately, I love learning new stuff, and I love information. Here is how I am currently working to get the most relevant information in my mind, and keep up with the news stream. I have separate tools for separate needs, and most important I do not use them at the same pace :