Azure on Cloudinthealps

L'IA ne remplace pas les gens — elle casse les organisations en silence

Fri, 05 Jun 2026 00:00:00 +0000

Gartner nous dit que 20 % des organisations vont utiliser l’IA pour virer plus de la moitié de leur management intermédiaire d’ici fin 2026. En face, Sam Altman déclarait à Sydney le 26 mai qu’il était “content de s’être trompé” — l’apocalypse emploi qu’il annonçait, ben finalement, elle n’a pas eu lieu.

Les deux ont raison. Et les deux passent à côté du sujet.

L’IA ne supprime pas massivement les postes. Elle supprime les étages. Elle redessine l’organigramme sans que personne ait validé le plan. Et ça, on ne le verra pas dans les résultats trimestriels de 2026 — on le verra quand les organisations ne tourneront plus en 2032.

Test Azure Bastion

Tue, 02 Jul 2019 00:00:00 +0000

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 :

Brainwave, Tensorflow : AI at the edge

Fri, 02 Nov 2018 00:00:00 +0000

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!

Managed Kubernetes and security

Fri, 06 Jul 2018 00:00:00 +0000

Almost a sponsored post today, or better : a shared announcement. You probably know that I am following Kubernetes rather closely, especially managed Kubernetes services (AKS, EKS or Openshift for example). One domain where these offerings have been lacking is network and security. It is still a very sensitive subject for our customers, for containers related project, and still for public cloud projects. Security and networking teams have trouble adapting to the public cloud paradigms and architectures. There some fear of loss of control, some base fear of the unknown, and some real worry about how to handle networking and security. Kubernetes (and the other orchestrators) adds another abstraction layer on top of the existing public cloud platforms, which does nothing to alleviate fear, to say nothing about complexity and transparency. There are some very good solutions out there to manage network overlays into Kubernetes. My favourite is Calico, but you may like any of those. I’ll stick with Calico for a simple reason, which you will see below. Microsoft and AWS are both working hard to provide a network overlay into their managed Kubernetes offering. They each chose their own path, but we will get to approximately the same point in a short time. Thanks to Jean Poizat, we have the two announcements.

Microsoft Tech Summit France

Thu, 15 Mar 2018 00:00:00 +0000

As the summit has just closed its doors, I would like to share my feedback on this first Tech Summit to happen in France. As far as I know there are already Tech Summits in several other countries around the world. From what I have heard, they are supposed to be “local Ignite” events. For honesty’s sake, I have to say that I have not attended Ignite so far, only Tech-Ed Europe a few years ago, so I will not compare too much the two events. However according to the community website (http://aka.ms/community/techsummit) the sessions were exactly the same as the ones played at Ignite. I did not see any numbers published, so far, but it was a rather small event. Attendance to the first keynote on Microsoft 365 was not really high, however the Azure keynote attracted more people and the room was almost full. I had the feeling that Azure was more exciting than Microsoft 365, but maybe 9:30 was too early for most :) Or maybe I am biased toward Azure ;) The conference took place in one Hall from Paris Expo, on one level. And we were far from crowding it. As it was a free event, right in Paris, it seems that a lot of people came and went, just for a session or two, rather than stay for the whole two days. Which is rather smart, as it lets local people continue running their business, while being able to attend some sessions. And it lent a quiet feeling to the event itself. For once, I managed to attend a few sessions, and they were very interesting, very focused on a tight subject. I was never deceived by a catchy title enticing me to a session that had nothing to do with what I could expect. The speakers were a mix of Microsoft Corp and Microsoft France, most sessions were in English and we could interact easily with every speaker afterwards. Overall the sessions raise some good ideas for me to pitch, and subjects to talk about with my customers. I would have liked more technical sessions, but I think deep dives need a specific environment and public to be able to run properly. In conclusion, I liked the event overall, but I do not see it as attractive as Experiences. And it was much smaller! Also Experiences had been criticized has being less technical than the previous event it replaced, Tech Days. From my point of view, Tech Summit is on the same level as Experiences, just smaller and 6 months later (or earlier depending on how you look at it :) ) As usual, the strategy is a bit difficult to read, but the local speakers and content providers were present and accessible, which is almost always my first reason to come :) One final word about the technical levels used to sort the sessions : levels are standard, from 100 to 400, with 100 being introductory and 400 being expert. My advice would be to change the description as the level describes mostly the current knowledge you need to have about the product (Azure for example) than the depth of the session. 400 does not mean you will see live coding and the inners of the platform. It means that you know already where you’re going, and have probably already used the product.

Azure SLAs

Tue, 27 Feb 2018 00:00:00 +0000

Another quite short post today, but for a complex topic. I had the discussion several times with our customers, and more recently with several Microsoftees and MS partners. The discussion boils down to “SLAs for Azure are complex, and you might not get what you think”. And I’ll add “you might get better or worse than you are used to on-premises”. Quick reminder, the official SLA website is here : https://azure.microsoft.com/en-us/support/legal/sla/ They are adapted quite frequently and what I write today might be proven wrong very soon. Yes, it happens, sometimes I am right for a long time :) Back to our SLAs. I will focus on one service, but the idea can be expanded to almost all services. Some services SLA are quite easy to figure out. Take Virtual Machines (Azure or not) for example. You just have to decide what metric proves that a VM is alive (ping reply for example), and measure that. Do some computation at the end of the month, and you’re done. With backups, the official SLA (https://azure.microsoft.com/en-us/support/legal/sla/backup/v1_0/) is a monthly uptime percentage. Which does not mean much for me, speaking of backups. Luckily, there is a definition of “downtime” : “Downtime” is the total accumulated Deployment Minutes across all Protected Items scheduled for Backup by Customer in a given Microsoft Azure subscription during which the Backup Service is unavailable for the Protected Item. The Backup Service is considered unavailable for a given Protected Item from the first Failure to Back Up or Restore the Protected Item until the initiation of a successful Backup or Recovery of a Protected Item, provided that retries are continually attempted no less frequently than once every thirty minutes. Meaning basically that the “backup service” has to be available at all time, whether you try to backup or restore. But, and there are actually two buts, there is not hard commitment there. Microsoft will give you back a service credit if the service is not provided, to the limit of a 25% credit. Eventually, you could get no service at all for a month, and you would get a 25% service credit. And the second, more important, but, there is absolutely nothing about a guarantee on your data. You could lose all of your data, and at most get a 25% service credit. Some people would then point you to the storage SLA, stating that once the backup is stored, the SLA that applies is the one from storage. Another but here, as we are in the same situation : no commitment about your data. One note : I never looked closely at the SaaS services SLAs (Office365 for example), but I remember someone from Microsoft IT saying that it was too difficult, and expensive, even for them, to build the infrastructure and services to compete with what Office365 offers. So yes, you might dig into their SLAs, and find that they have a light hand… but think hard on what you can do yourself, and how much it would cost you :) Do not get me wrong, Microsoft does a quite good job with its SLAs, and from my experience, a way better job that most companies can do internally or for their customers. I worked for a hosting company, and I can assure you that we could write down an SLA about backups, and even commit to it. We could pray that we would be right, and prepare the compensations in case we were at fault, but that was it. There was no way for us to economically handle a complete guarantee.

Bring your containers to the cloud

Wed, 10 Jan 2018 00:00:00 +0000

Cloud and containers, two buzzwords of the IT world put together. What can go wrong? This post is a refresh on a previous one (https://cloudinthealps.mandin.net/2017/03/24/containers-azure-and-servicefabric/) with a focus on containers, rather than the other micro-services architectures. As usual, I’ll speak mainly of the solutions provided by Microsoft Azure, but they usually have an equivalent within Google Cloud Platform or Amazon Web Services, and probably other more boutique providers. And let’s be more specific, considering what happened in the container orchestrator world in the recent weeks. I am of the general opinion that this war is already over, and Kubernetes has won. Let’s focus on how to run/use/execute a Kubernetes cluster. First step : you want to try out Kubernetes on your own. The ideal starter pack would be called Minikube ( https://github.com/kubernetes/minikube) . I already wrote about it, the good thing about it is that you can run a Kubernetes installation on your laptop, in a few minutes. No need to worry about setting up any cluster and configurations you do not understand at all. You might want to play out a bit with Kubernetes the hard way, in order to be able to understand the underlying components. But that is not necessary if you only want to focus on the running pods themselves. Now you are ready to run a production workload Kubernetes Cluster. And you would like to handle everything on your own. There are many ways to get there. First, you want to deploy your own cluster, not manually but on your own terms. There is a solution, kubeadm (https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/), that will help you along the way, without having to do everything by hand. This is a solution that is compatible with any underlying hardware, cloud, virtual or physical. On Azure specifically, there are two concurrent solutions to build your Kubernetes cluster : ACS (https://azure.microsoft.com/en-us/services/container-service/) & ACS-engine ( https://github.com/Azure/acs-engine). ACS (Azure Container Service) is mostly a deployment assistant, that will ask you the relevant questions on your K8s deployment, and then create and launch the corresponding ARM template. After that, you’re on your own. And you may download the template, edit it and re-use it anytime you want! ACS-Engine is a command line customizable version of ACS, with more power to it :) I feel that both are Azure dedicated versions of Kubeadm, but they do not add value to your production. They still are good ways to quickly deploy your tailored cluster! BTW, if you go to the official webpage for ACS, it now just speaks about AKS, and you’ll have to dig a bit deeper to find out about the other orchestrators ;) What if you could have your K8s cluster, be able to run your containers, and just have to manage the clustering and workload details? There is a brilliant solution called AKS (https://azure.microsoft.com/en-us/services/containerservice/) , and no it does not stand for Azure K8S Service… It actually means Azure Container Service. Don’t ask. With that solution you just have to take care of your worker nodes, and the running workloads. Azure will manage the control plane for you. Nothing to do on the etcd & control nodes. Cherry on the top : you only pay for the IaaS cost of the worker nodes, the rest is free! In my opinion, it’s the best solution today, it offers you a wide flexibility and control on your cluster, at a very low cost, and lets you focus on what is important : running your containers. One last contestant to join the ring : Azure Container Instances (https://azure.microsoft.com/en-us/services/containerinstances/). This solution is still in Preview, but might become a strong player soon. The idea is that you just care about running your container, and nothing else. For now it is a plugin for an actual K8S cluster, that will present itself as a dedicated worker node, where you can force a pod to run. I did not have time to fully test the solution and see where the limits and constraints are, but we’ll probably hear from this team again soon.

Certifications

Wed, 04 Oct 2017 00:00:00 +0000

I have been pushing my team to get certified on Azure technologies for the past 24 months, with various degrees of success. I am quite lucky to have a team who does not discuss the value of the certification, however much they discuss the relevance of the questions. But, as I am now going over almost 15 years of certifications in IT, I feel quite entitled to share my views and opinion. Keep in mind that I work in infrastructure/Operations, and in France, which will probably give some bias to my analysis :) I will start with some general comments on the value of certifications, from a career perspective, and dive into some specifics for each vendor I have certified with over the years. Some of my exams are a bit dated, so please be nice. I will conclude with my general tips to preparing for an exam. As I said, it’s been almost 15 years since my first cert, and I started that one before even being employed, that gives me some insight about the relevance of such investment in my career. I took my first dip into the certification world during a recruitment process with a consulting company. We were two candidates, I was the young guy and the other one was already holding his Microsoft MCP. I felt, at that time, that I could benefit from one myself, and compensate some of my lack of experience with it. As I registered for my first MCP exam, for Windows 2000 (!), I was contacted to get into a kickstart program to get my certification level up to Microsoft MCSE, everything started from there. After a few months, I passed the final MCSE exam (out of 7 at that time) and was recruited, to work on Cisco networking, which had nothing to do with my skills, by the very same company that had interviewed me when I discovered the MCP. I still think that the fact that I went through the certification path did a lot to convince my boss to be of my motivation and ability to work hard. Over the years I refreshed my MCSE with each version of Windows (from 2000 to 2016) and added a few new ones, depending on what I worked on at my positions : Cisco, RedHat, Vmware and Prince2. Even though it was not obvious in my first job, the following ones were pretty clear cases where my certifications held some value to my employer. We discussed the fact during some of the interviews rather openly. And I was in a recruiter’s shoes myself a few times, and here is why I feel is useful regarding the certifications. First it show that you can focus on sometimes gruesome work, for a while. Passing these kind of exams almost always forces you to learn tons of new information, on software or devices that you maybe never handle. Then it show dedication to maintain them over time, when they have at least some value to your current position. And, let’s be candid, it show you can take one for the team, because almost every vendor partnership requires some level of certification. And, as I said, I know for a fact that I had been recruited, at least partly, twice thanks to my certs. On the salary part, I am not definite on the impact of certifications. I do not feel that the cert plays a part there, but I cannot prove or disprove it. That being said, when you take one of these exams, you will experience very different things depending on the vendor, and sometimes on the level of certification. Let’s take a closer look. We’ll start with my longest running candidate : Microsoft. Apart from one beta test ten years ago, I always had some kind of MCQ with them. You may have some variation around that : drag and drop, point and click etc. But, by and large nothing close to a simulator or designer. This had led to a bad reputation a while ago, when you may have had an MCSE (which was like the Holy Grail of Microsoft certification) while having absolutely no hands-on experience with Windows. They have kept the same format for Azure exams, and are taking some heat also, because the exams are deprecated almost as they go out. I am wondering whether they are working on some other way to certify. Cisco had a router/switch simulator for a long time, which had brought some rather interesting exams, for the lowest levels. I only took the CCNA 15 years ago, so I do not know how it goes for higher levels. The only caveat, from my perspective, was that the simulator did not allow for inline help and auto-completion, which you still have in real life. RedHat, for the RHCE exams, had the most interesting experience in my view. The exam was completely in a lab, split in two sections. First you had to repair a broken RHEL server, three times. Then you were given a list of objectives that you had to meet with a RHEL server. You could choose whichever configuration you would prefer, as long as the requirements were met (with SELinux enforced, obviously :) ). You had a fully functional RHEL, with the man pages and documentation, but without an internet access. I still feel to that day that this way let you prove that you really were knowledgeable and had the necessary skills to design and implement a Linux infrastructure. And the trainers were always fun and very skilled. I also certified on Vmware Vsphere for a while and that brought me to a whole new level of pain. The basic VCP level is fine, just along the same lines as an MCP. But when I started to study for the next level, VCAP-DCD (which stands for Vmware Certified Advanced Professionnal-DataCenter Design), I had to find some new ways of preparing and learning. You see, where a usual exam requires you to learn some basic stuff by heart (like the default OSPF timers, or the minimum Windows 2000 workstation hardware requirements) it was still a limited scope. For this exam, you had to be able to completely design a Vsphere infrastructure, along the official Vmware guidelines, form all of the perspective

Kubernetes and Azure Container Instances

Thu, 24 Aug 2017 00:00:00 +0000

Following my recent ventures in the Kubernetes world (http://cloudinthealps.mandin.net/2017/08/23/kubernetes-thehard-way-azcli-style/), I now had a functional Kubernetes cluster, on Azure, built with my own sweat and brain. But that was not the original goal. The original goal was to try and play with Azure Container Instances, and its Kubernetes connector https://azure.microsoft.com/fr-fr/resources/videos/using-kubernetes-with-azure-containerinstances/ Following the guide on GitHub was relatively straightforward and painless (https://github.com/Azure/aci-connectork8s), but I encountered two small issues. One was that I am not completely comfortable yet with all things K8s, and I had to read a bit about taints, to understand why the current ACI connector is not used by the K8s scheduler by default. Not a big deal, and a good way to get to know more about K8s. The second one was maybe due to the fact that I had never used ACI before, maybe not. I logged it into the GitHub project as an issue (https://github.com/Azure/aci-connector-k8s/issues/33) to make sure that it is taken into consideration. Short story was that I was missing a registered Provider in my subscription. However the error message did not pop up in kubectl output, but only on the Activity log in Azure portal. Another good occasion to learn an dig into some tools.

Kubernetes, the hard way, AZCLI style

Wed, 23 Aug 2017 00:00:00 +0000

Finally a tech post! I have been busy this week, on command lines and Kubernetes. The starting point was the recent announce for Azure Container Instances and the related Kubernetes conenctor : https://github.com/azure/aci-connector-k8s I admit I did try what Corey Sanders showed in his show : https://channel9.msdn.com/Shows/Tuesdays-WithCorey/Tuesdays-with-Corey-Azure-Container-Instances-with-WINDOWS-containers. However what I found interesting and wanted to try was the ACI connecter to Kubernetes, and how we would work with that. Of course we have a test Kubernetes cluster here, that someone from our tema built, but it felt too easy just to add the connector. Also I am not comfortable yet with Kubernetes and I wanted to get my hands dirty and know more about the inner workings of a k8s cluster. I remembered a quote from the Geek Whisperers’ show featuring Kelsey Hightower. He said that he wrote a guide to build a K8s cluster from the ground up, without any shortcuts. The guide is found there : https://github.com/kelseyhightower/kubernetes-the-hard-way The downside is that the guide is aimed at Google Cloud Platform, and I am an Azure guy. And there was my pet project for this week : adapt the guide for Azure, using only Azure CLI commands! There was one final trick for me to learn : store and share all that on GitHub. As I never had to work with Git by myself, it was also a good way to learn the moves. So, lots of new stuff learnt : • Create a K8s cluster from scratch • GitHub, and Git • Making progress on Azure CLI • A good refresh and Azure infrastructure The project is hosted there : https://github.com/frederimandin/Kubernetes-the-azcli-way There are many following steps to work on : • Integrating properly with Kelsey’s guide • Testing my own guide again • Adding ACI connector to my cluster and play with it (and write about it of course!) I’ll keep you posted, of course!

Choosing between IaaS, PaaS and SaaS (maybe containers?)

Fri, 07 Jul 2017 00:00:00 +0000

I know, there are tons of materials and training that will explain you how to select between SaaS and custom software. I’ll summarize their usual points, but I wanted to add some details on how you might have to look at the full scope of cloud services : from Iaas, through PaaS, to Saas, and a detour through containers. First the usual discussion, that have seen unfurl dozens of times : why choose SaaS over a custom/on-premises solution? You know the drill, right? On one side, you have full control and can customize the solution. This means the software will be tailored to your exact needs, and you will control exactly what is done with it, how is updated, where data is stored, accessed, replicated, backed-up etc. You will know the exact setup of the deployment, which layer is connected to which other layer, how, where traffic goes, how each layer is protected, and replicated. You will handle failover, high-availability etc. In a few words : you will be the master in your own kingdom. Problem with that path : you are, mostly, on your own. All of these domains I just listed are your responsibility, and you have to have knowledge and skills to handle those. You might need to expand those skills to cover 24*7. You’ll need a strong IT team, in addition to a trained software team. On the other side, you have SaaS : bright new, quick and easy. You set that up in a flash, connect the solution to your other enterprise software, create user accounts and voilà! No administrative overhead, the only skill you have to master is the configuration of the solution. You’ve seen the downside coming : you have absolutely no control over the software, its release cycle, the mechanisms in place to provide high-availability. Sometimes you have some control over your data, but it’s not obvious. In the end it’s your call to choose the balance you need. The cloud has integrated the same choices and solutions. You will have to decide whether you want to use IaaS, PaaS or SaaS. The basic triggers are the same, you choose the right balance between control, freedom and responsibility. Read here a good explanation : https://docs.microsoft.com/fr-fr/azure/app-service-web/choose-web-site-cloud-servicevm I would like to add something to that horizon, something spicier, which could probably give you the best of each solution, provided you are ready to learn some new skills. We had the same discussion several times with our customers, revolving around the limitations of Azure App Service for some Java applications, its lack of control, and how moving from that to a full-blown IaaS virtual machines felt like dropping out of the cloud. Here what we built with some of those customers. We wanted to provide them with the flexibility and ease of use of Azure App Service, tailored to their needs, without adding much IT admin overhead. We had already been running a Kubernetes cluster for our own internal needs for a while, and it was an easy leap to suggest that solution. Kubernetes is becoming the leader in container orchestration, but you could choose any other solution (DCOS, Swarm etc.) Here is a short list of the benefits the customer gained in that solution : • Flexibility of the deployment and settings of the application, down to every Java VM option • Scalability of an enterprise-ready container orchestration, based on a cloud platform that is reliable • Ease of deployment : these are containers after all! The only thing you have to keep in mind here is that someone has to learn and master containers and the orchestration layer for those. Kubernetes might not be the most accessible solution here, but it is, in my mind, the most mature and powerful. One last word, for you sceptics who still believe that Microsoft and Open-source are still far from each other : try to make a new build of your software for containers using Visual Studio : https://blogs.msdn.microsoft.com/jcorioland/2016/08/19/build-push-and-run-docker-images-with-visual-studio-teamservices/

PaaS and Managed Services

Sat, 20 May 2017 00:00:00 +0000

If you know me, or have read some of my previous articles, you will know that I am a big fan of PaaS services. They provide an easy way for architects and developers to design and build complex applications, without having to spend a lot of time and resources on components that may be used out of the box. And it relieves us IT admins of having to manage lower levels components and irrelevant questions. These questions are the ones that lead me to switch my focus into cloud platforms a few years ago. One day I’ll write an article on my personal journey :) Anyway, my subject today concerns the later stages of the application lifecycle. Let’s say we have designed and built a truly modern app, using only PaaS services. To be concrete, here is a possible design.

The first steps of your cloud trip

Tue, 14 Mar 2017 00:00:00 +0000

When I talk to customers who are already knowledgeable about the cloud, but still have not started their trip, the main subject we discuss about is : what is the first step to take to move into the cloud? Usually at that point we all know about the cloud and its various flavors, on a personal level. I have touched already the subject on how to start playing with the cloud as a person :http://cloudinthealps.mandin.net/wp-admin/post.php?post= 60&action=edit. But it’s not that easy to translate a personal journey and knowledge to a corporate view and strategy. There are two major ways to plan that journey. The first is : move everything, then transform. The second is : pick the best target for each application, transform and migrate if needed. Lift and shift I will touch quickly on the first path. It’s quite a simple planning, if difficult to implement. The aim is to perform a full migration of your datacenter into the cloud, lift-and-shift style. This can be done one-shot or with multiple steps. But in the end you will have moved all of your infrastructure, mostly as it is, into the cloud. Then you start transforming your applications and workload to take advantage of the capabilities offered by the cloud, in terms of IaaS, PaaS or SaaS offerings. The difficulty in there, for me, is that not all workloads or applications are a good fit for the cloud. Identify you application portfolio Enters the second solution : tailor the migration to your applications. Because the application is what matters in the end, along with the impact and use of this application for the business. The question of how you virtualize, or which storage vendor to choose is not relevant to your business. In that case you will have to identify all of your application portfolio, and split that into for categories :

Containers, Azure and Service Fabric

Wed, 15 Feb 2017 00:00:00 +0000

Today I will try to gather some explanations about containers, how they are implemented or used on Azure, and how this all relates to micro-services and Azure Service Fabric. First let’s share some basic knowledge and definitions. Containers in a nutshell To make a very long story short, a container is a higher level virtual machine. You just pack your application and its dependencies in it, and let it run. The good thing about those is that you do not have to pack the whole underlying OS in there. This gives us lightweight packages, which could be around 50MB for a web server for example. Originally, containers were designed to be stateless. You were supposed to keep permanent data out of those, and be able to spin out as many instances of your applications to run in parallel, without having to bother about data. This is not completely true about most deployments. Today many containers are used as lightweight virtual machines, to run multiple identical services, each with its instance. For example, if you need a monitoring poller for each new customer you have, you might package this in a container and run one instance for each client, where you just have to configure the specifics for this client. It’s simple, modular and quick. The stateless versus stateful containers is a long standing one, see [link to statefull vs stateless] Orchestration Just like in virtualization, the case is mostly not about the container technology and limits, but rather about the tools to orchestrate that. Vmware vCenter versus Microsoft SCVMM anyone? You may run containers manually above Linux or Windows, with some limitations, but the point is not to have a single OS instance running several services. The point is to have a framework where you can integrate that container and instantiate it without having to tinker with all the details : high-availability, load-balancing, registration into a catalog/registry etc. The video below is very good at explaining that : The Illustrated Children’s Guide to Kubernetes

How to Embrace Azure

Tue, 22 Nov 2016 00:00:00 +0000

For the last year, I have been meeting with customers and partners inside and outside the Microsoft ecosystem. I have talked with friends that are involved, at different levels, with IT whether Dev or Ops. I have been trying to explain what the public Cloud is, especially Azure, to many different people. Of course, I have been using the same evolution charts we all seen everywhere to illustrate my speech and explain where I believe we are headed.