The State of DevOps in Windows Land
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 163 | |
| Author | ||
| License | 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 | |
| Identifiers | 10.5446/50491 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 2015129 / 163
6
13
16
17
18
19
20
21
22
25
28
29
30
31
40
41
44
45
49
51
52
53
54
55
57
58
60
61
71
74
75
76
78
84
85
91
92
93
94
95
96
98
99
100
105
106
107
112
115
116
117
118
122
123
124
125
127
128
129
130
131
132
133
135
136
142
144
150
151
153
155
156
157
159
160
00:00
State of matterWindowComputing platformBasis <Mathematik>State of matterGoodness of fitServer (computing)Computer animation
00:47
Computing platformTerm (mathematics)Server (computing)Open sourceCodeGastropod shellPower (physics)Windows ServerOperations researchClient (computing)Entrainment (chronobiology)Phase transitionSoftware developerEntire functionPersonal digital assistantFeedbackVector potentialOperator (mathematics)Drop (liquid)Operating systemCartesian coordinate systemUltraviolet photoelectron spectroscopyProjective planeUniform resource locatorSoftware developerType theoryLine (geometry)Server (computing)MereologyComputing platformSuite (music)Dependent and independent variablesPhysical systemMultiplication signGoodness of fitWindowPower (physics)Web 2.0BlogCuboidCross-correlationRight angleFeedbackTerm (mathematics)Process (computing)Product (business)Vector potentialOnline helpClient (computing)Stress (mechanics)Envelope (mathematics)Data managementPartial derivativeFile formatNormal (geometry)ResultantOpen sourceBoss CorporationIntegrated development environmentCASE <Informatik>Exception handling10 (number)SoftwareTheory of relativityArithmetic meanKey (cryptography)Self-organizationDifferent (Kate Ryan album)CodeComputer animation
08:59
Operations researchSuite (music)Gastropod shellPower (physics)Server (computing)Point cloudFlow separationComputer programmingCodeState of matterConfiguration spaceoutputFormal languageWindowOperator (mathematics)Server (computing)Physical systemGastropod shellHydraulic jumpLine (geometry)Computer fileFlow separationUniverse (mathematics)Type theoryNetwork topologyWordComputing platformSuite (music)MiniDiscEndliche ModelltheorieMultiplication signBuildingSoftwareIntegrated development environmentScripting languageMetropolitan area networkCASE <Informatik>Order (biology)Different (Kate Ryan album)Software developerWeightData managementClient (computing)BitException handlingReal numberPoint cloudCellular automatonPower (physics)TrailService (economics)Thermal conductivityEvoluteRight angleWebsiteOffice suiteCodeSymbol tableConfiguration spaceLevel (video gaming)Computer animation
17:10
Configuration spaceGastropod shellPower (physics)State of matterCodeFormal languageServer (computing)Formal languageTrailProcess (computing)Direction (geometry)Web 2.0Revision controlWindowWordSimilarity (geometry)MultilaterationBitError messageSoftware bugAreaRow (database)Product (business)Operator (mathematics)Goodness of fitGastropod shellProjective planeSoftware developerFocus (optics)CurveConfiguration spaceEndliche ModelltheorieWindow functionCore dumpPhysical systemSystem callPlanningQuicksortRight angleFirewall (computing)1 (number)WebsiteData miningRouter (computing)Power (physics)Multiplication signThermal conductivitySet (mathematics)Lie groupGame theoryUltraviolet photoelectron spectroscopyLimit (category theory)CodeComputer fileAutomatic differentiationDataflowExistencePartial derivativeComputer animation
25:22
Demo (music)Windows RegistryComputer fileInformation securityString (computer science)Object (grammar)Inclusion mapParameter (computer programming)Database transactionVariable (mathematics)Operator (mathematics)Gastropod shellPower (physics)ZugriffskontrollePhysical systemInheritance (object-oriented programming)Control flowConfiguration spaceState of matterDefault (computer science)Data typeDirectory serviceStrutSource codeDrum memoryJava appletCone penetration testLengthView (database)Scripting languageComputer fileFile systemDirectory serviceInformation securityConfiguration spaceObject (grammar)Operating systemGastropod shellGame controllerMathematicsPhysical systemCore dumpLocal ringFunctional (mathematics)Instance (computer science)Ocean currentModule (mathematics)WeightGoodness of fitType theorySet (mathematics)Coma BerenicesWindows RegistryContext awarenessWordRevision controlState of matterRight angleOrder (biology)Rule of inferenceCartesian coordinate systemServer (computing)Ultraviolet photoelectron spectroscopyMedical imagingArithmetic meanMultiplication signCompilation albumEndliche ModelltheoriePartial derivativeElectronic mailing listDot productLevel (video gaming)Computer animation
33:34
Gastropod shellPower (physics)Server (computing)Source codeNP-hardPhysical systemOperations researchMessage passingWindows ServerWeightCore dumpMultiplication signSynchronizationRecursionPresentation of a groupOperator (mathematics)WindowServer (computing)Module (mathematics)Point (geometry)Client (computing)Parameter (computer programming)Order (biology)Process (computing)State of matterSource codeGastropod shell1 (number)Core dumpOperating systemComputer fileEmailPhysical systemOpen sourceReverse engineeringVariable (mathematics)Open setCartesian coordinate systemRight angleType theoryGraphical user interfaceSystem administratorDirection (geometry)Directory serviceExpected valueTheory of relativityWeightRevision controlObject-oriented programmingService (economics)Installation artMechanism designDifferent (Kate Ryan album)User interfaceSpacetimeAuthorizationMessage passingDependent and independent variablesStatement (computer science)Video gameComputing platformWeb 2.0Data managementInterface (computing)PlastikkarteGoodness of fitNeuroinformatikLevel (video gaming)MereologyElectronic mailing listSocial classTelephone number mappingLink (knot theory)Symbol tablePartial derivativeSeries (mathematics)Workstation <Musikinstrument>Content (media)Sign (mathematics)AxiomPerturbation theoryPower (physics)SummierbarkeitCASE <Informatik>Tape driveWeb browserGoogolLine (geometry)Closed setSoftwareFlow separationData storage devicePhysical lawInternetworkingFormal languageMassSession Initiation ProtocolMetropolitan area networkLimit (category theory)Object (grammar)Connectivity (graph theory)Arithmetic meanConfiguration spaceComputer animation
Transcript: English(auto-generated)
00:01
All right, welcome. I'm going to talk about a state of DevOps 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
00:21
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 DevOps. All right. My name is Johan Adel Telestal. I work for Miles in Bergen on the west coast of Norway.
00:49
And I more or less work professionally on the Windows platform or Windows server since 2000. More or less worked with DevOps long before the term was coined.
01:01
But more importantly, I worked six years for Fender for Sickring, a Norwegian insurance company. There I spent most of my time actually getting the DevOps practices into place. So it all started like the normal CI story, continuous integration, and then just moved on and moved
01:21
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,
01:41
which resulted in me creating an open source project called Condapp back in 2011. That project is still around. It's what we call an 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.
02:05
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 about today? Well, culture. So what's the culture like in these type of Windows-based
02:25
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
02:43
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. And it's about servers and server applications.
03:05
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, they're
03:22
doing great stuff within DevOps for the client platform. And that's actually right. 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
03:43
well in the DevOps world. It's different. So 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
04:03
of confusion, right? That's a classical picture you will see from DevOps that 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.
04:20
Well, to me, DevOps to me is developers and operations collectively taking responsibility for applications during all phases, including production. But I also think that OR operations trusting developers
04:41
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 typical in companies where operations are outsourced,
05:04
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 or
05:22
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.
05:43
And in both cases, a shared understanding and trust between Dev and Ops is required. 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.
06:00
It's all trust related. So culture. The gap between Dev and Ops in most organizations result in a major bottleneck, bringing with it significant hidden cost way outside of IT. Does anybody know who said that?
06:24
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. No, but really, this is one of the key things within Dev
06:45
Ops, because we as developers or operations people have a really hard time explaining to the business why Dev Ops is a good thing. And one of the reasons for this is the hidden part. This is a hidden cost.
07:01
It's really hard to see it. And there's a historical aspect here as well. It's always been like that. We've always had operations. We always have development. And we always hand it off from the one to the other. But in most businesses today, at least, well, business
07:21
leaders in most businesses have 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 this is not specific to corporations that
07:45
rely on Windows servers. I think this is general, that they basically just don't know that the Dev Ops 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.
08:03
And most importantly, they're unaware of the economical benefits of actually implementing Dev Ops and the efficiency, potential, and 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
08:22
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.
08:41
So everybody should have an understanding of what Dev Ops means. So how about on the operations side? Well, in the Windows world, there's a tooling suite that are very, very UI-centric.
09:02
And they're typically, in my opinion, too dependent or reliant on SCOM-like tooling, so System Center 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 Dev Ops,
09:23
not so much. So you're looking for a different type of tooling and a different type of mindset in this world. They're lacking automation. And there's no scripting culture. I say no scripting culture. Of course, you'll find exceptions. But you see less scripting here in this environment.
09:44
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
10:01
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 a few excuses. And I'll get back to that later on when I talk about PowerShell, why I think that is.
10:22
But more importantly, in the Windows world, and it's not unique to Windows, but I'll talk about Windows here, is that it still treats servers as pets versus cattle. And by that I mean, if you heard the lead architect for Windows Server, Jeffrey Snover, I think he's called,
10:44
he talked about this at Build 2015. So with pets, right, you take care of them, you feed them, and you're cozy with them, and yeah, you're nice to them, right? Well, the world has changed.
11:00
You don't do that to servers anymore. You don't 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
11:21
barbecue, so to speak, in a cattle sense. So the thing is, you automate everything. 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. And I think in the Windows world, there's still this
11:42
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
12:02
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.
12:21
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.
12:40
That is the thing that is in the company I work, they say. And Upton Sinclair, back in the 30s, said, 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.
13:03
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.
13:25
And I also think, 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?
13:41
I've talked to universities and stuff over the years, and I always emphasize that you've got to stop making this huge separation between dev and ops. Because devs needs ops knowledge, and ops needs programming knowledge.
14:01
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.
14:20
You have to know the tools that is relevant for working with dev ops, 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.
14:43
So we talked about this as infrastructure as code, or IAC. And modestly enough, I'll put Condep on top here. And I'm not saying that, well, don't take my word for it, right? Don't jump ahead and do Condep straight away, because that's the best tool he said so.
15:01
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
15:21
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. So and then Chef came along, which was after Puppet. And the Chef people had experience from Puppet, and
15:42
they wanted to do things a bit differently. So looking outside in, the major difference between Puppet and Chef is Puppet is an external DSL, and Chef is an internal DSL. And there are, of course, other differences.
16:02
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.
16:23
So you put Ansible on a central server, which can communicate with all your other servers, and they push out stuff. So the benefit by the push model is it's a lot simpler, and it's easier to understand and work with.
16:41
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. 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.
17:04
And the same thing with Condep. 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
17:23
were between the two. Again, I've created that tool, so don't take my word for it. But I think there's a lot of similarities. And I think it also is because those both projects took inspiration from the same tools and tried to make the same improvements, so to speak.
17:45
So let's take Chef. 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?
18:02
OK, there's a few that are 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 world, right? That's where it all started.
18:21
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,
18:41
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 on 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.
19:03
And also, since Windows is not primarily focused for Chef, even though they now have all this cooperation with Microsoft and all that, and it's probably got better since when I were using it, Windows, in my mind, will always
19:21
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.
19:43
Because deployment is the thing that, well, it's the obvious thing to start with. But in my mind, deployment in this area, even on Windows, is a solved problem. There are tons of tools that you can use, or there are enough tools that you
20:01
can use that the technology is no longer an excuse. 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.
20:23
But Condap has a deployment model. Octopus is a pretty common tool in the Windows.net world to deploy stuff. And it's a great tool. It has more than just deployment. It has the deployment workflow, the pipeline, which is good. Condap does currently not have that.
20:40
So if you're just looking for deployment, I would really recommend Octopus, because this is a really kickstarter for this process. But thinking DevOps, don't stop after deployment. That's just the first step. You need to automate all these other things, too. You need to automate the entire configurations
21:00
for your servers. And where I come from, where I used to work at Fender, 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 that should be code?
21:20
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.
21:45
So, questions so far? What about the DevOps community on Windows? Well, I would argue it's very small, almost invisible. Almost doesn't exist.
22:04
Does anyone disagree, or is that what you feel, too? Yeah, that's definitely where I am. I'm in the middle of that community, and I feel pretty much alone, to be honest. I also think it's very coupled to Microsoft.
22:22
I think that this community, whatever it is, kind of rely on Microsoft. And I'm used to relying on Microsoft to provide the tooling to solve this problem, so to speak. I would not wait around for Microsoft to solve this problem. I think that the solutions to this problem
22:41
is already out there. It's about combining the tools for doing the job. And honestly, I think Microsoft has a bad track record in solving these problems. That's just my honest opinion. And also, as I mentioned earlier,
23:00
there's a limited community around these IAC tools. So 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 and an error or something like that, it's really hard to get fixed.
23:22
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 a bit depressed now? Is that just like, OK, I'm going to bring it up soon?
23:43
So PowerShell, that's the shell for Windows, right? Like the dust shell is too limited. You don't even think about it. You need to go the PowerShell way. But there's a really slow user adoption.
24:01
And honestly, really bad reputation. Developers love talking down on PowerShell. It's like, how are you doing in 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
24:22
themselves or learned PowerShell yet. And 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.
24:41
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 the general focus that Microsoft has on it as a language.
25:00
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,
25:23
you know shmod. So shmod is for changing an access right on your file or a directory, something like that. How do you do shmod in PowerShell? Does anybody know? So how do you do it? Set ACL.
25:41
Set ACL. All right. OK, so let's try that. So I'm just going to, because I don't know, 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.
26:05
So it says, can you read this? Is that right? Changes the security descriptor of a specific item, such as a file or a registry key. Oh, so you've got to be right.
26:21
So let's see what it takes as parameters. Needs a path. OK, a path for a file. That's good. And then needs an ACL object. OK, what's an ACL object? Where do you get that from? How do you do that? Well, that's a dot net object. It's a security descriptor object in dot net.
26:42
So I need to create this security descriptor. But hang on. They probably have some examples for this. So let's do get help set ACL example.
27:03
Oh, here's one. Oh, you create a new ACL object. Cool. How do you do that? Get ACL file? What's that? OK, so you copy the ACLs from an existing file. Is that how you define your security descriptor?
27:26
OK, 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 permission to another file. That makes no freaking sense, right?
27:41
So they 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. So, but you can do it, though.
28:02
You can, of course, create this ACL object like this. So first you get the ACL for the object
28:22
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,
28:43
some pretty cryptic type of old COM stuff that they ported into .NET. So it's really not .NET. It's COM. It's PI invoke simplified, for those who are familiar with the .NET world.
29:06
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,
29:21
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. So they created 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?
29:43
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.
30:02
By the way, here's the tool I was talking about. Not that. Anyway, it's a .DAV URL. There it is. File system security PowerShell module.
30:21
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?
30:41
A few people. 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 Chef and Puppet and the other tools are doing is that they define the state of what they want,
31:03
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, and I can just copy it into PowerShell.
31:27
Or somebody's just going to create a new shell so I don't have any existing oops, like this.
31:41
So now I have a local function inside, which is called FileResourceDemo. So if I do FileResource PowerShell detects that.
32:00
So if you look back here, what you need to do is just call that. So I'm just going to call that. Actually, I'm just going to cd out into pldc.
32:21
And I'm going to call that. And something happened and outputted a local host moff file. So it's kind of a compilation. It creates a file for you, so you can use to run. And the way you run is you say dart start dsc
32:43
configuration. You point to the directory, which I'm just going to show you now. So it's a bad directory to choose. CD and a C something.
33:05
Anyway, I forgot to go into that. Create a folder called FileResourceDemo. So if I'm going to run that, I'm just saying start configuration pointing
33:23
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.
33:43
And then it says node and pointing to a server. So I've 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
34:04
copy. And I say ensure present type directory, recursive true, and then I 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
34:24
is temp2 underscore nscoslo. So let's just see. So there's already a temp nscoslo here because I forgot to delete it earlier. So I'm just going to delete that. So basically, it's going to take this temp2 folder
34:43
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. Takes some time, but what it actually figures out is so it doesn't just do file copy, right?
35:02
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. And that's a distinction you need to make. So if somebody has deleted a file on the server in this directory
35:22
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.
35:41
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.
36:03
And yeah, of course, it's idempotent, which was what I just explained. Basically, it makes sure that the state is correct. And it 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
36:23
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 in regards to DevOps, but mostly in general.
36:41
We can now copy files from one server to another. It 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 open. And you couldn't just use that. You need to rely on these things working over HTTP.
37:03
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.
37:22
Yes, that's good. They're starting now to create some tooling around actually getting components easy and don't have to browse the internet, download the thing, extract it into a folder in a specific place. Nor for PowerShell to find it and so forth, right?
37:40
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, specifically class and enum. I never saw that coming, honestly. I've not missed that at all.
38:02
That is not one I wanted for PowerShell going forward. I think PowerShell, as it is today, works. And OK, class and enum, maybe, but that was not on top of my list. They now have support for zip files and symbolic links.
38:21
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.
38:41
And there's a few other things. So we can versioning of modules 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 to begin with, but it's good that it's there now. You can now define dependencies across computers in DSC.
39:03
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.
39:22
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 for PowerShell, this is apparently going on right now.
39:42
It takes time because it's 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.
40:01
And then we have the operating system package manager. So does anyone use a package manager for Windows today? And I'm not talking about Windows Installer or anything like that. So again, use a command line tool and go online
40:22
and get a package or install some software, right? So maybe 10 people. And it's probably this one. Is that correct? Chocolatey, right? All right. And it's really good that this tool finally arrived.
40:42
But 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, Chocolatey is basically app get or brew, as it is for Mac, for Windows. So you can just use this.
41:00
You say, Choco install, and then point to, let's say, Atom or Sublime or some application you want to have installed. And it 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.
41:21
Run MSI, which is included in that zip, and click next, next, next, finish. You don't have to do that anymore. Yeah. It's the proper way. So if you don't do Chocolatey today, start using it now. So what happens tomorrow, so when PowerShell 5 comes along
41:41
and Windows 10? Well, one get is added, 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 in PowerShell,
42:05
you can get stuff through Chocolatey, 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?
42:25
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 how to automate installation of applications.
42:42
So how are typical applications on Windows distributed? Well, as MSIs or XCs, and sometimes zips or stuff like that, but the most professional applications are usually packaged as an MSI or an XC.
43:00
So you can automate an MSI. You can use MSIXEC 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,
43:20
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
43:41
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 Chocolatay way and other things. So that's good. So just mentioning MSIs, MSUs, web deploy and stuff
44:04
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.
44:23
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.
44:45
So Jeffrey Snover, which I referenced earlier, said this. Admin GUIs on servers are poison. They're like heroin. Your first shot of heroin probably feels pretty good. But you do it a bunch, your life goes to heck, and you do it too much, you're dead.
45:01
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. So the big thing now is Windows Nano, right?
45:23
That is the operating system, or the stripped down operating system that Microsoft had to create in order to support containers. I'm not going to do a big talk on containerization or anything like that, but if you don't know what container is,
45:41
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 there is no UI. You open, you run Windows Nano, and there's nothing there.
46:03
You have to automate it remotely. 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.
46:21
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,
46:43
remotely communicating with the server. And well, actually, optionally, you can have them installed on a server as well. And that is one of the things that Microsoft is good at, is being backward compatible. So I would expect this story to continue.
47:03
And they're working on a new Windows installer. And I don't know how many efforts have been done around working with installer mechanisms. But the thing is that the existing MSI Exsec or MSI installer doesn't work good enough in this world.
47:22
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
47:45
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.
48:01
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 stripped down.
48:23
So if you want to have your application run on Windows Nano, you have to rewrite your application or get down to the core CLR, right? If you do that, you can run it on Nano,
48:42
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?
49:02
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.
49:24
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.
49:42
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 stuff. 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
50:03
for running on a Windows server, then, yeah, it's unclear to me what Microsoft are 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.
50:26
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.
50:46
Yeah. I do not want to have a UI tool for doing these things. And remember, admin GUIs on servers are poison. Thanks.
51:02
Questions? Yeah. So the question is, is there anything else other than PowerShell you can use to automate on Windows? Yes. So the other IEC toolings I now mentioned
51:25
does not necessarily expose PowerShell to you, but they rely on PowerShell in order to get stuff done. So you can use any of those tools, and you don't necessarily touch PowerShell, and you still accomplish what you want to do.
51:41
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.
52:03
Any other question? All right. We're getting close to lunch, and you're one of the lucky ones that gets to get first in the line, apparently. So thank you.