The State of DevOps in Windows Land
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Tørresdal, Jon Arild
How are Windows doing with regards to DevOps and automation specifically? How is the tooling space compared to other platforms? Are there changes in the horizon that will make living in Windows Land more attractive and less challenging? What is the community like? What is the culture like? What and how are typical Windows Ops companies and departments thinking? Jon Arild Tørresdal will try to answer these and other questions based on his experience working with operations, DevOps and Lean for a a number of companies. Not only focusing on automation of their deployment processes and Windows infrastructure, but also organizational changes needed to successfully accomplish their efficiency goals.
 All right. Welcome. I'm going to talk about a state of dev-ups in Windows Land. How many here consider themselves as Windows practitioners or on the Windows platform? So most of you, actually, I should have asked the complete opposite question, so I'm doing that. Who's not on the Windows platform, on a daily basis, the server platform? So most of you are in Windows. That's good. And you're apparently curious about the state of dev-ups. All right. My name is Johan Adel Telestal. I work for Miles in Bergen on the West Coast of Norway. And I'm more or less work professionally on the Windows platform or Windows Server since 2000. More or less work with dev-ups long before the term was coined. But more importantly, I worked six years for Frende Forsikring, a Norwegian insurance company. And there I spent most of my time actually getting the dev-ups' practices into place. So it all started like the normal CI story, continuous integration, and then just moved on and moved on and moved on. Today, they're fully automated. Their deployment, their infrastructure, everything is automated. And they're on the Windows platform for everything. And that has some very big challenges, I would admit, which resulted in me creating an open source project called Condep back in 2011. That project is still around. It's what we call a infrastructure as code thing. So if you know like Chef and Puppet or Ansible, things like that, it's more or less the same thing, except it's on the Windows platform and only for Windows. And it does not have even close to any of the same traction as you see the other tools have. So what are we going to talk today about today? Well, culture. So what's the culture like in these type of Windows-based companies, so to speak? What's the community like? What tools do we have around infrastructure as code? So the tools for automating everything Windows. What about PowerShell? How's the story around PowerShell? That is basically the tool you need to rely on for automation and Windows servers in general. So this talk is about DevOps or WebOps. It's not about operations, right? So it's specifically targeted to that. It's about servers and server applications. So it's not about client operating system or anything like that, right? It's about hosting your applications on a Windows server, typically for the web. And I'm drawing this distinction because when I talk to people, often they say, well, Microsoft are doing great stuff within DevOps for the client platform. And that's actually right. I mean, they're doing impressive stuff of maintaining tens of thousands of clients and companies for their client platform, right? But those things that they do there does not apply very well in the DevOps world. It's different. So, and of course, it's based on my experience working with these things in the DevOps world for Windows servers. All right. So what's DevOps to me? So the classical thing in the right corner here is the wall of confusion, right? That's a classical picture you will see from DevOps that the dev have to hand off to DevOps and throw these things over the wall. And you need to break down the wall. That's kind of the classic thing. Well, to me, DevOps to me is developers and operations collectively taking responsibility for applications during all phases, including production, right? But I also think that or operations trusting developer or developers to take the entire responsibility for the application or their applications, including production. So I think you can go both ways, right? So I've actually had pretty good experience with the last one. And typically in companies where operations are outsourced, it's really hard to have this tight relationship and tight correlation between operations and your own company. And then it makes more sense to try and educate developers to have the necessary knowledge to actually have their or maintain their application and publish their applications themselves into production during the entire pipeline. But no matter which thing you choose, you still need to fully automate and monitor deployment and infrastructure for your environments. And in both cases, a shared understanding and trust between dev and ops is required, right? So if operations doesn't trust the developers to actually do this, or they've shown that they're not competent in doing it, well, then you have a problem. It's all trust related. So culture. The gap between dev and ops in most organizations result in a major bottleneck bringing with its significant hidden cost way outside of IT. Does anybody know who said that? I did just now. I couldn't find a good quote to express what I was thinking, so I created one. And feel free to use it as much as you want. But really, this is one of the key things within DevOps because we as developers or operations people have a really hard time explaining to the business why DevOps is a good thing, right? And one of the reasons for this is the hidden part, right? This is a hidden cost. It's really hard to see it. And there's a historical aspect here as well. It's always been like that, right? We've always had operations. We always have development, and we always handed off from the one to the other. But in most businesses today, at least, well, in business leaders, in most businesses has a relation to lean in some way or another. And trying to take that path and explain the lean aspects of this might help you in explaining to the business why this is a huge problem. So I think that in this is not specific to corporations that rely on Windows servers. I think this is general, that they basically just don't know that the DevOps initiative is there or what it is. They might have heard about it, but they don't know what it is or what it stands for and which benefits it brings. And most importantly, they're unaware of the economical benefits of actually implementing DevOps and efficiency, potentially rapid feedback that they get. So we see that most businesses around the world now which wasn't reliant on IT before are all getting reliant on IT now. So very many of the businesses that we see becomes an IT business. And if they don't, they often run out of business because software is running the world today. So everybody should have an understanding of what DevOps means. So how about on the operations side? Well, in the Windows world, there's a tooling suite that are very, very UI centric. There's, and it typically, in my opinion, too dependent or reliant on scum-like tooling, so system-centered operation manager type of systems. So they're very specific to maintaining what I mentioned earlier, which is the client platform. They're really good at that. But for the server platform and for doing DevOps, not so much. So you're looking for a different type of tooling and a different type of mindset in this world. The lacking automation, and there's no scripting culture, I say no scripting culture. Of course, you find exceptions, but you see less scripting here in this environment. And PowerShell, which is the language or shell you have to use in these scenarios on Windows, is very slow or low, or both. So what I typically hear when I talk to ops people is that they kind of have a bad conscience because they haven't learned PowerShell yet. They all say, well, I really need to learn PowerShell, but I haven't. And yeah, and a few excuses. And I'll get back to that later on when I talk about PowerShell, why I think that is. But more importantly, in the Windows world, and it's not unique to Windows, but I'll talk about Windows here, is that they still treat servers as pets versus cattle. But I mean, if you heard these lead architect for Windows Server, Jeffrey Snowber, I think he's called, he talked about this at Build 2015. So with pets, right? You take care of them, you feed them, and you cozy with them, and yeah, you're nice to them, right? Well, the world have changed. You don't do that to servers anymore. You spend a lot of time optimizing disk with removing files and running Windows updates to make it fully patched and all these things. You don't spend a lot of time on that. You treat them as cattle. So if something goes wrong on a server, you fire up the barbecue, so to speak, right? In a cattle sense. So the thing is, you automate everything, right? So that if a server behaves in a way that it shouldn't, you kill it and then create a new one. It's a commodity, right? You just, yeah. So and I think in the Windows world, there's still this thing that, oh, we should take care of our servers and we still maintain them in the kind of old-fashioned way. So what's the culture on the development side? Well, they're really inspired by the cloud. So they've seen what we can do in the cloud, how fast you can get a server, the APIs they offer to interact with the server, and do all these kinds of things, right? But in a corporate world, where they expect the same thing, they have a tendency to lack ops know-how or interest. So many devs know too little about ops in order to do these things effectively and securely. And it's still a case of not my problem, because I'm supposed to throw this thing over the wall anyway. That is the thing that is in the company I work, they say. And Optin's in clear, back in the 30s, it is difficult to get a man to understand something when his salary depends on he's not understanding it. So if you pay to be an ops person, you do ops stuff. If you pay to be a developer, you do dev stuff, right? You're not paid to actually do something in between. So it takes something extra to actually do that. Payment is not the initiative. Something to think about. And also, is there anybody from academia here? From universities or, right? So specifically I was thinking about tutoring in academia. I think that it's got to start there, right? I've talked to universities and stuff over the years and I always emphasize that you got to stop making this huge separation between dev and ops, right? Because devs needs ops knowledge and ops needs programming knowledge. You can't draw a distinct line between the two. And when I say ops knowledge, I'm not talking about devs knowing intricate details of networking or operations knowing or being fluent in.NET or something like that. You have to know that the tools that is relevant for working with DevOps, right? And if there is somebody from academia here, come talk to me afterwards, I have tons of input on what that could be. And then we have the tooling suite. So we talked about this as infrastructure code or IAC. And modestly enough, I put condop on top here. And I'm not saying that, well, don't take my word for it, right? And jump ahead and do condops right away because that's the best tool he said so. You need to evaluate these things yourself. But I've used every one of these tools in real life except from puppet, which I haven't used that much. And for the last one, which is PowerShell Desire State Configuration, which I'll talk a bit about later on. So this is kind of an evolution here. So puppet was one of the first tools out. And then Chef came along, which was after puppet. And the Chef people had experienced from puppet and they wanted to do things a bit differently. So looking outside in, the major difference between puppet and Chef is puppet is an internal DSL, sorry, puppet is an external DSL, and Chef is an internal DSL. And there are, of course, other differences. But they're both pull-based, mostly. So you install some software on each and every server. And they find out when something new happened and they pull that down and they run it on the server. As for Ansible, that is mostly a push model. So you put Ansible on a central server, which can communicate with all your other servers and they push out stuff, right? So the benefit by the push model is it a lot simpler and it's easier to understand and work with. But depending on the network topology that you have in your company or that you're working with, you might not be able to use either one of these two, right? So if you don't have a central place in your network where you actually get access to all the servers, you can't do the push model. You need to reverse it and do a pull model instead, right? And the same thing with Condep is that's a push model too. And I took experience specifically for Chef and Puppet when I created that one and kind of discovered Ansible a bit later. And it was interesting to see how many similarities there were between the two. Again, I've created that too, so don't take my word for it. But I think there's a lot of similarities. And I think it also is because we both or those both projects took inspiration from the same tools and tried to make the same improvements, so to speak. So let's take Chef is how many here are using a tool called Chef for Windows or Puppet for Windows or any other infrastructure automation tool that is here or Condep. Okay, there's a few using Condep. Good. So the thing about Chef and Puppet, where do they come from? Where do the tools originate? Anybody know? In the Linux role, right? That's where it all started. And they've added support for Windows later on. And I've used especially Chef in production on systems. And when something had gone wrong, I've experienced what happened in those cases. So let's say a bug was introduced and you're in the Linux world and running Chef stuff, things are happening really fast. Things are getting fixed really fast because the community around Chef is huge. If you're in the Windows world, the community around Chef and Windows is tiny and it takes forever for things to happen. So you're more or less on your own, right? And also since Windows is not the primarily focus for Chef, even though they know how all these cooperation with Microsoft and all that and it's probably got better since when I were using it, Windows in my mind will always be an afterthought in these tools. It will not have the highest priority. And then we have deployment tools. And the thing is that when I talk to people about DevOps, we start out talking about DevOps and maybe some cultural thing, but soon enough we're talking about deployment. Because deployment is the thing that, well, it's the obvious thing to start with, right? But in my mind, deployment in this area, even on Windows, is a solved problem. I mean, there are tons of tools that you can use or there are enough tools that you can use that the technology is no longer an excuse, right? But usually it's all the other issues that comes in your way as a developer that you don't get access to production or operations team don't believe that this is a good idea and things like that. But Condep has a deployment model. Octopus is a pretty common tool in the Windows.net world to deploy stuff. And that's a great tool. It has more than just deployment. It has the deployment workflow or the pipeline, which is good. Condep does currently not have that. So if you're just looking for deployment, I would really recommend Octopus because that's a really kickstarter for this process. But thinking DevOps, don't stop after deployment. That's just the first step, right? You need to automate all these other things, too. You need to automate the entire configurations for your servers. And where I come from, where I used to work at Frenda, they've done all this automation for the servers. And it now makes sense to start thinking about what about firewalls? What about routers? What about all these other things? It should be code. It should be version controlled, right? Don't stop with the servers. Just keep it going and automate things. It makes things so much easier to maintain over time. And I mentioned web deploy here mostly because there are still people using it. I wouldn't recommend going in that direction when you have these other tools. So question so far? What about the DevOps community on Windows? Well I would argue it's very small, almost invisible. Almost doesn't exist. Does anyone disagree or is that what you feel too? That's definitely where I am. I'm in the middle of that community and I'm pretty much alone, to be honest. I also think it's very coupled to Microsoft. I think that this community, whatever it is, kind of rely on Microsoft and I used to relying on Microsoft to provide a tooling to solve these problems, so to speak. I would not wait around for Microsoft to solve this problem. I think that the solutions to this problem is already out there. It's about combining the tools for doing the job. And honestly, I think Microsoft had us a bad track record in solving these problems. That's just my honest opinion. And also, as I mentioned earlier, there's a limited community around these IAC tools. Although typically, like Chef and Puppet and the other ones, actually I think Puppet is probably more mature in this area than any other one. But there's a limited community around that. So as I said, if you run into a problem or there are a bug in our error or something like that, it's really hard to get fixed. And just think about it. How many talks do you find at DevOps conferences that talk about Windows? I almost don't know about any. It's not a common subject at all. Are we getting some bit depressed now? Is that just like, OK, I'm going to bring it up soon. So PowerShell, that's the shell for Windows. The Dush shell is too limited. You don't even think about it. You need to go, but at PowerShell, wait. So this is a really slow user adoption and honestly, really bad reputation. Developers love talking down on PowerShell. It's like, oh, you're doing PowerShell. Oh, that's a really bad language. Oh, they love that. And as I was saying earlier, ops people tend to have a bad conscience for not having thought themselves or learned PowerShell yet. But the reason I think, or one of the reasons for that is I think that Microsoft has mostly focused on PowerShell as a language and not so much as a shell. And ops people are not set out to learn languages the same way as developers are. So I think that there's a slow adoption curve there because just a general focus that Microsoft has on it as a language. And it just honestly does not give you the obvious core Windows functionality you would expect from a shell. It's not done at all as for a shell. And to just illustrate this. So if you're familiar with a Linux world or you have a Mac or whatever, you know Schmod. So Schmod is for changing in access right on your file or directory, something like that. How do you do Schmod in PowerShell? Does anybody know? So how do you do it? Set ACL. All right. Okay, so let's try that. So I'm just going to, because I don't know, so I'm going to say get help set. Let's make this bigger, shall we? Well, actually, I'm going to zoom in for you. So it says, can we read this? Is that right? What is the security descriptor of a specific item, such as a file or a registry key? Oh, so you've got to be right. So let's see what it takes as parameters. Needs a path, okay, a path for a file, that's good. And then needs an ACL object. Okay, what's an ACL object? Where do you get that from? How do you do that? Well, that's a.NET object. It's a security descriptor object in.NET. We need to create this security descriptor. But hang on, let's, they probably have some examples for this. So let's do get help set ACL example. Oh, here's one. Oh, you create a new ACL object. Cool. How do you do that? Get ACL file? What's that? Okay, so you copy the ACLs from an existing file. Is that how you define your security descriptor? Okay. So I have to manually create a file, set the permissions that I want the file to have, and then say, get ACL on it in order to get those permissions so I can give those permissions to another file. That makes no freaking sense, right? So they've created get ACL and set ACL, and they ignored everything in between. So that doesn't make any sense to me. This should be really, really simple. This is a core OS thing to do. I want to change the access rights on a file, right? So, but you can do it though. You can, of course, create this ACL object. Like this. So first you get the ACL for the object that you are going to manipulate, and then you new up a new system security access control file system access rule, which is the ACL object, and then you tell it which user, what type of control you need, and seriously, some pretty cryptic type of old, calm stuff that they've forwarded into.NET. So it's really not.NET. It's calm. It's a PI invoke simplified for those who are familiar with the.NET world. And then you set the access rule, and then at the end use the set ACL. So yes, you're right, but it's really hard, isn't it? Shouldn't be like this. And so I tweeted this a few days ago, and somebody said, well, there's a module for this. Yes, there is. So somebody in the community actually took the time and make this right, right? So they create a module for it. So you need to download that and install it and use that instead, and it's all good. But I mean, it's a core operating system thing, right? You should expect the shell to do this. And there are many, many examples of the same thing in the PowerShell shell. So I think if Microsoft should do something, they should focus more on their shell and less on PowerShell as a language. And by the way, here's the tool I was talking about. Not that. Anyway, it's a data URL. There it is. Fast system security PowerShell module. So if you need ACL stuff, use that. And recently in PowerShell 4, which is the current version of PowerShell we have today, they introduced PowerShell desired state configuration or DSC. Does anybody know what DSC is? Few people, right? So for me, this looks like Microsoft's attempt to do the DevOps type of thing or probably a bad wording to use in this context. So the same thing as the Chef and Puppet and the other tools are doing is that they define the state of what they want or the state that they want to have on a server, for instance. So this tool is set out to do exactly that. And this is an example of how it looks. So I can take this file or this text. I can just copy it into PowerShell. There's somebody just going to create a new shell so I don't have any existing. Oops. Like this. So now I have a local function inside which is called file resource demo. So if I do like file resource, right? PowerShell detects that. So if you look back here, what you need to do is just call that. Okay. So I'm just going to call that. Next I'm just going to CD out into temp. And you see. And I'm going to call that. And something happened and outputted a local host MOF file. So it's kind of a compilation. And it creates a file for you so you can use to run. And the way you run is you say start DSC configuration, you point to the directory, which I'm just going to show you now. So bad directory to choose. CD and they see something. Anyway I forgot to go into that. Create a folder called file resource demo. So if I'm going to run that. I'm just saying start configuration pointing to that folder containing that file and will execute whatever that said it should do. So what did it say? So it uses configuration. That's just the main header of your DSC. And then there's node and pointing to a server. So that can be a, so I have hard coded that now to local host so that can just be a variable. So you can replace that with whatever you want and pass that into this file. And then I say file and I call this operation directory copy. And I say ensure present, type directory, recursive true and then a point to a source path on my client. So in this case that's temp2. And then I say the destination path on whatever server I'm going to run this towards is temp2 underscore and is COSLOW. So let's just see. So there's already a temp and is COSLOW here because I forgot to delete earlier. So I'm just going to delete that. So basically it's going to take this temp2 folder and copied it since this local host I don't have a remote server to show it on. But it could be a remote server and does the exact same thing. Take some time. But what it actually figures out is, so it doesn't just do file copy, right? It actually checks the state on a client versus the server you're pointing to or the servers you're pointing to. So it synchronizes the files. That's a distinction you need to make. So if somebody has deleted a file on the server in this directory and you run this thing, it would actually make sure the file gets back. But more importantly, if you delete a file on a client and synchronize it, it will make sure that it's copied over, right? So it synchronizes the thing. It doesn't just copy it. So this is all good. DSC, I kind of like. But I kind of have a hard time understanding what Microsoft is trying to do, right? Because there are very few resources available that has this DSC thing. And yeah, of course, it's not important, which was what I just explained. Basically, it makes sure that the state is correct. And you can run them as many times as you want. And it still makes sure that the state is correct. So Microsoft really needs to do a way better job in order to provide the tooling around this space than they already have. But let's look at PowerShell 5. So that's the new PowerShell coming in Windows 10, right? So let's see what they've done with regards to DevOps. Well not only regards to DevOps, but mostly in general. We can now copy files from one server to another. They took them so long, right? I'm serious. OK, you could copy files earlier, but you were reliant on Windows networking and all kinds of ports being opened. And you couldn't just use that. You need to rely on these things working over HTTP. That's where stuff happens nowadays. So yes, in Windows 10, we can actually copy a file from a client to a server. Yes, that's progress. They've added support for PowerShell Get, which is a gallery you can upload or download modules from. Yes, that's good. They're starting now to create some tooling around actually getting components easy and don't have to like browse the internet, download the thing, extract the interfolder in a specific place, know if a PowerShell defined it and so forth, right? It's really easy. Just point this command line tool to a certain place and you get the module. Good. They've added some object-oriented language improvements. Actually class an enum. I never saw that coming, honestly. That is, I'm not missed that at all. That is not what I wanted for PowerShell going forward. I think PowerShell, as it is today, works. And okay, class an enum, maybe, but that was not on top of my list. They now have support for zip files and symbolic links. Yes, finally. Again, I mean, the community have done this a long time ago, right? They provided support for this. But now it's in the core PowerShell, which is good. The package management module, and actually I'm going to talk a bit about that later on. So I'm going to skip that. And there's a few other things. So we can versioning a module in a single folder. So just as you know, run as credentials is now supported in DSC. This is also a thing that you would have expected from to begin with, but it's good that it's there now. You can now define the pencies across computers in DSC. It is also, that's good. But there's no ACL or SMART support, though. I mean, come on. You need to provide the basic stuff before you do all these advanced stuff, right? You need to make it a shell first, and then you can start organizing the other things. And I think that all PowerShell modules and DSC modules should be open source, because the community would take this responsibility immediately and just fix that problem and create those resources that are missing in PowerShell. And according to the community in PowerShell, this is apparently going on right now. It takes time because of legal, la, la, la, same thing. But let's hope that happens. I think this is a key part of actually PowerShell getting to the level that we would expect from any shell, no matter platform. So and then we have the operation, operating system package manager. So does anyone use a package manager for Windows today? And I'm not talking about Windows installer and like that. So again, use a command line tool and go online and get a package or install some software, right? So maybe 10 people. And it's probably this one. Is that correct? Chocolate tea, right? All right. And it's really good that this tool finally arrived. But it was started, it was done in the community. Microsoft now have seen this and of course we need to have this. So just for those of you who don't know, chocolate tea is basically up, get a brew from, as it is from Mac, for Windows, right? So you can just use this, you say Choco install and then point to, let's say, Adam or Sublime or some application you want to have installed and just downloads it, installs it and you're all good. Really, really easy. You don't have to open your browser, find Google for some tool, find it, download it, unzip it, run MSI, which is included in that zip and click next, next, next, finish. You don't have to do that anymore. And just, yeah, it's the proper way. So if you don't do chocolate tea today, start using it now. So what happens tomorrow? So when PowerShell 5 comes along and Windows 10, well, one get is added, which is basically, which is integrated to PowerShell 5. And what one get is, it's not a package manager per se, but it's an interface which package managers can integrate with. So that using one get and in PowerShell, you can get stuff from through chocolate tea, so to speak. So it gives you this new system of applications that you can download. So that's good. So how about a server operating system? I don't think anyone would argue against me on this. It's hard to automate and configure. Does anyone think differently? I think we're all agreeing on this. It's auto-automate, automate installation of applications. So how are typical applications on Windows distributed? Well as MSI's or XC's and sometimes ZIP's or stuff like that, but the most professional applications are usually packaged as an MSI or XC. So you can automate an MSI. You can use MSI exec and install an MSI given that the author of the package actually took into consideration that it should be fully automated and provided the necessary parameters for doing that. Most of my time trying to install this application, I have to reverse engineer this MSI in order to figure out which parameters to send in to automate the entire thing. And this is not just we or whoever who's creating these packages, it's Microsoft too. They're doing the same thing. So the worst thing is if you provide an XC and you don't allow any parameters at all, you have to do the next, next, next finish thing and that doesn't really work in automation. Fortunately, it seems like everyone is realizing this now and moving away from it based on the chocolate takeaway and other things. So that's good. So just mentioning MSI's, MSU's, web deploy and stuff is the typical way today. But the operating system is still very UI centric. There are still things that you just can't do automatically. You have to use the UI. And frankly, I mean, that is Windows. That is what it started out as doing. So this is the legacy that we brought with us until today. But now the world has really, really changed and it's not going to work anymore. This needs to change. So what happens tomorrow? So we're talking Windows Server 2016. So Jeffrey Snowber, which I referenced earlier, said this. Admin GUIs on servers are poison. They're like heroin. You know, first shot of heroin probably feels pretty good. But you do it a bunch. You like goes to heck and you do it too much. You're dead. Pretty bold statement coming from somebody who's responsible for Windows Server. So it's changing and that's good, right? I like that. I like the new direction that Microsoft is going. It's the right direction. I think everybody agrees on that. But so the big thing now is Windows Nano, right? That is the operating system or the stripped down operating system that Microsoft had to create in order to support containers. And I'm going to do big talk on containerization or anything like that. But if you don't know what container is, you will. I mean, this is huge. Everybody's going to do some type of containerization going forward. There's no doubt about it. So Windows Nano is the Windows version you're going to use for this. So and there is no UI. You open, you run Windows Nano and there's nothing there. You have to automate it remotely, right? So the key thing is they're working away from this rich UI and they're communicating the message clearly, right? But this scares the shit out of the ops world in Windows. I'm serious because you just can't say that. Well, tomorrow we're removing all the UIs and they have a big investment and reliant on all these UI tools, right? So of course they're going to continue to support the UIs. But the major difference is that they're now moving the UI tools to the client remotely communicating with the server and, well, actually optionally you can have them installed it on the server as well. So and that is one of the things that Microsoft is good at is being backward compatible. So I would expect this story to continue. And they're working on a new Windows installer. And I don't know how many efforts has been done around working with installer mechanisms. But the thing is that the existing MSI-XSEC or MSI installer doesn't work good enough in this world. So apparently they're looking at creating a new one. And I think that's probably good too if they get it right. Any questions so far? Comments? All right. So what about the.NET story? I would argue the only reason to run Windows Server today is because of.NET. Is there anybody in this room that runs Windows Server for something else than.NET? No one. One person. Update services. Update services. Right. But if we're thinking DevOps and WebOps, it's, yeah. Right. If you, so if you're following along what have happened in the announcements lately for Microsoft, we're talking about this new thing called the Core CLR, which has no UI stuff and all that and still shrift down. So if you want to have your application run on Windows Nano, you have to rewrite your application in order to get down to the Core CLR. If you do that, you can run it on Nano, but you can run it on any other OS supporting the Core CLR like Linux, Mac, FreeBSD. Right. So my open question is, so why would you choose to run on Windows? I'm not going to answer it. I don't have an answer for it, but I'll leave that open to you. But I think Microsoft needs to do something in this space in order to provide the added benefit of running Windows. Or else I can't see why we should use it. So bottom line, I would expect more from Microsoft. PowerShell is still too limited and needs its shell. I mean, the shell is not a shell yet. They need to improve that a lot. PowerShell needs to get its modules into open source. And the future value for server OS is unclear in the DevOps world. Remember, everything I've said today is in relation to DevOps, right? I'm not talking about all the other DevOps. And to me, it's very unclear. When they're opening up.NET that way and I say that, well, that's the only reason I have for running on a Windows server, then, yeah, it's unclear to me what Microsoft is thinking. But no matter what, Microsoft needs a vibrant DevOps community for Windows in order to have this being a success. And they need to start helping to organize that community. And sadly enough, I would expect UI tools coming from Microsoft supporting DevOps. I hope not, because that is not the way to go about this. But there are some things that point in that direction. Yeah, I do not want to have a UI tool for doing these things. And remember, Admin GUIs on servers are poison. Thanks. Questions? Yeah? Anything else other than PowerShell that you can probably use to automate stuff on Windows? So the question is, is there anything else other than PowerShell you can use to automate on Windows? Yes. So the other ISE toolings I mentioned does not necessarily expose PowerShell to you, but they rely on PowerShell in order to get stuff done, right? So you can use any of those tools and you don't necessarily touch PowerShell and you still accomplish what you want to do. And yes, you can also use other shells, but I don't think it's the way to go for the future. It's PowerShell, which is Windows shell, and that is where your investment should be, I think, going forward. So the answer to the question is probably no. Any other question? All right. We're getting close to lunch and you wanted the lucky ones that gets to get first in the line, apparently. So thank you.
 All right. Welcome.  I'm going to talk about a state of dev-ups in Windows Land.  How many here consider themselves as  Windows practitioners or on the Windows platform?  So most of you, actually,  I should have asked the complete opposite question,  so I'm doing that.  Who's not on the Windows platform,  on a daily basis, the server platform?  So most of you are in Windows.  That's good. And you're apparently curious about the state of dev-ups.  All right. My name is Johan Adel Telestal.  I work for Miles in Bergen on the West Coast of Norway.  And I'm more or less work professionally on the Windows platform or Windows Server since 2000.  More or less work with dev-ups long before the term was coined.  But more importantly, I worked six years for Frende Forsikring,  a Norwegian insurance company.  And there I spent most of my time actually  getting the dev-ups' practices into place.  So it all started like the normal CI story, continuous integration,  and then just moved on and moved on and moved on.  Today, they're fully automated.  Their deployment, their infrastructure, everything is automated.  And they're on the Windows platform for everything.  And that has some very big challenges, I would admit,  which resulted in me creating an open source project called Condep back in 2011.  That project is still around.  It's what we call a infrastructure as code thing.  So if you know like Chef and Puppet or Ansible, things like that,  it's more or less the same thing, except it's on the Windows platform and only for Windows.  And it does not have even close to any of the same traction as you see the other tools have.  So what are we going to talk today about today?  Well, culture.  So what's the culture like in these type of Windows-based companies, so to speak?  What's the community like?  What tools do we have around infrastructure as code?  So the tools for automating everything Windows.  What about PowerShell?  How's the story around PowerShell?  That is basically the tool you need to rely on for automation  and Windows servers in general.  So this talk is about DevOps or WebOps.  It's not about operations, right?  So it's specifically targeted to that.  It's about servers and server applications.  So it's not about client operating system or anything like that, right?  It's about hosting your applications on a Windows server, typically for the web.  And I'm drawing this distinction because when I talk to people, often they say,  well, Microsoft are doing great stuff within DevOps for the client platform.  And that's actually right.  I mean, they're doing impressive stuff of maintaining tens of thousands of clients  and companies for their client platform, right?  But those things that they do there does not apply very well in the DevOps world.  It's different.  So, and of course, it's based on my experience working with these things  in the DevOps world for Windows servers.  All right.  So what's DevOps to me?  So the classical thing in the right corner here is the wall of confusion, right?  That's a classical picture you will see from DevOps that the dev have to hand off to DevOps  and throw these things over the wall.  And you need to break down the wall.  That's kind of the classic thing.  Well, to me, DevOps to me is developers and operations collectively taking responsibility  for applications during all phases, including production, right?  But I also think that or operations trusting developer or developers to take the entire  responsibility for the application or their applications, including production.  So I think you can go both ways, right?  So I've actually had pretty good experience with the last one.  And typically in companies where operations are outsourced, it's really hard to have this  tight relationship and tight correlation between operations and your own company.  And then it makes more sense to try and educate developers to have the necessary knowledge  to actually have their or maintain their application and publish their applications themselves  into production during the entire pipeline.  But no matter which thing you choose, you still need to fully automate and monitor deployment  and infrastructure for your environments.  And in both cases, a shared understanding and trust between dev and ops is required,  right?  So if operations doesn't trust the developers to actually do this, or they've shown that  they're not competent in doing it, well, then you have a problem.  It's all trust related.  So culture.  The gap between dev and ops in most organizations result in a major bottleneck bringing with  its significant hidden cost way outside of IT.  Does anybody know who said that?  I did just now.  I couldn't find a good quote to express what I was thinking, so I created one.  And feel free to use it as much as you want.  But really, this is one of the key things within DevOps because we as developers or operations  people have a really hard time explaining to the business why DevOps is a good thing,  right?  And one of the reasons for this is the hidden part, right?  This is a hidden cost.  It's really hard to see it.  And there's a historical aspect here as well.  It's always been like that, right?  We've always had operations.  We always have development, and we always handed off from the one to the other.  But in most businesses today, at least, well, in business leaders, in most businesses has  a relation to lean in some way or another.  And trying to take that path and explain the lean aspects of this might help you in explaining  to the business why this is a huge problem.  So I think that in this is not specific to corporations that rely on Windows servers.  I think this is general, that they basically just don't know that the DevOps initiative  is there or what it is.  They might have heard about it, but they don't know what it is or what it stands for and  which benefits it brings.  And most importantly, they're unaware of the economical benefits of actually implementing  DevOps and efficiency, potentially rapid feedback that they get.  So we see that most businesses around the world now which wasn't reliant on IT before  are all getting reliant on IT now.  So very many of the businesses that we see becomes an IT business.  And if they don't, they often run out of business because software is running the world today.  So everybody should have an understanding of what DevOps means.  So how about on the operations side?  Well, in the Windows world, there's a tooling suite that are very, very UI centric.  There's, and it typically, in my opinion, too dependent or reliant on scum-like tooling,  so system-centered operation manager type of systems.  So they're very specific to maintaining what I mentioned earlier, which is the client platform.  They're really good at that.  But for the server platform and for doing DevOps, not so much.  So you're looking for a different type of tooling and a different type of mindset in this world.  The lacking automation, and there's no scripting culture, I say no scripting culture.  Of course, you find exceptions, but you see less scripting here in this environment.  And PowerShell, which is the language or shell you have to use in these scenarios on Windows,  is very slow or low, or both.  So what I typically hear when I talk to ops people is that they kind of have a bad conscience  because they haven't learned PowerShell yet.  They all say, well, I really need to learn PowerShell, but I haven't.  And yeah, and a few excuses.  And I'll get back to that later on when I talk about PowerShell, why I think that is.  But more importantly, in the Windows world, and it's not unique to Windows, but I'll  talk about Windows here, is that they still treat servers as pets versus cattle.  But I mean, if you heard these lead architect for Windows Server, Jeffrey Snowber, I think  he's called, he talked about this at Build 2015.  So with pets, right?  You take care of them, you feed them, and you cozy with them, and yeah, you're nice to them,  right?  Well, the world have changed.  You don't do that to servers anymore.  You spend a lot of time optimizing disk with removing files and running Windows updates  to make it fully patched and all these things.  You don't spend a lot of time on that.  You treat them as cattle.  So if something goes wrong on a server, you fire up the barbecue, so to speak, right?  In a cattle sense.  So the thing is, you automate everything, right?  So that if a server behaves in a way that it shouldn't, you kill it and then create  a new one.  It's a commodity, right?  You just, yeah.  So and I think in the Windows world, there's still this thing that, oh, we should take  care of our servers and we still maintain them in the kind of old-fashioned way.  So what's the culture on the development side?  Well, they're really inspired by the cloud.  So they've seen what we can do in the cloud, how fast you can get a server, the APIs they  offer to interact with the server, and do all these kinds of things, right?  But in a corporate world, where they expect the same thing, they have a tendency to lack  ops know-how or interest.  So many devs know too little about ops in order to do these things effectively and securely.  And it's still a case of not my problem, because I'm supposed to throw this thing over the  wall anyway.  That is the thing that is in the company I work, they say.  And Optin's in clear, back in the 30s, it is difficult to get a man to understand something  when his salary depends on he's not understanding it.  So if you pay to be an ops person, you do ops stuff.  If you pay to be a developer, you do dev stuff, right?  You're not paid to actually do something in between.  So it takes something extra to actually do that.  Payment is not the initiative.  Something to think about.  And also, is there anybody from academia here?  From universities or, right?  So specifically I was thinking about tutoring in academia.  I think that it's got to start there, right?  I've talked to universities and stuff over the years and I always emphasize that you  got to stop making this huge separation between dev and ops, right?  Because devs needs ops knowledge and ops needs programming knowledge.  You can't draw a distinct line between the two.  And when I say ops knowledge, I'm not talking about devs knowing intricate details of networking  or operations knowing or being fluent in.NET or something like that.  You have to know that the tools that is relevant for working with DevOps, right?  And if there is somebody from academia here, come talk to me afterwards, I have tons of  input on what that could be.  And then we have the tooling suite.  So we talked about this as infrastructure code or IAC.  And modestly enough, I put condop on top here.  And I'm not saying that, well, don't take my word for it, right?  And jump ahead and do condops right away because that's the best tool he said so.  You need to evaluate these things yourself.  But I've used every one of these tools in real life except from puppet, which I haven't  used that much.  And for the last one, which is PowerShell Desire State Configuration, which I'll talk  a bit about later on.  So this is kind of an evolution here.  So puppet was one of the first tools out.  And then Chef came along, which was after puppet.  And the Chef people had experienced from puppet and they wanted to do things a bit differently.  So looking outside in, the major difference between puppet and Chef is puppet is an internal  DSL, sorry, puppet is an external DSL, and Chef is an internal DSL.  And there are, of course, other differences.  But they're both pull-based, mostly.  So you install some software on each and every server.  And they find out when something new happened and they pull that down and they run it on  the server.  As for Ansible, that is mostly a push model.  So you put Ansible on a central server, which can communicate with all your other servers  and they push out stuff, right?  So the benefit by the push model is it a lot simpler and it's easier to understand and  work with.  But depending on the network topology that you have in your company or that you're working  with, you might not be able to use either one of these two, right?  So if you don't have a central place in your network where you actually get access to all  the servers, you can't do the push model.  You need to reverse it and do a pull model instead, right?  And the same thing with Condep is that's a push model too.  And I took experience specifically for Chef and Puppet when I created that one and kind  of discovered Ansible a bit later.  And it was interesting to see how many similarities there were between the two.  Again, I've created that too, so don't take my word for it.  But I think there's a lot of similarities.  And I think it also is because we both or those both projects took inspiration from the same  tools and tried to make the same improvements, so to speak.  So let's take Chef is how many here are using a tool called Chef for Windows or Puppet for  Windows or any other infrastructure automation tool that is here or Condep.  Okay, there's a few using Condep.  Good.  So the thing about Chef and Puppet, where do they come from?  Where do the tools originate?  Anybody know?  In the Linux role, right?  That's where it all started.  And they've added support for Windows later on.  And I've used especially Chef in production on systems.  And when something had gone wrong, I've experienced what happened in those cases.  So let's say a bug was introduced and you're in the Linux world and running Chef stuff,  things are happening really fast.  Things are getting fixed really fast because the community around Chef is huge.  If you're in the Windows world, the community around Chef and Windows is tiny and it takes  forever for things to happen.  So you're more or less on your own, right?  And also since Windows is not the primarily focus for Chef, even though they know how  all these cooperation with Microsoft and all that and it's probably got better since when  I were using it, Windows in my mind will always be an afterthought in these tools.  It will not have the highest priority.  And then we have deployment tools.  And the thing is that when I talk to people about DevOps, we start out talking about DevOps  and maybe some cultural thing, but soon enough we're talking about deployment.  Because deployment is the thing that, well, it's the obvious thing to start with, right?  But in my mind, deployment in this area, even on Windows, is a solved problem.  I mean, there are tons of tools that you can use or there are enough tools that you can  use that the technology is no longer an excuse, right?  But usually it's all the other issues that comes in your way as a developer that you  don't get access to production or operations team don't believe that this is a good idea  and things like that.  But Condep has a deployment model.  Octopus is a pretty common tool in the Windows.net world to deploy stuff.  And that's a great tool.  It has more than just deployment.  It has the deployment workflow or the pipeline, which is good.  Condep does currently not have that.  So if you're just looking for deployment, I would really recommend Octopus because that's  a really kickstarter for this process.  But thinking DevOps, don't stop after deployment.  That's just the first step, right?  You need to automate all these other things, too.  You need to automate the entire configurations for your servers.  And where I come from, where I used to work at Frenda, they've done all this automation  for the servers.  And it now makes sense to start thinking about what about firewalls?  What about routers?  What about all these other things?  It should be code.  It should be version controlled, right?  Don't stop with the servers.  Just keep it going and automate things.  It makes things so much easier to maintain over time.  And I mentioned web deploy here mostly because there are still people using it.  I wouldn't recommend going in that direction when you have these other tools.  So question so far?  What about the DevOps community on Windows?  Well I would argue it's very small, almost invisible.  Almost doesn't exist.  Does anyone disagree or is that what you feel too?  That's definitely where I am.  I'm in the middle of that community and I'm pretty much alone, to be honest.  I also think it's very coupled to Microsoft.  I think that this community, whatever it is, kind of rely on Microsoft and I used to relying  on Microsoft to provide a tooling to solve these problems, so to speak.  I would not wait around for Microsoft to solve this problem.  I think that the solutions to this problem is already out there.  It's about combining the tools for doing the job.  And honestly, I think Microsoft had us a bad track record in solving these problems.  That's just my honest opinion.  And also, as I mentioned earlier, there's a limited community around these IAC tools.  Although typically, like Chef and Puppet and the other ones, actually I think Puppet is  probably more mature in this area than any other one.  But there's a limited community around that.  So as I said, if you run into a problem or there are a bug in our error or something  like that, it's really hard to get fixed.  And just think about it.  How many talks do you find at DevOps conferences that talk about Windows?  I almost don't know about any.  It's not a common subject at all.  Are we getting some bit depressed now?  Is that just like, OK, I'm going to bring it up soon.  So PowerShell, that's the shell for Windows.  The Dush shell is too limited.  You don't even think about it.  You need to go, but at PowerShell, wait.  So this is a really slow user adoption and honestly, really bad reputation.  Developers love talking down on PowerShell.  It's like, oh, you're doing PowerShell.  Oh, that's a really bad language.  Oh, they love that.  And as I was saying earlier, ops people tend to have a bad conscience for not having thought  themselves or learned PowerShell yet.  But the reason I think, or one of the reasons for that is I think that Microsoft has mostly  focused on PowerShell as a language and not so much as a shell.  And ops people are not set out to learn languages the same way as developers are.  So I think that there's a slow adoption curve there because just a general focus that Microsoft  has on it as a language.  And it just honestly does not give you the obvious core Windows functionality you would  expect from a shell.  It's not done at all as for a shell.  And to just illustrate this.  So if you're familiar with a Linux world or you have a Mac or whatever, you know Schmod.  So Schmod is for changing in access right on your file or directory, something like that.  How do you do Schmod in PowerShell?  Does anybody know?  So how do you do it?  Set ACL.  All right.  Okay, so let's try that.  So I'm just going to, because I don't know, so I'm going to say get help set.  Let's make this bigger, shall we?  Well, actually, I'm going to zoom in for you.  So it says, can we read this?  Is that right?  What is the security descriptor of a specific item, such as a file or a registry key?  Oh, so you've got to be right.  So let's see what it takes as parameters.  Needs a path, okay, a path for a file, that's good.  And then needs an ACL object.  Okay, what's an ACL object?  Where do you get that from?  How do you do that?  Well, that's a.NET object.  It's a security descriptor object in.NET.  We need to create this security descriptor.  But hang on, let's, they probably have some examples for this.  So let's do get help set ACL example.  Oh, here's one.  Oh, you create a new ACL object.  Cool.  How do you do that?  Get ACL file?  What's that?  Okay, so you copy the ACLs from an existing file.  Is that how you define your security descriptor?  Okay.  So I have to manually create a file, set the permissions that I want the file to have,  and then say, get ACL on it in order to get those permissions so I can give those permissions  to another file.  That makes no freaking sense, right?  So they've created get ACL and set ACL, and they ignored everything in between.  So that doesn't make any sense to me.  This should be really, really simple.  This is a core OS thing to do.  I want to change the access rights on a file, right?  So, but you can do it though.  You can, of course, create this ACL object.  Like this.  So first you get the ACL for the object that you are going to manipulate, and then you  new up a new system security access control file system access rule, which is the ACL  object, and then you tell it which user, what type of control you need, and seriously,  some pretty cryptic type of old, calm stuff that they've forwarded into.NET.  So it's really not.NET.  It's calm.  It's a PI invoke simplified for those who are familiar with the.NET world.  And then you set the access rule, and then at the end use the set ACL.  So yes, you're right, but it's really hard, isn't it?  Shouldn't be like this.  And so I tweeted this a few days ago, and somebody said, well, there's a module for  this.  Yes, there is.  So somebody in the community actually took the time and make this right, right?  So they create a module for it.  So you need to download that and install it and use that instead, and it's all good.  But I mean, it's a core operating system thing, right?  You should expect the shell to do this.  And there are many, many examples of the same thing in the PowerShell shell.  So I think if Microsoft should do something, they should focus more on their shell and  less on PowerShell as a language.  And by the way, here's the tool I was talking about.  Not that.  Anyway, it's a data URL.  There it is.  Fast system security PowerShell module.  So if you need ACL stuff, use that.  And recently in PowerShell 4, which is the current version of PowerShell we have today,  they introduced PowerShell desired state configuration or DSC.  Does anybody know what DSC is?  Few people, right?  So for me, this looks like Microsoft's attempt to do the DevOps type of thing or probably  a bad wording to use in this context.  So the same thing as the Chef and Puppet and the other tools are doing is that they define  the state of what they want or the state that they want to have on a server, for instance.  So this tool is set out to do exactly that.  And this is an example of how it looks.  So I can take this file or this text.  I can just copy it into PowerShell.  There's somebody just going to create a new shell so I don't have any existing.  Oops.  Like this.  So now I have a local function inside which is called file resource demo.  So if I do like file resource, right?  PowerShell detects that.  So if you look back here, what you need to do is just call that.  Okay.  So I'm just going to call that.  Next I'm just going to CD out into temp.  And you see.  And I'm going to call that.  And something happened and outputted a local host MOF file.  So it's kind of a compilation.  And it creates a file for you so you can use to run.  And the way you run is you say start DSC configuration, you point to the directory, which I'm just  going to show you now.  So bad directory to choose.  CD and they see something.  Anyway I forgot to go into that.  Create a folder called file resource demo.  So if I'm going to run that.  I'm just saying start configuration pointing to that folder containing that file and will  execute whatever that said it should do.  So what did it say?  So it uses configuration.  That's just the main header of your DSC.  And then there's node and pointing to a server.  So that can be a, so I have hard coded that now to local host so that can just be a variable.  So you can replace that with whatever you want and pass that into this file.  And then I say file and I call this operation directory copy.  And I say ensure present, type directory, recursive true and then a point to a source  path on my client.  So in this case that's temp2.  And then I say the destination path on whatever server I'm going to run this towards is temp2  underscore and is COSLOW.  So let's just see.  So there's already a temp and is COSLOW here because I forgot to delete earlier.  So I'm just going to delete that.  So basically it's going to take this temp2 folder and copied it since this local host  I don't have a remote server to show it on.  But it could be a remote server and does the exact same thing.  Take some time.  But what it actually figures out is, so it doesn't just do file copy, right?  It actually checks the state on a client versus the server you're pointing to or the servers  you're pointing to.  So it synchronizes the files.  That's a distinction you need to make.  So if somebody has deleted a file on the server in this directory and you run this thing,  it would actually make sure the file gets back.  But more importantly, if you delete a file on a client and synchronize it, it will make  sure that it's copied over, right?  So it synchronizes the thing.  It doesn't just copy it.  So this is all good.  DSC, I kind of like.  But I kind of have a hard time understanding what Microsoft is trying to do, right?  Because there are very few resources available that has this DSC thing.  And yeah, of course, it's not important, which was what I just explained.  Basically, it makes sure that the state is correct.  And you can run them as many times as you want.  And it still makes sure that the state is correct.  So Microsoft really needs to do a way better job in order to provide the tooling around  this space than they already have.  But let's look at PowerShell 5.  So that's the new PowerShell coming in Windows 10, right?  So let's see what they've done with regards to DevOps.  Well not only regards to DevOps, but mostly in general.  We can now copy files from one server to another.  They took them so long, right?  I'm serious.  OK, you could copy files earlier, but you were reliant on Windows networking and all  kinds of ports being opened.  And you couldn't just use that.  You need to rely on these things working over HTTP.  That's where stuff happens nowadays.  So yes, in Windows 10, we can actually copy a file from a client to a server.  Yes, that's progress.  They've added support for PowerShell Get, which is a gallery you can upload or download  modules from.  Yes, that's good.  They're starting now to create some tooling around actually getting components easy and  don't have to like browse the internet, download the thing, extract the interfolder in a specific  place, know if a PowerShell defined it and so forth, right?  It's really easy.  Just point this command line tool to a certain place and you get the module.  Good.  They've added some object-oriented language improvements.  Actually class an enum.  I never saw that coming, honestly.  That is, I'm not missed that at all.  That is not what I wanted for PowerShell going forward.  I think PowerShell, as it is today, works.  And okay, class an enum, maybe, but that was not on top of my list.  They now have support for zip files and symbolic links.  Yes, finally.  Again, I mean, the community have done this a long time ago, right?  They provided support for this.  But now it's in the core PowerShell, which is good.  The package management module, and actually I'm going to talk a bit about that later on.  So I'm going to skip that.  And there's a few other things.  So we can versioning a module in a single folder.  So just as you know, run as credentials is now supported in DSC.  This is also a thing that you would have expected from to begin with, but it's good that it's  there now.  You can now define the pencies across computers in DSC.  It is also, that's good.  But there's no ACL or SMART support, though.  I mean, come on.  You need to provide the basic stuff before you do all these advanced stuff, right?  You need to make it a shell first, and then you can start organizing the other things.  And I think that all PowerShell modules and DSC modules should be open source, because  the community would take this responsibility immediately and just fix that problem and  create those resources that are missing in PowerShell.  And according to the community in PowerShell, this is apparently going on right now.  It takes time because of legal, la, la, la, same thing.  But let's hope that happens.  I think this is a key part of actually PowerShell getting to the level that we would expect  from any shell, no matter platform.  So and then we have the operation, operating system package manager.  So does anyone use a package manager for Windows today?  And I'm not talking about Windows installer and like that.  So again, use a command line tool and go online and get a package or install some software,  right?  So maybe 10 people.  And it's probably this one.  Is that correct?  Chocolate tea, right?  All right.  And it's really good that this tool finally arrived.  But it was started, it was done in the community.  Microsoft now have seen this and of course we need to have this.  So just for those of you who don't know, chocolate tea is basically up, get a brew from, as it  is from Mac, for Windows, right?  So you can just use this, you say Choco install and then point to, let's say, Adam or Sublime  or some application you want to have installed and just downloads it, installs it and you're  all good.  Really, really easy.  You don't have to open your browser, find Google for some tool, find it, download it,  unzip it, run MSI, which is included in that zip and click next, next, next, finish.  You don't have to do that anymore.  And just, yeah, it's the proper way.  So if you don't do chocolate tea today, start using it now.  So what happens tomorrow?  So when PowerShell 5 comes along and Windows 10, well, one get is added, which is basically,  which is integrated to PowerShell 5.  And what one get is, it's not a package manager per se, but it's an interface which package  managers can integrate with.  So that using one get and in PowerShell, you can get stuff from through chocolate tea,  so to speak.  So it gives you this new system of applications that you can download.  So that's good.  So how about a server operating system?  I don't think anyone would argue against me on this.  It's hard to automate and configure.  Does anyone think differently?  I think we're all agreeing on this.  It's auto-automate, automate installation of applications.  So how are typical applications on Windows distributed?  Well as MSI's or XC's and sometimes ZIP's or stuff like that, but the most professional  applications are usually packaged as an MSI or XC.  So you can automate an MSI.  You can use MSI exec and install an MSI given that the author of the package actually took  into consideration that it should be fully automated and provided the necessary parameters  for doing that.  Most of my time trying to install this application, I have to reverse engineer this MSI in order  to figure out which parameters to send in to automate the entire thing.  And this is not just we or whoever who's creating these packages, it's Microsoft too.  They're doing the same thing.  So the worst thing is if you provide an XC and you don't allow any parameters at all,  you have to do the next, next, next finish thing and that doesn't really work in automation.  Fortunately, it seems like everyone is realizing this now and moving away from it based on  the chocolate takeaway and other things.  So that's good.  So just mentioning MSI's, MSU's, web deploy and stuff is the typical way today.  But the operating system is still very UI centric.  There are still things that you just can't do automatically.  You have to use the UI.  And frankly, I mean, that is Windows.  That is what it started out as doing.  So this is the legacy that we brought with us until today.  But now the world has really, really changed and it's not going to work anymore.  This needs to change.  So what happens tomorrow?  So we're talking Windows Server 2016.  So Jeffrey Snowber, which I referenced earlier, said this.  Admin GUIs on servers are poison.  They're like heroin.  You know, first shot of heroin probably feels pretty good.  But you do it a bunch.  You like goes to heck and you do it too much.  You're dead.  Pretty bold statement coming from somebody who's responsible for Windows Server.  So it's changing and that's good, right?  I like that.  I like the new direction that Microsoft is going.  It's the right direction.  I think everybody agrees on that.  But so the big thing now is Windows Nano, right?  That is the operating system or the stripped down operating system that Microsoft had to  create in order to support containers.  And I'm going to do big talk on containerization or anything like that.  But if you don't know what container is, you will.  I mean, this is huge.  Everybody's going to do some type of containerization going forward.  There's no doubt about it.  So Windows Nano is the Windows version you're going to use for this.  So and there is no UI.  You open, you run Windows Nano and there's nothing there.  You have to automate it remotely, right?  So the key thing is they're working away from this rich UI and they're communicating the  message clearly, right?  But this scares the shit out of the ops world in Windows.  I'm serious because you just can't say that.  Well, tomorrow we're removing all the UIs and they have a big investment and reliant  on all these UI tools, right?  So of course they're going to continue to support the UIs.  But the major difference is that they're now moving the UI tools to the client remotely  communicating with the server and, well, actually optionally you can have them installed it  on the server as well.  So and that is one of the things that Microsoft is good at is being backward compatible.  So I would expect this story to continue.  And they're working on a new Windows installer.  And I don't know how many efforts has been done around working with installer mechanisms.  But the thing is that the existing MSI-XSEC or MSI installer doesn't work good enough  in this world.  So apparently they're looking at creating a new one.  And I think that's probably good too if they get it right.  Any questions so far?  Comments?  All right.  So what about the.NET story?  I would argue the only reason to run Windows Server today is because of.NET.  Is there anybody in this room that runs Windows Server for something else than.NET?  No one.  One person.  Update services.  Update services.  Right.  But if we're thinking DevOps and WebOps, it's, yeah.  Right.  If you, so if you're following along what have happened in the announcements lately for Microsoft,  we're talking about this new thing called the Core CLR, which has no UI stuff and all  that and still shrift down.  So if you want to have your application run on Windows Nano, you have to rewrite your  application in order to get down to the Core CLR.  If you do that, you can run it on Nano, but you can run it on any other OS supporting the  Core CLR like Linux, Mac, FreeBSD.  Right.  So my open question is, so why would you choose to run on Windows?  I'm not going to answer it.  I don't have an answer for it, but I'll leave that open to you.  But I think Microsoft needs to do something in this space in order to provide the added  benefit of running Windows.  Or else I can't see why we should use it.  So bottom line, I would expect more from Microsoft.  PowerShell is still too limited and needs its shell.  I mean, the shell is not a shell yet.  They need to improve that a lot.  PowerShell needs to get its modules into open source.  And the future value for server OS is unclear in the DevOps world.  Remember, everything I've said today is in relation to DevOps, right?  I'm not talking about all the other DevOps.  And to me, it's very unclear.  When they're opening up.NET that way and I say that, well, that's the only reason I  have for running on a Windows server, then, yeah, it's unclear to me what Microsoft is  thinking.  But no matter what, Microsoft needs a vibrant DevOps community for Windows in order to have  this being a success.  And they need to start helping to organize that community.  And sadly enough, I would expect UI tools coming from Microsoft supporting DevOps.  I hope not, because that is not the way to go about this.  But there are some things that point in that direction.  Yeah, I do not want to have a UI tool for doing these things.  And remember,  Admin GUIs on servers are poison.  Thanks.  Questions?  Yeah?  Anything else other than PowerShell that you can probably use to automate stuff on Windows?  So the question is, is there anything else other than PowerShell you can use to automate  on Windows?  Yes.  So the other ISE toolings I mentioned does not necessarily expose PowerShell to you,  but they rely on PowerShell in order to get stuff done, right?  So you can use any of those tools and you don't necessarily touch PowerShell and you  still accomplish what you want to do.  And yes, you can also use other shells, but I don't think it's the way to go for the future.  It's PowerShell, which is Windows shell, and that is where your investment should be, I  think, going forward.  So the answer to the question is probably no.  Any other question?  All right.  We're getting close to lunch and you wanted the lucky ones that gets to get first in the  line, apparently.  So thank you.
The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_0_1175.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_1176_3359.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_3360_5903.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_5904_6491.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_6492_9071.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_9072_38627.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_38628_38675.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_38676_39131.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_39132_39179.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_39180_39419.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_39420_40295.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_40296_40367.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_40368_40427.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_40428_40655.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_40656_42095.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_42096_42155.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_42156_42275.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_42276_42359.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_42360_42407.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_42408_42455.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_42456_42755.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_42756_42851.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_42852_42935.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_42936_43115.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_43116_43175.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_43176_43607.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_43608_43799.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_43800_44735.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_44736_44783.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_44784_44951.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_44952_45119.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_45120_45323.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_45324_45419.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_45420_45599.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_45600_46907.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_46908_47075.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_47076_47711.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_47712_47867.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_47868_48035.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_48036_48095.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_48096_48167.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_48168_48491.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_48492_48683.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_48684_48947.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_48948_49199.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_49200_49259.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_49260_49307.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_49308_49427.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_49428_49703.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_49704_49931.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_49932_49979.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_49980_50027.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_50028_50231.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_50232_50291.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_50292_50351.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_50352_51755.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_51756_51827.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_51828_52103.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_52104_52343.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_52344_53543.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_53544_53591.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_53592_59951.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_59952_67103.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_67104_67955.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_67956_71459.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_71460_74063.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_74064_76343.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_76344_76487.png The_State_of_DevOps_in_Windows_Land_-_Jon_Arild_T__rresdal_76488_78587.png