Cloud on Cloudinthealps

Mes premières impressions sur les Realwear HMT-1

Wed, 08 Dec 2021 00:00:00 +0000

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.

Le cloud souverain, oui mais comment?

Mon, 25 Nov 2019 00:00:00 +0000

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.

La fin des POCs

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

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.

IoT Challenges

Fri, 24 Aug 2018 00:00:00 +0000

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.

Autonomous versus autonomic systems

Wed, 16 May 2018 00:00:00 +0000

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.

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.

IoT everywhere, for everyone

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

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 :

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.

Cloud is for poor companies

Thu, 21 Dec 2017 00:00:00 +0000

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 :

New security paradigms

Mon, 09 Oct 2017 00:00:00 +0000

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.

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/

My journey to the cloud

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

I may have skimmed that subject a few times before, but as I get to the end of the (Microsoft) year, and begin a new one, it feels right to reflect for a while on what got me where I am now. The short version is : I got enough of cabling, servers, storage and operating systems, and wanted to move to something else, however related. Okay, that is VERY short. Allow me to develop that further. I started working in IT about 15 years ago. I did my duties in user support, moved to network engineering and implementation. At the same time, I discovered the wonderful world of Microsoft training and certification, and got my first cert around 2003, quickly followed by an MCSE (yes, on Windows 2000!). I switched back and forth between networking and systems engineering for several customers. I collected some knowledge along the way, mainly about hardware installation, cabling, storage and servers, but also about virtualization, networking, SAN. I continued my cert trip in parallel, maintaining my MCSE up to Windows 2016 and Azure. I also collected a few other certs : ITIL, Redhat RHCE (6 & 7), Vmware VCP & VCAP-DCD, Prince2 etc. I will say more about certification in a later article, keep in touch! To complete the brush-up, I tried my hand at project management, as well as people management. Let’s get to the point where it gets interesting. First time I heard about public cloud was at Tech-Ed Europe, probably in 2010. It was mostly limited to SQL server databases with many limitations. It was not really a hit for me. The subject kept reappearing : public cloud, private cloud, elastic computing, you’ve heard the talk. There were actually two triggers to my “Frederi, meet Cloud” moment. The first one was rather a long term evolution of my area of interest. After years spent working with the same company, and on the same software, I got to the point where I could understand the business side of my actions and responsibilities for our customers. It was a slow shift to a more end-user/application centric approach. This is where I try to push today : the major focus and metric is the end-user. If this user is not happy about his experience, then we (the whole team behind the software, from IT infrastructure to developers and designers) have failed. This is why I tend to ask the question early in the discussions : how is the application used? By who? The second trigger was more of a “a-ha” moment, specifically about public cloud. In a previous job, I was in an outsourcing team, focused on infrastructure. We had a whole Services department, whose job was to design build and deliver custom software. We almost never had a project in common. Until once we had a developer on the phone, and we had the most common conversation between dev and ops : Dev : “we have built a php application for that customer, and he wants to know if we can host and operate it, and what the cost would be” Ops (me) : “OK, tell me your exact need : OS, VM size, which web server, which version, how much disk space, a public IP etc?” Dev : “I do not know that” Ops : “in that case, I cannot give you an estimate. We can operate, but we need to know what” Follow a few days of emails trying to get those details ironed out and try to write a proposal. Two weeks later, we had the same dev on the phone : “Drop it, the customer has already deployed in Azure by himself”. That is when I realized that we, ops and infra, could not stay on the defense line and ask for what we knew best. We had to ask about the application itself, and we had to get into that “Azure” stuff. And that’s how I ended up in Azure, and mostly PaaS oriented ;)

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 :

Why I love working on IT & the cloud

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

I remember when I started working full time in IT, all the young professionals were employed by large contractors and consulting firms. The word then was “please help me find a job with a customer/end-user!”. When I recruit today, mostly people a bit younger than me, the word has shifted to “I love working for a contractor, as it does not enclose me in one function”. OK, I did think about that early today, and wanted to write it somewhere, so I used it as an intro, to show my deep thinking in the wee hours of the morning. However what I wanted to write about more extensively was about how I love working in IT today, and particularly on Cloud solutions, and how it is gratifying, compared to what we experienced a few years back. Technology centric and support functions Not so long ago, IT was a support function, and was supposed to keep the hassle of computers to a bare minimum. When interacting with our customers and users, the main issues and questions were about how we kept printers running, and emails flowing. If you worked on ERP or any management system, same thing : please keep that running so that we can do our job. For years, we had team members who loved technology, who delve deep into configuration and setups so that we could congratulate ourselves in building shiny new infrastructures, to try to keep up with users' demand. I will keep the example to my own situation. I went through technological phases, from Windows 2000 Active Directory, to Cisco networking, to virtualization, to SAN storage and blade servers, to end up on hyper-converged systems. For years I would generally not talk shop with friends, family or even friends from school (I went to a mix business/engineering school, so that could explain things). I did not see the point on digging into technical points with people from outside my “technological comfort zone”. Don’t misunderstand the situation, I was aware IT department trying to shift their role from support function to help the business, but it was a bit far-fetched for me. Then came public cloud… Business centric, and solution provider At first we had a simplistic and limited public cloud (Hello 2010!), and a private cloud which was just virtualization with a layer of self-service and automation. I could begin to see the point, but still… it was a technologist dream of being able to remove a large portion of our day to day routine. Situation evolved to a point where we had real PaaS and SaaS offerings that could solve complex technical solutions with a few clicks (or command lines, don’t throw your penguin at me!). And I started to talk with my customers on how we could help them build new solutions for their business, give them better quality of service, and have them understand me! Of course some of that is linked to my experience, and the fact that am not in the same role as I was 10 years ago, but still. I now enjoy discussing with my former schoolmates and help them figure out a solution to a business issue, being able to help some friend’s business grow and expand. IT can now be a real solutions provider. We have to work at gaining sufficient knowledge on all the cloud bricks to be able to build the house our business does not know they need.

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.