I will assume that I am definitely not the first one to write about that, but I feel the need to write anyway. We saw during a few recent events that our new beloved always listening devices can interpret an ordre form almost anyone (Someone ordered a Whopper? Burger King: OK Google!) It seems trivial and a bit childish, but when you start integrating many services into a system like that, you may have to think about security. This goes at different levels : from limiting commands to voice-print recognition. ...

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

I am quite certain that there are many articles, posts and even books already written on that subject. To be honest, I did not search for any of those. For some reason, I had to figure out sharding almost by myself building a customer design. So this post will just be my way of walking through the process, and confirm that I can explain it again. If someone finds this useful, I will be happy :) Here is the information I started with. We want to build an application that uses a database. In our case, we chose DocumentDB, but the technology itself is irrelevant. The pain point was that we wanted to be able to expand the application worldwide, but also to keep a single data set for all the users, wherever they were living, connecting from. That meant finding a way of having a local copy of the data, writable, in every location we needed. Having a readable replica of a database is quite standard. You may even be able to get multiple replicas of this kind. Having a writable replica is not very standard, and certainly not a simple operation to setup. Having multiple writable replicas… let’s say that even with reading the official guide from Microsoft (https://docs.microsoft.com/fr-fr/azure/cosmos-db/multi-region-writers) it took us a while to fully understand. As I said, we chose to use DocumentDB, which already provides the creation a readable replica with a few clicks. This is not enough, as we need to have a locally writable database. But we also need to be able to read data that is written from the other locations. What we can start with is to create a multiple ways replica set. We could have a writable database in our three locations, with a readable copy in each of the other two regions : Dessin ...

It has almost been a year since my first Worldwide Partner Convention organized by Microsoft in Toronto. At the time, I wanted to share some insights, and some tips to survive the week. Before WPC, I attended multiple Tech-Ed Europe and VMworld Europe, in several locations over the years. WPC is slightly different as it is a partner-dedicated event, without any customers or end users. It gives a very different tone to the sessions and discussions, as well as a very good opportunity to meet with Microsoft Execs. As it was my first time, I signed up for the FTA (First Time Attendee) program, which gave me access to a mentor (someone who had already attended at least once) and a few dedicated sessions to help us get the most out of the conference. The buildup weeks In the months preceding the event, Microsoft will be pushing to get you registered. They are quite right to do so, for two reasons. First the registration fee is significantly lower when you register early. So if you are certain to attend, save yourself a few hundred dollars and register as soon as you can. Note that you may even register during the event for the next one. Second, the hotels fill up very quickly, and if you want to be in a decent area, or even in the same place as your country delegation, be quick! A few weeks before the event, I had a phone call with my mentor, who gave me some advice and opinion, as well as pointers on how to survive the packed 5 days. This helped me focus on the meetings with potential partners, and meetings with microsoftees, rather than on the sessions themselves. More on that subject later. During that period, you are also given the opportunity to complete your online WPC profile, which may help get in touch with other partners, and organize some meetings ahead of time. You also get the sessions schedule, which let you organize your coming days, and see what the focus is. I had the surprise, a few days before the event, to learn that we had “graduated” in the Microsoft partner program, from remotely managed to fully managed. So we had a new PSE (Microsoft representative handling us as a partner) which was very helpful and set up a lot of meetings with everyone we needed to meet from Microsoft France. This helped, for a first-timer, to be guided by someone who knew the drill. I was very excited to get there, and a bit anxious as we were scheduled to meet a lot of people, in addition to my original agenda with many sessions planned. ...

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

Today is another rant day, or, to put it politely a clarification that needs to be made. As you probably know by now, I’m an infra/Ops guy. So monitoring has always been our core interest and tooling. There are many tools out there, some dating back to pre-cloud era, some brand new and cloud oriented, some focused on the application, some on the infrastructure. And with some tuning, you can always find the right one for you. But beware of a fundamental misunderstanding, that is very common : monitoring is not alerting, and vice-versa. Let me explain a bit. Monitoring is the action of gathering some information about the value of a probe. This probe can measure anything, from CPU load to an application return code. Monitoring will then store this data and give you the ability to graph/query/display/export that. Alerting is one of the possible actions taken when a probe reaches a defined value. The alert can be an email sent to your Ops team when a certain CPU reaches 80%, or it could be a notification on your IPhone when your spouse get within 50m of your home. Of course, most tools have both abilities, but that does not mean that you need to mix them and setup alerting for any probe that you have setup. ...

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

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.

In the wake of the recent MongoDB happy hour debacle, there have been a few mentions of DevOps and NoOps. The pieces were mostly about the fact that this incident proved that the IT business is not really in full DevOps mode, not to mention NoOps. I am not confident that NoOps will be the future for a vast majority of shops. Being from the Ops side of things, I am obviously biased toward anyone stating that NoOps is the future. Because that would mean no job left for me and my comrades in arms. But let me explain :) I would like to be a bit more thorough than usual and explain what I see there, in terms of practices and trends. Definitions First let me set the stage and define what I mean by DevOps, and NoOps. https://en.wikipedia.org/wiki/DevOps http://www.realgenekim.me/devops-cookbook/ At its most simple definition, DevOps means that Dev teams and Ops team have to cooperate daily to ensure that they both get what they are responsible for : functionalities for Dev, and stability for Ops. A quick reminder though : business is the main driver, above all. This implies that both teams have to work together and define processes and tooling that enables fast and controlled deployment, accurate testing and monitoring. We could go deeper into DevOps, but that is not the point here. Of course, Ops team should learn a thing or two from Scrum or any agile methodology. On the other hand, Dev teams should at least grasp the bare minimum of ITIL or ITSM. What I could imagine in NoOps would be the next steps of DevOps, where the dev team is able to design, deploy and run the application, without the need of an Ops team. I do not feel that realistic for now, but I’ll come back to this point later. How are DevOps, and the cloud, influencing our processes and organizations I have worked in several managed services contexts and environments in my few years of experience, where sometimes Dev and Ops were very close, sometimes completely walled of. The main driver for DevOps, usually linked to cloud technologies adoption, on the Ops side, is automation. Nothing new here, you’ve read about it already. But there are several kinds of automation, and the main ones are automated deployment and automated incident recovery. The second kind has a deep impact, in the long term, on how I’ve seen IT support organization and their processes evolve. Most of the time, when you ask your support desk to handle an incident, they have to follow a written procedure, step by step. The logical progress is to automate these steps, either by scripting them, or using any IT automation tool (Rundeck, Azure Automation, Powershell etc.). You may want to keep the decision to apply the procedure human-based, but it’s not always the case. Many incidents may be resolved automatically by applying directly a correctly written script. If you associate that to the expanding use of PaaS services, which removes most of the monitoring and management tasks, you will get a new trend that has already be partly identified in a study : https://azure.microsoft.com/en-us/resources/total-economic-impact-of-microsoft-azure-paas/ ...

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