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.

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.

The original title was supposed to be “in bed with GDPR”, but it might have been a little too clickbait :) Anyway, short post today, but an important one, I think. To be honest, I feel like screaming everytime I see/read/hear someone telling me that “we need to have a GDPR offer/business/thing”. Alright, it is a buzzword, and I have to live with that. I have made my peace with AI, Blockchain, Big Data, IoT , Cloud, etc. But I still struggle with GDPR. Here is why. First this policy is a very important one in Europe, and will impact every business that comes anywhere close to us. You cannot ignore it. And every company has to look into it and find out what is needed to be compliant. Second, the deadline is looming, but the national law for France is not yet in application. There is a text that is discussed (https://www.legifrance.gouv.fr/affichLoiPreparation.do;jsessionid=?idDocument=JORFDOLE000036195293 &type=contenu&id=2&typeLoi=proj&legislature=15) but there might still be many changes before the law is applied in France. That means that we should hurry to wait, but be prepared… tough one. Last, and most important, and the main reason of my screaming : it is mostly a question of law, for lawyers. Sure IT has to get ready to comply, but most of the consulting and debating and discussing has to be managed by law experts, which will be the right people to understand what it will mean to be compliant. Sure an IT company can get some services in place, offer some broad suggestions and consulting. But without a lawyer, trained for that (and a proper written and voted law…) our job is almost meaningless.

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

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

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.

Yes, DevOps is the new black. I might not be the first to use the phrase, but it’s so obviously true. I am currently working on building some kind of offer around DevOps, so you’ll probably see more posts on the topic. But two things struck me recently and I decided I would make a post out of those. Both items are related to the people side of DevOps. The first is the importance of the people involved in your DevOps transformation or organization. The second, corollary to the first, is the recruitment of these people. People matter People are important, that’s obvious. However a customer experience has lately surfaced the importance for a successful DevOps transformation. I may not be able to go into many details but the broad outline is quite simple. The organization is a software team, within a large company. It delivers its own product, to be used by other business units. It has decided to run its own operations. Perfect candidate for DevOps, right? Using a custom approach, based on industry standards, an Agile/DevOps organization is designed and implemented. Fast forward one year. The transformation is quite successful, the stability and quality of the product have improved. The only thing that prevented the team to be outstanding seems to come from the people. Don’t misunderstand me, I am not judging this team and its members. But for an Agile/DevOps transformation to be successful you need the right people, with the right mindset. And not everyone fits the bill. Like some people are more comfortable in an open-space and some prefer a closed-off office. It has been the same with Agile practices, which could not apply to every situation and team. We need to pay extra attention to the people we include in these transformation projects, if we want them to succeed. Recruitment is crucial As a follow-up of the above assessment, recruitment of people for your team is important. Yes, I know, it has always been important. However, take a second look at the title of this post. Done? Alright. Now have a look at the job offers in IT. See any pattern? DevOps is written everywhere. It is somehow justified, as DevOps encompasses many modern practices that we have or would like to implement. Take automation, continuous delivery, continuous deployment, testing, QA etc. The issue is that not every job offer is for a DevOps team or project. Most of the offers are for traditional sysadmins or developers with a hint of DevOps. Which is a good trend, but not a good fit for a full devops profile. So, people matter in DevOps environments, so take care of your profile :) Note : this post was inspired by a LinkedIN post that I cannot find, in french, regarding the abusive use of DevOps in job postings in France. If anyone can find it, I’d love to thank and credit its author!

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

I already posted about this event a few weeks ago, with a focus around my experience and the organization : https://cloudinthealps.mandin.net/2017/11/03/velocity-london-2017/ This time, I would like to share a short summary of what I have learned during these 4 days. The first two days were a Kubernetes training, so nothing very specific here. I learnt a lot about Kubernetes, which is to be expected :) During the two conference days, I attended the keynotes, and several sessions. The keynotes are difficult to sum up, as they were very different, and each was a succession of short talks. I attended several large-scale conferences in the past, and that was the first time that I felt that the speakers were really on the edge of research and technology. They were not specifically here to sell us their new product, but to share where their work was headed, what the outcomes could be etc. They broached subjects ranging from bio-software to chaos engineering, from blockchain to edge computing. Some talks were really oriented toward IT & DevOps, and some were bringing a completely different view on our world. Overall, it felt energizing to hear some many brilliant minds talk about what is mostly our future! The sessions were a bit more down to earth and provided with data, content and feedbacks that would bring us some changes back home. I was surprised to have most sessions concentrate on general information and feedback, and not so much on specific tools and solutions. I expected more sessions from the toolchains for DevOps (Chef, Puppet, Gitlab, Sensu and so on). Actually, even when the session were presented by these software companies (Datadog, Yahoo, Bitly, Puppet, PagerDuty) they never sold their product. However they used their experience and data to provide very useful insights and feedbacks. What I brought back could be split into two categories : short term improvements/decisions that could be implemented as soon as I got back (which I did partly), and trends that would have to be thought about and analyzed, and then maybe crafted into a new offer or approach. In the first category : • Blameless post-mortems. A lot of data analyzed, with one takeout for us : keep the story focused and short. If you do not have anything to add apart from the basic timeline… maybe you’re not the right team to handle the postmortem :) • Solving overmonitoring and alert fatigue. This talk was a gamechanger for me. What Kishore Jalleda (https://twitter.com/KishoreJalleda) stated was this : you may stop monitoring applications and services that are not respectful. For example, if you get more than X alerts everyday from an application, you may go to the owner of the application and say “as you are generating too much noise, we will disable monitoring for a moment, until the situation comes back to something that is manageable by the 24*7 team” Of course you have to help the product team get back on track and identify what is monitoring and what is alerting (https://cloudinthealps.mandin.net/2017/05/12/monitoring-and-alerting/). And you need top management support before you go and apply that :) • On the same topic, a session about monitoring containers came down to the same issue : how do you monitor the health of your application? Track the data :) The second group covered mostly higher level topics, on how to organize your teams and company for successful DevOps transformation. I noted an ever spreading use of the term “SRE”, which I would qualify of misused most of the time. At least SRE seems now to qualify any team/engineer in charge of running your infrastructure. Another trend, in terms of organization, was the model based on this famous SRE team, to provide tooling and best practices for each DevOps/Feature/Product team. I’ll probably post at length sometime later.

This October I had the opportunity to go at the Velovity conference in London (https://conferences.oreilly.com/velocity/vl-eu). The exact title of the conference is “Build and maintain complex distributed systems”. That’s an ambitious subject. The event had been suggested by a customer who went to one of the US editions and found that it was a brilliant event, both in terms of DevOps subjects covered and in terms the attendees & networking. So here I am, back in London, for 4 days of DevOps and cloud talks. [logo conf] I have started the conference with a special 2-days training on Kubernetes, by Sebastien Goasgen (@sebgoa) [logo k8s] The training was really intense, as Sebastien described many standard objects and tools of the platform, as well as a few custom options that we can use. We played with Minikube on our laptops, which is a really great way to have the experience of a Kubernetes cluster, in a small box. It was really packed, and we had to rush to keep up with Sebastien’s tests and labs, even with his Github repo containing most of the scripts and K8s manifests. I came out of those days a bit tired by all the things I had learned and tested, and a long list of new functions and tools to try, new ideas to explore etc, it was immensely fun, thank Sebastien! The conference itself was rather overwhelming, and a big surprise for me. I am used to large conferences like Vmworld or Tech-Ed where you get the good word for the year to come from an editor and its ecosystem. Most of the sessions in those are obviously diving into the products and how to use them. At Velocity, almost all the keynote speakers were somehow working in research, or such bleeding edge domain that it might not even exist yet. I loved being presented with what might be happening, and by people who are scientists at heart, not just marketing infused with a light touch of technology. Moreover the sessions themselves were mostly feedback on the speakers own experience on a specific domain/issue/subject. Usually they are not into a particular tool or software suite, but rather on how to make things work with DevOps and large distributed systems. Overall, I I really enjoyed this conference, because it very well organized, and small enough to be a human experience. As we have four days with the same group of around 400 people (227 to this day according to the attendee directory), in a rather small area, you cross path often with the same people, and it makes it easy to start conversations. Also they came up with a lot of ribbons that you can attach to your badge, to let other know what you are here for : [photo des ribbons] I was used to much larger conferences, where I always found the networking a bit difficult, if you did not know a few people beforehand. In Velocity’s case, it is so easy, you have only a handful of attendees and speakers, and you can meet everyone informally, during lunch breaks or just by asking. It came as a surprise for me to able just to chat with some of the speakers that have impressed me, like [juergen & Gremlin] just by going and sit with them at a lunch table.