Cloud

Et voilà, j’ai lâché quelques teasers, maintenant je dois assumer. Nous sommes donc partis pour mes premières impressions au déballage de cet appareil étrange, un unboxing quoi :-). J’ai pu donc, courtesy of Lenovo, avoir entre mes mains un Realwear HMT-1, et mener quelques essais : mise en route et configuration manuelle Installation d’une application, utilisation des lunettes avec un document PDF, et essais de base Utilisation de la plate-forme Foresight by Realwear Je parlerais sûrement de Lenovo Thinkreality, la plate-forme dédiée à la gestion des devices de XR, mais cela fera l’objet d’un second article, celui-ci sera déjà bien assez long. ...

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

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

After a long summer break, getting back to writing is a bit difficult, so here is a first post for a new era. I’ll be switching jobs early September, so there might a slight variation in the subjects I’ll write about. As highlighted in Gartner 2018 Cycle of Hype study, IoT is now a mature tech and we will see more and more large scale projects being deployed in the wild. I would like to expand a bit about what it entails to start an IoT initiative, whether it be to design a new product to sell, or to gain some insight and improve your own processes. The steps are familiar to anyone who has ever come close to a project in his/her life: 1. 2. 3. 4. 5. 6. ...

This is a difficult topic. I have to admit I am still not completely comfortable with all the concepts and functions. However, the thinking is amazingly interesting, and I will take some time to ingest everything. First things first, I will use this post to summarize what I have learned so far. How did I end up reading that kind of work, you ask? Weeeellll, that’s easy :) Brendan Burns, in one of Ignite ‘17 sessions, used the comparison “autonomous vs autonomic” to discuss Kubernetes. This got me thinking on the actual comparison, and aided with our trusted friend, Google, I found a NASA paper about that (https://www.researchgate.net/publication/265111077 _Autonomous_and_Autonomic_Systems_with_Applications_to_NASA_Intelligent_Spacecraft_Operations_and_Exploration_Systems) I started to read it, but it was a bit obscure for me, and scientific English, applied to space research, was a bit too hard for an introduction to that topic of autonomic systems. Some more research, helped by me beloved wife, led to a research thesis, in French, by Rémi Sharrock (https://www.linkedin.com/in/tichadok/). The thesis is available right there : https://tel.archives-ouvertes.fr/tel-00578735/document. This one relates to the same topic, but applied to distributed software and infrastructure, which ends up being way more familiar to me :) The point where I am right now is just over getting the definitions and concepts right. I will try to describe what I understand here about automated, autonomous and autonomic systems. There is some progression from the first to the second, and from the second to the third concept. Let’s start with automated. An automated system is just like an automaton in the old world : something that will execute a series of commands, on the order of a human (or another system). For example, you have a thermostat at home that send the temperature from inside and outside your home to the heater controller. ...

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.

Today is another tentative to explain part of the Microsoft Azure catalog of solutions. As I did write about the different flavors of containers in Azure, I feel that it’s time for a little explanation about the different ways of running you IoT solution in Azure. There are three major ways of running an IoT platform in Azure : build your own, Azure IoT Suite and IoT Central. There are some sub-versions of those, that I will mention as I go along but these are the main players. I have listed those in a specific order, on purpose : ...

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.

I heard that statement from Greg Ferro (@etherealmind https://twitter.com/etherealmind) in a podcast a few weeks back. I have to admit, I was a bit surprised and had a look at Greg’s tweets and posts, while finishing up the podcast. Of course, the catchphrase is aimed at shocking, but it is quite well defended, and I have to agree, to some point with Greg on that. Let me try to explain Greg’s point, as far as I have understood it. The IaaS/PaaS platforms, and some of the SaaS ones, are aimed at providing you with on the shelf functionalities and apps, to develop your product quicker. And also to let you focus on your own business, rather than building every expertise needed out there to support your business. However, there are some underlying truths, and even drawbacks : ...

Obviously you have heard a lot of talk around security, recently and less recently. I have been in the tech/IT trade for about 15 years, and every time I have met with a new vendor/startup, they would start by saying that we did security wrong and they could help us built Next Gen security. I am here to help you move to the Next Gen :) All right, I am not. I wanted to share a short synthesis of what I have seen and heard over the past months around security in general, and in the public cloud in particular. There are few statements I did find interesting : • Perimetric lockdown, AKA perimeter firewalls, is over. • No more need for IDS/IPS, in public cloud, you just need clean code (and maybe a Web Application Firewall) • Public cloud PaaS services are moving to an hybrid mode delivery Of course, these sentences are not very clear, so let me dig into those. First, perimeter security. The “old” security model was built lake a medieval castle, with a strong outer wall, and some heavily defended entry points (Firewalls) There were some secret passages (VPNs), and some corrupted guards (Open ACLs :) ). https://commons.wikimedia.org/wiki/File:Herstmonceux_Castle_with_moat.jpg This design has lived and is not relevant any more. It is way too difficult to manage and maintain thousands of access lists, VPNs, exceptions and parallel Internet accesses, not mentioning the hundreds of connected devices that we have floating around. A more modern design, for enterprise networking, often relies on device security and identity management. You will still need some firewalling around your network, just to make sure that some dumb threat cannot go in by accident. But the core of your protection, networking-wise, will be based on a very stringent device policy that will allow only safe devices to connect to your resources. This solution will also require that you have a good identity management, ideally with some advanced threat detection in place. Something that can tell you when some accounts should be deactivated/expired, or when you have abnormal behavior : for example, two connections attempts for the same account, from places thousands of kilometers apart. For those who have already setup 802.1X authentication and Network Access Control on the physical network for workstations know that it requires good discipline and organization to work properly and not hamper actual work. To complete the setup, you will need to secure your data itself, ideally using a solution that manages the various levels of confidentiality, and can also track the usage and distribution of the documents. As I said No more need for IPS/IDS. Actually, I think that I have never seen a real implementation that was used in production. Rather there was almost always an IPS/IDS somewhere on the network, to comply with the CSO’s office requirement, but nothing was done with it, mostly because of all the generated noise. Do not misunderstand me, there are surely many true deployments in use that are perfectly valid! But for a cloud application, it is strange to want to get down to that level where your cloud provider is in charge of the lower infrastructure levels. The “official” approach is to write clean code, to make sure that your data entry points are protected and then to trust the defenses in place from your provider. However, as many of us do not feel comfortable enough to skip the WAF (Web Application Firewall) step, at least Microsoft has heard the clamor and will add the possibility to connect a WAF in front of your App Service shortly. Note here : it is already possible to insert a firewall in front of an Azure App Service, but this requires a Premium service plan, which will come at a ahem premium price. And that was my third point : PaaS services coming to a hybrid delivery mode. Usually when you look at PaaS services in the public cloud, they tend to have public endpoints. You may secure these endpoints with ACLs (or NSG for Azure), but this might not be very easy to do, for example if you do not have a precise IP range for your consumers. This point had been discussed and worked on for a while, at least at Microsoft, and we are now seeing the first announcements for PaaS services that are usable through a Vnet, and thus private IP. This leads to a new model, where you may use these services, Azure SQL for example, for your internal applications, through a Site-To-Site VPN.