Ladies and gentlemen, Jeffrey Snover. Yeah, I'm glad you applauded before my talk. I'm not sure I'll go after it at the end. Well, howdy, I'm Jeffrey Snover.

We're going to talk about PowerShell and this year. Oh, you know what, I should have, I got the wrong dang thing. Oh hell. Don, give me one minute. It's almost, right, you know, if you ever heard the story

that PowerShell is so awesome because I'm such a flawed person, that's not actually a joke. That's a true thing. And I was looking for a clicker here. No? I think it's on my floor at home. Okay, well, there you go. Not going to go very far. Hey.

Yeah, so it's true. PowerShell is such a great product because I'm such a flawed person. In fact, first thing this morning, I was sitting right down here getting ready, cleaning things up, and I deleted most of my demos. So, no, I did. So, there might be a few rough spots. Let's see. Okay, so it's 2018 and PowerShell's never been more important.

That's really the end of my talk. You know, I mean, they got some details, but this is it, right? You know, is PowerShell done? No, it's not done. Is it important? Oh, my heavens, it's never been more important. So, why is it that PowerShell is so important?

And, you know, we used to say, oh, well, you know, there's this inflection point, the cloud, and the cloud changes everything. But that's not really yet, right? What's really yet, there is an inflection point, but the cloud is a technology. The inflection point is digital transformation.

Digital transformation is in the grand arc of computing this huge inflection point that's going to affect everyone in this room, everyone in our industry. And why this is so important is that automation is a thing that enables digital transformation, and that's why PowerShell is so critical,

more critical now than it's ever been in the past. Digital transformation does not work without automation, okay? So, you might have heard of this thing called Moore's Law, right? Doubling of transistors every year. It's sort of been the kind of foundation of our industry

for the last, what, 30, 40 years, right? Heard all about that. Well, I'm here to tell you that this is less important in the future, and that what's more important for the next 20 years of computing is what I call the other Moore's Law.

And this other Moore's Law is Jeffrey Moore, okay? Now, this has a link here, a seven-minute video that explains this in great detail. I encourage you to watch that. But Jeffrey Moore basically drew this distinction. He said, listen, every company participates in two activities, something he called core and something he called context.

Core are those things that advance your mission, that differentiate you from your competitors, and allow you to charge money, okay? Context is everything else. So, let me give you an example. Microsoft, our core is software, so we go out of our way to find the world's best software people, hire them, treat them well, develop software.

But in order for that to work, we have to have things like receptionists, shuttles, cafeterias, right? These are not core to our business. If Microsoft was awesome at our cafeterias, no one would buy more of our software, okay? So, these are the everything else. They're important, but we just want to write a check for them, right?

So, to be concrete, we have no technical fellow of the cafeterias, right? No distinguished engineers of the shuttles. Now, we pay a lot of money. We want great service, but Satya never gets his leadership team together and is like, okay, let's go over the menus for next week's lunch, right?

This is just not something where you put your energy on, right? You put your energy and your best people on the things that differentiate you, but you have to do this other stuff. Now, then, he draws this other axis, and that's mission critical. Here's the definition of mission critical. Screw up, you're effed, okay?

I'm trying to clean up my act. Okay, so screw up and you're effed. And then everything else, right? So, the interesting part about this is that, of course, this is where you make all your money, but this is where your risk is. So, you might say, well, hey, how can something be mission critical and still be context? And the answer is that when you have something that is core and mission critical,

that's where you're making all your money, over time, the market will respond. It will respond with an alternative, with a substitute, or with something that becomes different. And so you're no longer able to charge a premium for this, okay?

But it's still mission critical, which is to say if you screwed up, you're effed. So, this is what happened. This is where you get risk, right? This is where Jeffrey Morris says, he called it the killing field of once great companies, okay? And so what you want to do is you want to focus all of your energy

on the things that differentiate you, the things that you and only you can do, and then de-risk everything else. So, how do you do that? And the answer is you've got to reduce the risk here. By the way, one of the reasons why it's the killing field is often because it's mission critical, and often because to become successful,

you had to incur a lot of technical debt, you know, often these things are a mess. And so you've got to go invest, try and, people will increase their investment at a time when they can no longer charge a premium, and that's where they end up dying. So, what you have to do is you have to reduce the risk of these things by reducing the complexity, and the way you reduce complexity is you standardize.

Put it all underneath one person, standardize things. You automate, automate, automate, and then you take the components and you either offshore them, you outsource them, or automate them, okay? So, that's the heart of this.

And what this does then allows you to take resources out of what is mission critical and to focus in on mission critical core, the things that differentiate you. So, the heart of this digital transformation, and by the way, this is digital transformation 101. We're going really quick through it. But at the end, it's not that complicated, okay?

At the end, it's not that complicated. What you want to do is you want to build the things that advance your mission, that differentiate you, that you're able to charge a premium for, and you want to buy everything else, right? Just write a check. Okay, it's that simple, really. Now, sounds great, how do you do that, right?

You just go to your boss and say, hey, give me some more people. I went to this talk, Jeffrey Snover, oh my God, digital transformation. I'm totally in. This is what we must do. I just need 40, 50, 100, 200 more heads, right?

Anybody going to be successful with that conversation? No, exactly, smart crowd. No, you don't, right? That's not going to work. So, but in order to pursue digital transformation, right? Because guess what? The folks who get this right are going to win, and the folks that don't are going to lose. How do you do that? And the answer is the only people that are going to be successful

with digital transformation are the people that do these two things. Number one is you got to create bandwidth. You got to create bandwidth out of the stuff you're doing right now, and then with that bandwidth, you invest that in innovation. And then you do it again and again and again, okay?

So how do you create bandwidth, right? The answer is it's pretty simple. First is software as a service, right? If there's a software of a service out there for something that you're doing by yourself, you should just bite the bullet and take advantage of that software as a service. Let me give you an example. There is no airline that can put more people in planes

because they can run exchange better than their competition, right? Nobody is going to be able to sell more sneakers or shoes than their competition because they can run visual studio team services, right? These are important things, right?

Email, mission critical, but it doesn't differentiate you. So in reality, you should just write a check. We run those things really well. There's lots of SaaSes out there. If you have a choice, you should just use a SaaS. Now, number two is lift and shift, right? Lift and shift is the term where you take existing virtual machines

or physical machines and run them in the cloud. And you'll see that just running them in the cloud actually generates bandwidth. And the reason it generates bandwidth is because running the cloud, the cloud vendors provide so much functionality for you, okay? I'll give you some examples of that. But then it's automate, automate, automate, right?

How much of this stuff do you do today is just click next, click next, click next. Good Lord. Instead, you automate that stuff. When you automate it, you free up resources. What do you do with those resources? You invest in automation, okay? So this is where you want to invest, right?

This is where you take those people and you're going to invest in new architectures, all right? These new architectures should take advantage of cloud services like PaaS. That allows you to focus most of your energy, right? Here's the heart of it. You want to be really good at listening to customers,

figuring out what they're really saying, and then delivering that as a set of features very quickly and then doing it again, okay? So listen, react, deliver, listen. Fast, fast, fast. PaaS services allow you to do that, right?

To spend more of your energy doing that than, oh, hey, there's a new patch of the operating system, blah, blah, blah, blah, blah. Don't do any of that. We do that for you. The next is to embrace DevOps. Now, anybody been to a DevOps conference before? Yeah, yeah, yeah. Okay, great. DevOps, fantastic stuff. If you go to a DevOps conference,

what you will find is they spend an inordinate amount of time talking about what DevOps is and isn't, and no one ever agrees, ever. So here's the primer. I can save you all, like, lots of time and money. DevOps is really only two things. One, it's to go faster by doing smaller batches,

more frequent smaller batches, and number two is stop being an asshole to your fellow team members. Really, that's it. No, seriously, it is. It really is. Where the other team members, you know, the developers are jerks to the operators, the operators are jerks to the... No, you're all part of one team focused in on advancing the customer value proposition.

It reminds me of this funny story. Ever heard of this guy, Curtis LeMay? Curtis LeMay was this Air Force general. Anyway, he was an Air Force guy and a cold warrior, right? And at some point, one of his lieutenants is there talking about,

you know, talking about the Russians, oh, the enemy this and the enemy that, and Curtis LeMay said, young man, just stop that right now. He says, I want you to stop referring to the Russians as the enemy. They are our adversary. The enemy is the Navy. So, anyway, so you want to embrace DevOps, okay?

And then what do you do in innovation? You automate, you automate, you automate. Now, why is it important here as well? And the answer is, in the first case, you automate to create bandwidth. But here you're automating to increase quality and speed, okay?

So you want to get to a world where when you make a change, you automatically build that change, automatically test that change, and if the tests succeed, you publish it, right? Michael Green's here. Hopefully he's going to give a talk on that. Where's Michael? Somewhere. Perfect. So Michael Green's going to talk about that.

But you want to automate, automate, automate to increase the quality of your operations. So the heart of this is that those people that get digital transformation right are going to have just a huge business advantage, a huge business advantage.

They are going to flourish. And the people that don't, not so much, okay? So excellence at digital transformation means winning. Excellent at automation means winning. I truly believe that. The people who are great at automating are going to deliver their company such huge advantages that their careers are going to prosper,

their company's going to prosper. It all starts from the customer, right? You can't have a failing business and you succeeding with your career. It doesn't work that way, right? So the customer has to be successful. Your company has to be doing great with the customers. From there the customer prospers. And if you've been part of that chain, you will prosper as well.

So getting excellent at automation is all about winning. Great. Digital transformation. So it's just Windows PowerShell, right? The answer is no. No. Windows PowerShell is all about Windows, right?

Or as one Microsoft executive told me, Jeffrey, exactly what part of fucking Windows is confusing you. He's trying to introduce a CLI. He's like, Windows, Jeffrey, Windows. Anyway, that was a painful period. Okay, the reality is the world is heterogeneous, right?

The world is a lot of Windows, but there's also a lot of open source Linux. And that services, services are just as important as machines and in a lot of cases, they're more important than the machines.

And guess what, when you're managing services, it really doesn't matter how that service is implemented, Windows or Linux. You still have to manage the service. But you're not logging into the machine that runs the service. You're here and you're managing that remote service, okay? So that is perhaps more important than managing individual machines.

And in reality, the cloud really does need much better programming and large support than PowerShell has right now. It's gotten better, but there's much more to do here. And that services require the control and bug fix timing open source provides.

So I don't know how many people are using WMF 5.1, okay? Now did you notice that WMF 5.1 had some cool new debugging features? Like you could debug desired state configuration resources for the first time, feasibly for the first time ever, like yay.

And did you notice that you can step into a function? Well, with 5.1, you can step into a function on a remote machine and have a remote debugging session there. Okay, now those were not part of the plan, right? But we've been focused, I've been focused in on Azure Stack,

and at some point we were just dying. We're dying because we didn't have these debugging capabilities. And I went to the team and I said, you got to stop. You got to deliver these things. And they're like, well, Jeffrey, we got the schedule, we got these priorities, and it just doesn't fit. It's like, I'm sorry if that sounded like a request.

You got to stop. I mean, we're dying here. I need this solved like right frickin' now. And it's not a negotiation, it's not an option, right? We got to solve this problem. And the point is that when you're a service, you know,

you need solutions and you will bring up your compiler and you bring up your editor, you'll solve your own problem. Like if I could have done that, we would have just done that. But at the time we couldn't because we were using Windows PowerShell. So open source means that you are empowered to solve your own stuff. Now, you don't want to create your own fork, your own branch. Well, actually you do for very short periods of time.

And then you want to do a PR and have them fix it and then get back on the main line. But when you're delivering something in production, you need the timing and the bug fix, you know, the control and bug fix timing that open source provides. So the conclusion when we thought about this was

we actually needed a new tool, right? That Windows PowerShell was not going to do it for us, okay? However, there's this thing we call the sacred vow, okay? The sacred vow was we as individual members of the PowerShell team stood out and said, we make a commitment to you.

We know you're very busy, your hair's on fire, and the last thing in the world you want to do is to stop and learn a new language, learn a new tool, PowerShell. But we asked you to make that change. We asked you to stop doing what you're doing and learn PowerShell. And in exchange, we would do everything in our power

to make sure it was the best investment you ever made, okay? So we're going to make it as powerful as we can. When a new problem came up, we're going to reuse PowerShell. I mean, how many times as a customer of Microsoft, Microsoft would get on some technology and I'd go tell my bosses, hey, we got to do this, this is super important.

And for, you know, a year and a half, two years, I'd seem like a smart guy. And then Microsoft would want to solve a new problem and they'd abandon that technology and pick up a new one and I looked like a jerk to my boss, right? And we said, we're not going to do that. When we have a new problem, we're going to figure out how to take the tool that we have and extend it to meet that new problem.

That is our sacred vow to you. So yes, it's just PowerShell. And here the key is we're dropping the Windows portion of that, okay? Oh, yay. So this really was kind of a hit refresh.

That's our new boss's great phrase, hit refresh moment, where when you hit refresh, you keep the things that are great and bring you and deliver you a path to the next 15, 20 years and then the stuff that don't, you leave behind, okay? So that's what we do.

We have a new mission. And the new mission for PowerShell is to enable and empower this digital transformation, right? So we want to be able to manage from any client, be able to manage any server or service running on any cloud, AWS, Google, Azure,

or on-premises running any hypervisor, VMware, Hyper-V, whatever, any storage stack, any networking. This is the tool that you can now finally bring your teams together, converge on a common tool set, and manage everything in your estate, right? I've been in this business a long time,

and I can't tell you how many times people have asked for this tool, and this is really for the first time the time where we've been able to actually deliver that. So great, sounds great, but a lot of people is like, yeah, but right now I'm using Windows PowerShell. What's that mean for it?

And the answer is Windows PowerShell is complete, okay? We're complete. It's going to be fully supported probably forever, right? Command.exe, still supported. It was deprecated I think in 2008, a long, long time ago. Command.exe was deprecated, still fully supported.

If it's used, it's supported. That's sort of the model. But we'll have no new feature development on Windows PowerShell. We'll do security fixes and customer blocking bug fixes only, and that all of our investment is going to go into this new PowerShell.

And because this new PowerShell needed to achieve this new mission, there were quite a few small breaking changes, and so we decided that if we just kept the name PowerShell.exe, that there would be enough little hiccups that would be jarring to people,

so we gave it a new executable name, pwsh. So here's a question everybody asks. So what's that mean? Am I screwed? Anybody feel screwed yet? Not yet, okay. So the answer is no, you're not screwed, right? As I said, Command.exe, we've had no changes in Command.exe

in over 20 years, right? And it's still used, right? I mean, we deprecated it a long time ago, and we don't use it because we don't deprecate it, we don't remove it because so many people use it. PowerShell version 1 was at least 20 times more powerful than Command.exe.

It really was. And since then, we've had five releases, 5.1 releases. Just think about the difference in language between what you're able to do in PowerShell versus Command.exe, right? And the coverage, both first-party and third-party, the consistency, the fact that we have universal remoting,

the ability to manage heterogeneous jobs and background activities. We have an inventing model. We have incredible security, like the best security out there. We've got desired state configuration, the ability to share information with the galleries. We have authoring and debugging tools.

We have classes. We have script analyzer and fantastic extensibility, okay? So in reality, I mean, I called this last year, and boy, I think I was absolutely right. Last year, I stood up here and I said, hey, in reality, the bulk of the innovation in PowerShell,

in the PowerShell ecosystem, has shifted from the PowerShell team to the community. And it's absolutely true. Just go up to the gallery. You'll see that. When you talk in the hallways, you find people that talked to somebody last night wrote PSGraph, right? It's domain-specific language that you can type and get graphical displays using PowerShell.

Fantastic stuff. So the community is really where this innovation is happening, and we've given the community the right extension points that they can continue with this 5.1 for a very long period of time. But we'll hear people say, hey, that's great.

Like, I'm in. Sounds good. Sounds like I'm covered on this Windows Server, the Windows PowerShell front. But this PowerShell version 6 front, man, you know, it's not there, right? Because there's a bunch of stuff that's not in PowerShell version 6. And the answer is that's right. You know, really, it's kind of PWSH v1. We chose PowerShell version 6.

So part of this is stuff that will never come in, right? That's our hit refresh moment. So things like workflow, you know, we went and talked to people, and we said, hey, are you using workflow? And the strong answer for the community was no. So that's not something we went forward with. If we're wrong on that, we're community-driven,

you'll tell us, and we'll change that. But we've been asking quite a bit now, and nobody's been saying, yeah, that was a critical thing. Same thing with snap-ins, right? Good Lord. We've tried to get rid of snap-ins since version 1. Actually, before version 1, we always hated that thing. And WMI, right? We're trying to shift everybody to SIM. So there's stuff that we don't think is ever coming back.

But then we're built upon .NET Core, right? And .NET Core is smaller than .NET Desktop. Well, when we first released Core PowerShell, we did it on .NET Core version 1. And they heard, you know, it was actually quite a big lift for us. That team heard that they had overly,

been overly aggressive in refactoring the frameworks. So in .NET Core version 2, they doubled the number of APIs. And now with the Windows compatibility pack, they have doubled that yet again. So, you know, we are kind of following the lead of the .NET community.

They are doing all their new stuff on Core. They're investing heavily. And at the beginning, when you make these kind of big shifts, sometimes there's a take-back. But when you're on the right technology and the right architectural thing, you pretty quickly make that up and then are able to accelerate even faster. And that's what we anticipate will happen with the .NET community.

Of course, you have PowerShell remoting. And PowerShell remoting works between these two environments. From PowerShell version 6, you can call PowerShell version 5. From PowerShell version 5, you can call PowerShell version 6. In fact, that's true all the way back down to PowerShell version 2

and will be true up to PowerShell version, you know, a billion, right? That's a contract that we make. So you have interoperability, which is to say, if you're running a PowerShell version 6 environment and there's something that is not there, you can remote to a machine and call it in PowerShell version 5.

I'll show you a little bit of a demo there. And if there's stuff that we're missing, please tell us about that. We prioritize. We are here to serve you. And also, if you go and say, hey, this product doesn't have PowerShell version 6 support, don't tell the PowerShell team about that. Go to that individual team and say, hey, Bucko, maybe you're not up on current events,

but the future here is PowerShell, not Windows PowerShell. We need you to get PowerShell version 6 support for your product. Your voices, right? Under Satya's model, Satya basically said, hey, get out of your office, go talk to customers, give them what they want.

Stop talking to guys like me and Racinovich who are saying, hey, the right thing to do is this. It still happens. But in reality, your voices are far stronger than our voices. So tell teams what you want. All right. Let's talk about PowerShell coverage.

Okay. Okay. So we have this model for how you get commandlets, right? So it's basically you get modules. Commandlets are available in module. That's how you ship and share them. You can import them and then run the commandlets, right?

So we'll get here all the modules. Notice I got SIM commandlets here. So let's import those. I'll import those modules, that module, and now those commandlets are available to me. So I can just say get sim class win32bios. Happy days. And we added auto module auto logging.

But in fact, that just simplifies this basic mechanics. Commandlets are in modules. You list the modules, you import a module, and then you run the commandlet. So now I'm gonna try and run get app locker policy and it fails.

It fails because that commandlet is not yet available on PowerShell version 6. So here I'm showing you a proof of concept prototype. We haven't figured out exactly how we'll ship this yet. But it's of this new module called R module. Okay, so I'll import R module. I'll get the commands from it.

And I've got copy R module, get R module, import R module. Get R module. That's sort of like get module, right? So R, maybe remote. So get R module, list available, computer name. I'll do this local machine. And so now what it's doing is it's behind the scenes creating a connection,

talking to that, and I'm getting the remote modules that are available. Remote modules, yeah. So now we've now made uniform this idea between local and remote modules. So now I'll say, okay, well, is that true? Let me import one of those things. I'll import R module app locker, right? I tried that.

That didn't work. And I'll do local host. And so what's this actually doing? And the answer is it's using implicit remoting, right? If you're not familiar with implicit remoting, it's this wonderful feature that allows us to connect via remote connection, go to that remote machine, harvest a set of cmdlets,

bring them over here, and create local proxies for those cmdlets here. And then when you invoke those local proxies, you have command completion, you have error checking, parameter checking, IntelliSense, etc. And when you execute it, it then runs, sends that to the remote run space,

executes there, and gets the results back here, okay? So remember, imported app locker, and now I've got all my app locker commands in this environment. And so when I run get app locker policy, voila, it works, okay? So remember, yeah, isn't that cool?

So let me go over that again. So I'm in PowerShell version 6, and boy, some stuff works, that's great. But some stuff's not there because they haven't ported it from Windows PowerShell to PowerShell. So now what I do is I use implicit remoting to make it show up in the PowerShell version 6 environment.

And when it runs, it uses remoting to do that. Okay, that's great. So now, getting that adapter, that doesn't work, okay? Well, it turns out that there's a whole set of things. If you recall, we really kind of broke the back of coverage with sim cmdlets.

Once we allowed the Windows team to write cmdlets in native code using sim, then we got fantastic coverage. Well, guess what? The sim cmdlets work just fine in PowerShell version 6. We got to get those teams to do their full test coverage and acknowledge that, but they do. So here, I'm going to find out, right, PowerShell version 6, I got 367 cmdlets.

That's not so good. But now what I'm going to do is I'm going to copy our module, and I'm going to say copy the compatible modules to this directory, v6-compat, okay? So what it's doing is it's running, makes a remote connection.

It, remote connection, it then looks for these sim modules, knows that they're compatible, and makes a copy of them, and also has a whitelist of additional modules that are compatible and copies them. And I went from 367 to 1853, okay?

So now, right, getting that adapter didn't work, but now when I run it, just works. Happy days. Okay, so that's pretty good. Now, I'll do get module list available. Shows you all the modules that I have, right?

These were all the things that came over as part of that sim module, compatible sim module. Now what I did was I went and just yesterday, I got a new set of cmdlets from Azure that support .NET Core.

The things I deleted, I brought back, my buddies from VMware, I got their cmdlets, I got the Google cmdlets, and I got the things in the gallery that explicitly say that they support .NET Core.

And now when I say get command, it's gonna take a while, because there's a large number, 9,400 cmdlets, okay? So 9,400 cmdlets that are now work in PowerShell version 6.

So pretty good days. So the point there was, yep, with PowerShell version 6, the initial set of cmdlets is smaller than you get with Windows PowerShell, but through third-party support and through, well, remote coverage, I didn't count many of those, that number's gonna grow rapidly.

So a lot of people ask, okay, great, I got Windows PowerShell, do I have to convert to PowerShell version 6? When do I convert? And the answer is, for you, if you're a user, do so when it makes sense for you, right? These things work side by side, so you can have them on all your machines together.

Certainly, if you're gonna be doing things from Linux or Mac OS, you're gonna wanna do that with PowerShell version 6, cuz that's your only choice. But some people might never switch. You might just say, hey, Windows PowerShell is it for me. That's fine. Now, if you are a cmdlet provider, however, that's a different story. If you're a cmdlet provider, what we want you to do is we want you to

compile your cmdlets against the .NET standard in the PowerShell standard library. And what that does is that then allows your cmdlets to work in both Windows PowerShell and PowerShell version 6, okay? One set of cmdlets work in both environments and work in Linux.

And for people writing scripts and modules, things that you write and share with others, put up in the gallery, we encourage you to support both. But whatever you do, we want you to declare which versions you support, right, and that's with the tag psedition underscore core, right?

Now, great, happy days. Now, people wanna know, great, what's in PowerShell version vNext? The answer is, I don't know. Seriously, I don't know. And the reason why is that with PowerShell v6,

over 50% of our PRs, our pull requests, came from the community, okay? So when you ask me what's in PowerShell version 6, I only know what things we're gonna invest in. I have no idea what the community's gonna invest in. So here's where we're doing all of our planning out in the open.

We're being very explicit about that. You can follow this link to find all the projects. Well, here, let's show you this. Is that a good idea? Yeah, so here, all the telemetry is all available.

So here's where it showed you the pull request created. Microsoft had 50.29, and the community had 49.71% of the pull requests. Here, what things we're investing in, we have this full list. Here are all the projects that we're working on, okay?

Now, to do a stack pop globally, these are the three things that Microsoft is investing in PowerShell, okay? Number one, cloud and service management. There should be no surprise there. Number two, programming in the large. And number three, community feedback, okay?

These are the three large buckets, and roughly, these are the priorities, okay? So with community feedback, guess what? Community has lots of feedback. We're gonna be able to fund a portion of that. You can fund as much of that as you'd like, right? You can say, hey, those idiots, they didn't do this feature. Just code it, baby.

Code it, do a PR, have a pull request, have a unit test. We'll accept those, and your code will be in PowerShell. By the way, that's a pretty amazing thing, right? Now, let's stop here a second and put this in perspective. If you contribute code to the PowerShell project, and it gets accepted, now all of a sudden, your code's gonna be used and installed on,

not millions, not tens of millions, but hundreds of millions of machines. How cool is that, okay? Now, a lot of people will sit there and they say, well, yeah, that's cool, but I'm not a C-sharp programmer,

you know, and this delegate, that's too complex. You do not have to be a hardcore developer to contribute to the project. And to show that, I'm gonna bring up Joey, who's gonna demonstrate this to you. And I'm telling you, everybody can participate in this ecosystem, and make it better, and then have your impact show the world.

What should we do? We found a couple error messages that we could fix up here. By the way, how many people are perfectly happy with the PowerShell error messages? One. This guy, wow, that's pretty awesome.

Not so much the rest. So, you don't have to be a C-sharp programmer to help us fix our error messages. Yeah, and really, I think it speaks to, oh, nobody can hear me. I think it speaks to the fact that there's a lot of progress to be made that I came up with what it is we wanted to improve in the last 15, 20 minutes.

So, you know, there's a ton of stuff out there. You really don't have to look that hard to find places where we can improve PowerShell. So, we do all of our development in GitHub? Did we find an error message? Yeah, here we are at the project here. So, we're gonna go into the source. Wait, did you find the error message? Oh, the error message that we want to break here. Okay, so this is a good one.

This doesn't look elevated. Can I use this guy? Yeah, go. So, this is gonna complain that, although we've got a little surprise on the update help front later today. Stick around for the lightning demos. Hey, well, he's finding the error message. How many people, raise your hand if you've never used get?

Oh, come on, somebody's got to never have used get. Is that true? You're too popular. Okay, you, come on, come here.

My friend, you are about to make the lives of everyone in this room better. Do you have your shortcut elevated by default? Yeah. Okay, that's the problem. Oh. The error message I want to fix is the one complaining about elevation. Oh, sorry. Here, do this one.

Is that, that'll give me the same thing? I just opened it from run. Here. Yeah, right there. This is not elevated. Update help. Or what's something else that needs elevation from PowerShell? Anybody? Start service, install module, there you go.

That would have worked, actually, install module. Okay, go for it. So it might be a little rough. Alright. Okay, fine, let's do this one. So this is an error message that is a block of red text.

One of the things that I would like to do is separate the error message from the mitigation of the error message so that when you're scanning down the page, you can see, oh, hey, I need to run this thing as administrator and not a whole bunch of gobbledygook about why we failed that is irrelevant to you when you're trying to get your job done. So what we're going to do is search for this error message in the repository,

and I'm actually going to have you take over here. So we're going to search for the command could not update help topics, blah, blah, blah, blah, blah. So just cut and paste from here. Cut and paste this guy. That's good enough. Copy. Okay, and alt tab over to edge. That one, there you go.

And just go ahead and go to the top and just search for that error message. Right there. Ta-da. See, here we got help errors dot res x, right? So this is the file where this thing's stored. All we have to do is jump into this file, select it. Wait, it's as easy as that. Find a crappy error message, search for it in our repository. So at this point, all we have to do is click the edit button here in the upper right-hand corner.

Oh, we're not in a branch here, so you got a tree. We changed something earlier, so this is not going to happen to you, but if you go to master here, it's the main branch that we're going to fork off of. So we edit the file, and now find that string again here in this file.

Control F. Next result? Okay, if we scroll to the bottom here, in the right scroll, sorry. Maybe do the control F from within this thing.

There we go. I think if we just scroll the file, we're going to see it pretty obvious here. Yeah, so here we've got, keep going, keep going.

Access is denied. Here we go. So, access is denied. The command could not update help topics for the PowerShell core, so let's go to where the mitigation is further to the right. So if you just scroll the way to the right here, we say to update these help topics. It'd be nice if we put a line break there, right? Make it more readable. So you're just going to go to this spot, just backspace, and add a line break.

All right? And then we actually, because of some wonkiness, we need to make sure to get rid of this white space here that cannot be indented if we want this to render properly. But other than that, that's it, right? So now if we scroll down to the bottom here, you'll see the only option that we have selected is create a new branch for this commit and start a pull request.

So you should, you know, maybe add right here at the top just a nice message that says, added a line break to update help error message. Jeffrey made me do this.

There you go. It's true. Yeah. It's all good. So what you're going to do is hit commit changes. And this is going to start a pull request. And then you can summarize your changes here in the pull request. This is a pretty lightweight PR, and we've got time, so we're just going to go ahead and go through.

But this PR checklist gives you everything that you need to do in order to make sure that the PR is good to go. And then at that point, you would hit create pull request. And there we go. We're making PowerShell better. All right. Give it up for Brad, the latest member of the PowerShell community team here. Thank you, Kelly. So indeed, you know, and there's just tons of opportunities like that.

Formatting, help messages, everybody can contribute to PowerShell. Now, in terms of cloud and service management, what we're going to focus in is basically helping people consume the cloud and the services.

So this gets back to that core mission. From any environment, be able to manage anything, swagger-based cmdlets. Swagger is a way, REST APIs are very popular, and swagger is a way of annotating your REST API to tell people how to use it. And the Azure SDK team has picked up support.

They were doing all the .NET, Go, Java, Python, somebody else, something else, five, anyway, five. And then we were doing the PowerShell swagger cmdlets. They have decided that they are going to officially support PowerShell, so they're going to generate all of that stuff.

And this will work for, you know, Azure cmdlets. It will work for any REST API that annotates stuff through swagger. We think that's going to be very important. Production quality gallery. Right now our gallery is great, but we need to make it more production quality. Very highly available, low latency access to everywhere.

So basically when I go to my friends at VMware and I say, hey, you should put all your stuff in the gallery, I need to be able to look at them with a head and heart in the right place and say, your customers will always be able to get your code when they need to as quickly as possible. And so we've got some improvements to make there. We are going to do those.

And has anybody seen Cloud Shell? Yeah, so Cloud Shell, if you haven't seen Cloud Shell. I'll just quickly, this is the Azure portal.

It's nice and zen-like. No, there it is. And notice here, right, there's our prompt, Cloud Shell. And you click it and you get a command line interface right here, right?

And this can be Bash or PowerShell. And even within Bash you can run PowerShell. You get the Linux version of PowerShell in there. Pretty awesome stuff. Now, the other thing we're going to do in this area is to drive features. So a lot of features that are in Azure are based upon PowerShell.

Update management. So if you have a VM in Azure, we'll tell you when it needs to be patched. We'll do the patching for you. That's all using PowerShell. Inventory, that's all using desired state configuration. We can tell you what systems on both Linux and Windows. The inventory of things, we can tell you when they change with change tracking.

Of course, we've got Azure automation, configuration management, which is desired state configuration in the cloud. The Azure security baselines, those are all using desired state configuration. In fact, for this, we generated the new, it's using the new desired state configuration LCM.

So we have a native code version of that that's extremely lightweight and is used for this. And we have what, over 2.5 million? Over 2.5 million instances of this running. So this has been incredibly successful. And of course, things like Azure functions where you can do serverless computing

and it supports PowerShell as well. Again, so these are the two big themes. Help people consume the cloud, help build the cloud. And this is a virtual machine in Azure and you see things like, basically most of the stuff under operations is all PowerShell

and desired state configuration, right? Update management, inventory change tracking. Now, where I'm spending a lot of my time these days is Azure Stack. And with that comes about a new set of challenges that really kind of highlight an area of growth needed for PowerShell.

And that's the area of programming in the large, okay? Now, I mean, how many people are familiar with Azure Stack? Okay, so some, not everybody. I'll give you a quick tutorial about Azure Stack, what it is. It's this first product in a new category, this hybrid cloud platform.

We basically are taking Azure, Azure, and running it on servers in your data center. Wow, okay? Now, it delivers an appliance experience, okay? An appliance experience that gives you self-service, IaaS, PaaS, and cloud. And it's not a DIY thing, right?

Not a bunch of raw hardware and best of luck, here's a rabbit's foot, you're gonna need it. No, no, no. You buy this, you pick, it's very simple. You pick a vendor, you pick a size. This vendor, four servers. That vendor, 12 servers. This server, 16, whatever. And then they roll it in and then they install it for you, 24 hours later, you're using it.

You get a portal, it is the Azure portal. But it's pointing to your servers, not our public cloud, okay? So it's an appliance experience. Now, it has to be consistent with Azure, right? That's the whole value proposition. So I can allow nothing that interferes with updating that every single month, okay?

And it's fully, the business model is dependent upon your success. How much does Azure Stack cost? And the answer is zero, zero, zero. It costs you nothing. Now, when you use it, then you pay based upon how much you use. It's exactly the Azure business model.

How much does Azure cost you? I don't use it. Then it costs you nothing. I use it a lot. Cost you a bunch. Same model with Azure Stack. You only pay for what you use, okay? Well, this is fantastic because what that means is, I am like hyper focused on making you successful, right? If I give you a crappy error message and you're like, oh, what do I do with that?

You're not using my product, right? So I have a great incentive to make it useful. These are the Azure Stack internals. There's gonna be a test on this, so. Now, here's the thing. So first off, you know, iWash, like good heavens, there's a lot of stuff going on here. This is actually a simplified diagram of what's going on.

In fact, there's a lot more going on. And most of these components are continuously available or highly available. Now, what that means is that there are not just one instance, but there are at least two and sometimes three and sometimes more than that instances of these components.

So if something fails, your service keeps going, okay? So, pretty complicated system. Now, here's how this works, right? We have scale units. Those scale units can have four to 16 servers. You always get three switches in each of these racks. There's a base motherboard controller switch

to talk to all the base motherboard controllers to do like, you know, IPMI. Then there's two topper rack switches. Remember I mentioned redundancy? Those have to get configured. You can have multiple of these scale units. That comes later in these years. And that's Azure Stack. And then we integrate that into your environment, right?

So there's the physical integration, but then it has to be integrated into your identity systems, either Active Directory or AAD, all your data center monitoring and management systems and the border devices, all the networking and the BGP controls, okay? So the point is, pretty complicated system.

Now, the point I'm really making here is, oh, wait, it gets better. We manage the entire life cycle of this Azure Stack. I mean the entire life cycle. Again, my number one mission is to reduce the friction and time from when an innovation happens in Azure to the time it's running in your data centers, okay?

So what that means is I control everything and make sure nothing gets in that way, okay? So we do the deployment. We do the provisioning. We do all the configuration. We validate these systems. We do the monitoring. We do the diagnostics. If things will fail, we have an automated process

for doing the field replacement recovery of systems. We patch and update these every single month. We support business continuity, backup and restore, and we entirely secure this thing. If you haven't seen our security, it is phenomenal. Lee Holmes and the team just did a fantastic job

securing Azure Stack. Now, why am I going on and on about Azure Stack? Like, who cares? Jeffrey, you're busy. I don't care. Here's why you care. Azure Stack runs on PowerShell 100%. I have over 250,000 lines of code of PowerShell

and desired state configuration running Azure Stack. It's not the best PowerShell code, but I got a lot of it. It's not just the creation and the provisioning. It's the production system. When you create a VM on Azure Stack,

there are over 400, on average, of 472 PowerShell cmdlets that get called to create a VM in Azure Stack. Jia was absolutely central to the design of our security subsystem, right? This is what allows us. Basically, we took a very modern assume-breach mentality

so that if you breach one section, it gives you nothing. It doesn't let you own the rest of the system. Using Jia gave us this compartmentalization. We have logging and transcripts for everything. And Jia's core to support. With Azure Stack, here's the deal. I'm never giving you the admin password. Full stop. Don't ask. You're never getting it.

I give you the admin password, I love you, but you're going to screw it up. So I can't allow that. So you don't get the admin password. But there are times when you need to do admin things. So guess what we did? We used Jia. We created a Jia endpoint that says, hey, here are the things that you can do. If ever support needs to do something outside of that,

then we have something where we can get admin privileges. This requires two keys. Microsoft has a key, you have a key, and that will unlock an admin account where everything is logged and transcribed, et cetera. Anyway, this incredible security system only enabled because of PowerShell and Jia.

I saw some people here are going to give some Jia talks. You should go check those out. It's an amazing capability. I want to give you a step back here and give you a little bit of the history here. Prior to Azure Stack, there's something called Cloud Platform Solution. And this was a purely PowerShell-based deployment. And when we went to do the next iteration of that design,

I said, hey, it was all PowerShell, but now we've got to use Desired State Configuration. And the team told me, I hate PowerShell. Really? Okay, tell me more. What do you mean you hate PowerShell? As we drilled in, we realized that where we were,

and this was with PowerShell version 4, we were not giving these developers the things that they needed to succeed, okay? Because they were doing programming in the large, okay? So, as developers, they had a tool set that they were used to, Visual Studio. They needed Visual Studio. They were used to defining contracts. As I'm going to produce something,

I'm going to consume code from you, and from you, I want to express that contract in terms of a class. We were doing it in scripts, script signatures. There were tools, I remember at some point the develop manager almost hit me. I thought he really was when I was buying coffee. He's like, you cost me three days on my schedule. I was like, me? How did I cost you three days on your schedule?

And he said, basically, somebody had checked in some bad PowerShell, and they weren't able to find out about it for three days. He says, why isn't there a lint tool like any other proper language? I was like, that's a good idea. And they didn't have the ability to unit test things, okay? So, these were things that were missing,

and why they did not feel that they could be successful as developers using PowerShell. And that whole improving programming large was one of the big focuses for PowerShell version 5, where we did Visual Studio and Visual Studio code support. We added classes, the new language mode. We added script analyzer.

We embraced the PowerShell, sorry, the Pester unit test framework, and then we improved all these things, right? The debugability, the authoring of DSC, debugging, jobs, et cetera, went a large way, and that's what's really enabled us to use PowerShell in Azure Stack.

I mentioned to you it's pretty complex, and here's the point. We deliver this with an appliance experience, right? The degree to which you're messing around with that complexity means you're not using the system. So, we try and do this like a car, right? You drive a car, everything's fine. You're not, like, looking at all the details.

A light comes on, says, put oil in. You put oil in, you keep driving. A light comes on, says, put gas in. You put gas in, you keep going. That's the model for Azure Stack. Comes in, gets deployed, you use it. At some point, a light comes on and says, replace this disk drive. Replace this disk drive, you keep using it. Another point, a light comes on and says, replace this server.

You replace that server, you keep going. The point I'm making is that that, we're able to deliver that very simple environment because of the hyper complexity of the previous environment, okay? And the hyper complexity, the fact that we have multiple levels of resilience and fault tolerance, the fact that we've got all this monitoring, et cetera,

is the things that allow us to give you a very simple experience. Well, guess what, guys? That's your job as well. Your job is to help empower other people, empower them by giving them very simple abstractions and tools that they can use. And in order for that to work, you need to do the heavy lifting

and to make a simple world for them. Now, challenges that we've had in Azure Stack. Number one, error handling. Error handling is a bit of a mess. Let me give you, in this, I'm going to propose something that we do. Right now, we don't have a prototype for this, but I'm going to kind of walk you through the problem

and what I think the solution is. Now, as you know, we've always had this distinction between terminating and non-terminating errors, okay? And it has served us very well. However, not always. Let's see if I got this right.

Okay, so I have this module called error. Error has two cmdlets, test non-terminating error and test terminating error, that's pretty good. So when I test non-terminating error, you'll see, I gotta make this smaller. You'll see that I get a bunch of errors.

In fact, let me show you what that actually looks like. Just so you see the code. So basically, it's stop process. In Windows, if you stop something that's an odd, an ID that's odd, they don't exist.

So anyway, so I stop these three things. And then the terminating error, I do exactly the same thing, but I say, error action stop, okay? So I ran that, I got three errors, okay? So now what I wanna do is I'll say, hey, I wanna run this again. I want the error action to be silently continue, and

I wanna grab everything and put it into a variable failed. And this is the kind of code that you write. Cuz then what you can do is you can say for each error in failed, remember we collected everything. We're gonna write host foreground yellow, fail, and we grab the error, the target. And so we had three errors, and I'm able to do that, okay?

So that is the coding pattern you have for non-terminating errors. Now let's consider the coding pattern for terminating errors, cuz it's different. So a terminating error, remember, does exactly the same thing, but when you get an error, it stops, okay?

So test terminating error, we run that, and we just get one error. We didn't get three, we got one, cuz it's a terminating error. So now if you wanna do the same thing and say, hey, fail ID and give the ID number, here's the code you have to write. So first you gotta put it in a try catch, and

then error is dollar sign under bar, gives you the error. And the rest of it looks the same. So now I do this, yeah, great, what did I do there? Louder, what?

There you go, yes, thank you, do, there you go. It takes a community, thank you very much. It's so true, I told you I'm a deeply flawed person. So there you go, but now I have these two different coding patterns, right?

And now here's the question, okay, fine, that's the deal, and there's a reason why we did that. Now, what you can do is you can do things like, hey, I'm gonna go and I will set dollar sign PS default parameter values. I'll say I want error action to be stopped for everybody.

I'll execute that, and now, if I do this, notice I have only one error, right? And now, here I can say, I'm gonna say non-terminating error, and this code should work, let's hope it works, and it does, okay?

So by adding that default parameter value, that works, okay, clear that? Okay, but now I'm gonna import another module, error2, and I have something that's called test error. Which code should I write?

I don't know, I don't know. It doesn't tell you whether it's terminating or non-terminating. In fact, some cmdlets can have both terminating errors and non-terminating errors, right? So, well, let's just run it, okay? And yeah, well, it looks like it gave me a bunch of the errors, that looks like it's a non-terminating error, and I've lost my mouse.

Seriously? There we go. Okay, so now I'll go and I'll do that trick again, okay?

Well, say default parameter values stop and run it again, and it didn't work. I don't know why. And the answer is that error, that module, let's take a look at it, psedit, error2, error, okay,

test error, it calls test non-terminating error, okay? And what happened, here's the heart of it, Is that each module has its own scope. And so when I did this code to say, these ps default parameter values,

it did not apply to the scope of that module. And if I wanted to apply that scope module, and by the way, this is advanced PowerShell, here's how you do that. $m equals get module error2, and then ampersand $m, my gosh. So what this says is run ampersand run $m in a module, a script block.

So it goes into the scope of that script block and runs arbitrary code. And here, the code is set the error action. And now when I run it, it does what I wanted. Man, that's a pain in the ass, like not good.

So imagine instead we had this. Imagine if we had something called ps on error. With ps on error, you call it with a non-terminating thing, that this script block would run every time you get a terminating or non-terminating error. So in this case, it would run three times.

When I call a terminating error, I have exactly the same code, but it'll only run once. And this, you don't have to know whether it's gonna produce terminating or non-terminating. You just call it, and the right thing happens. Now with that, you ran three errors. But what if you didn't want that, right?

Well, we have a way to deal with that. And the answer is, you do exactly the same thing, but you add a break. So if you do that, this, the first time it gets called, writes out the error message, and then terminates things. This would just do one. So you have a uniform way to handle error handling.

Anyway, so that's something we're gonna be looking at. And it's one of those things like you say, it's kinda cool, but I have other ways to deal with it. When you have over 250,000 lines of code, man, you want some of this uniformity. By the way, the other thing with that is that ability to have control over the modules, PS dollar sign error variable being different,

default parameter value being different for every module is a real problem in programming in the large. So we want better control over module and nested modules. PS breakpoint, PS breakpoint, we want to be able to break on an error, right? So right now there's no way to break on an error and then capture the state.

So what we're trying to do is to rewrite all of our script blocks associated with remoting so that when I, okay, so now think about this, right? You saw that complex hideous diagram, and I'm gonna patch that, right? So I got like a gazillion hosts, a gazillion VMs, and I'm gonna run script blocks on all of them, right?

Well, what happens when something goes wrong, right? Bring out that rabbit's foot. No, so what we wanna do is we wanna say, hey, I wanna overwrite invoke command, take the script block, and basically produce a mini dump anytime there's an error. But I can't do that because I cannot catch when you have a failure.

I can only catch at the top of the stack, not at the bottom of the stack. So that's a big issue for us. Classes, I cannot tell you how much I love classes. They're exactly the right tool. The new programming language mode is exactly the right tool for programming in large. But I can't use them to create my own cmdlets, and

I can't use them to create domain-specific languages, which we'd like to be able to do. And with Azure Stack, man, I just need to be able to fix whatever I need whenever I need it. I really need that open source capability. So what about, no, so that's the heart of it. This is where we're gonna focus in on programming in large,

these sort of areas. Now, as we do this, a lot of people have been asking us about things like, hey, what about this Windows services subsystem for Linux? Does that mean PowerShell's dead? And here's the real answer. The answer is, when Satya came on board, he said, hey, get out of your offices and go talk to customers and give them what they want.

Now, part of that is we are breaking down a lot of the bureaucracy that we had in the past, and teams are becoming more agile. Part of that bureaucracy, in fact, bulk of that, over by ten or ten more. Great, okay, a large portion of that was bad stuff,

is good to get rid of that bureaucracy. Some of it, you could argue, was good, but it's all gone and gone. Now we have empowered teams that joke about there's a fine line between agile and random. So every team's out talking to customers, figuring out the right thing to do, and going. And so here's the reality. The reality is, it's kind of a messy world, but that's okay, really it is.

So yeah, this Windows service is for Linux, now you have Bash on Windows. So what's that all about, why do we do that? And the answer is, because you go down to the valley and you see all these open source developers, people writing code for Linux servers on a Mac.

Not if you've checked the Mac lately, but that is a really expensive, really outdated piece of hardware. And we have these amazing machines. So hey, if we could just allow people to write their open source software on our desktops, that would be a compelling value proposition. And guess what, it is, they love it.

People are like, man, I can spend like half the price, get a much better machine, some of these Lenovo's. Some of you had a Lenovo here, it had 64 gigabytes of RAM, my gosh. Anyway, so that's what that's all about. Help open source developers do their development on Windows, that's what that's about.

And here's the thing, that team was closely associated with the team that owned the console, the console that had not been invested in over 20 years. And now the console is reinvigorated, right? We're getting things like transparency, we're getting, I don't know if you've seen the latest insider build has tabbed switches,

tabs in the console, so that's been great. This is also bringing us native curl, native tar, fantastic stuff. And just driving Microsoft to a more general command line culture, so that's fantastic. And then a lot of people have been asking me about these Python-based Azure CLI.

Here's the reality there, here's the back story. The back story was, Guthrie would go talk to people and say, hey, why aren't you using more Azure? And they'd say, cuz your Linux support sucks. We had these Azure CLI cmdlets that were written in, I guess, Node.js, and they're just not up to the task. So Guthrie basically personally PM'd this thing.

It was a time well over a year out from when PowerShell would be available on Linux. We didn't even know that it would be a year, it could have been longer. And so we personally PM'd them. Now the fact that it's written in Python means nothing, could have been written in Go. But he needed to get that ASAP, and that's what drove that. Now here's the reality is, he did that and did two things at once.

One was to drive the swagger-based SDK approach. So now when the Azure team produces a REST API, we get .NET, Python, Go, Java, Node.js, all first class citizens. And as I mentioned, now PowerShell as well. So that's a huge benefit.

And as Guthrie was personally PMing them, he went and drove like the abstractions. He's like, these abstractions make no sense whatsoever. And so then he went and drove a much better set of abstractions. And those abstractions are now coming to the PowerShell environment, so happy days. So as I mentioned, this is all kind of a side effect of the common engineering

criteria having been removed, but it's all good. So here's the net of this. And we started this from the very beginning. We always said, listen, the world is messy. The world always has been messy, the world is messy, the world always will be messy, right?

And PowerShell is the glue that pulls together this messy world. By the way, why is the world messy? Unless you give up and walk away from everything that you have, you got legacy stuff. And unless you say I'm no longer gonna innovate, you have people who innovate. And innovators kind of break the rules, they go their own way,

they produce messiness, right? So that's why the world's always messy, right? And if some part of it becomes less messy, it doesn't mean the whole becomes less messy, right? In general, it just gets messier and messier. So that's what we're all about. We're all about, all right, before the predictions, we're all about trying to help you solve that problem.

And I'll tell you, let me tell you a story. I was a young buck engineer at digital. And I was doing this managing product around distributed remote user management. And working our butts off on this project. And at some point, I stepped back and I said, hey, wait a second. The only reason why I'm doing this, the reason why I have a job is cuz that team over there screwed up.

Like as soon as they stopped screwing up, I mean, that's what management is, right? Managing is compensating for the screw ups of other teams. As soon as that team stops screwing up, I'm gonna be out of a career. I'm now a technical fellow at Microsoft 30 plus years later. Turns out there's a growth business in messiness.

So it's a messy world, PowerShell has a firm place. So now, predictions. These are my personal predictions. These come true, great. If they don't, don't hold me to it. Number one, PowerShell Core, I predict that will be renamed to PowerShell.

PowerShell Core has this convention, it's like caveat to it. Sends the wrong message. The message is PowerShell is our future, and I think we'll change the name to reflect that. We're gonna talk to you folks, give us some feedback, but I think that's what's gonna happen. SHPS, SHPS is, I don't even know what the heck SHPS stands for.

Simple Hierarchies in PowerShell. It's very important to pronounce the P, SHPS. SHPS is a way you use, it's very important, it's a way you can use PowerShell classes to create new hierarchies.

And that's what you're getting with the Azure Drive, and we're seeing a bunch of people in the community that are now taking this and generating fantastic new things. In fact, Ravi over at Dell produced one for the PowerShell European Conference. And so you mount the European Conference schedule as a drive and you can CD into day one, do a dir.

And so I believe that SHPS is gonna reinvigorate namespaces. Namespaces were always awesome, but they were just so hard to develop. We have more work to do on SHPS, but I think that that is gonna reinvigorate namespaces. People are gonna rediscover why namespaces are wonderful.

I mentioned to you these Swaggerbase cmdlets. I think as the world moves to microservices, as the world moves to services exposed through REST APIs. By the way, why is everyone exposing things through REST APIs? Here's a simple question. Hey, is everybody gonna program in Go?

No. Is nobody gonna program in Go? No. Okay, what about Python? Same answer. What about .NET? Same answer. What about this? Doing things in REST, exposing your APIs via REST means it's easier to access the widest range of languages and

runtimes and client environments. You can invoke a REST API from Python on Windows, from Go on Mac, from .NET on Linux. So it gives you the maximal addressability. Then annotating those REST APIs with Swagger gives you those things. And I think this will emerge as one of the most dominant

ways to generate cmdlets. Cloud Shell, the thing I showed you earlier, I predict that this will be shipped as a Linux-only environment. So Cloud Shell, you go up to the Azure portal, you say, hey, I'd like to manage Azure. We give you an environment.

And in the past, we gave you Windows running PowerShell and Linux running Bash. And then we went and said, well, actually PowerShell can be anywhere, and I think Bash can be anywhere. And what we found was, boy, we have two different teams producing the Windows and the Linux image. And then we're telling people we're trying to coordinate, and

there's a whole bunch of extra work. And then the startup times are really not so good. But we're sort of fixing a bunch of that stuff. But what really kind of looked at and said, wait, this doesn't make any sense, is that there are a whole suite of Azure-oriented tools that are being generated on Linux, like Terraform, for which the Windows support is either not there or

lags greatly. And so what we don't wanna do is to have an environment where, hey, this set of tools is available here and that set of tools is available there. Having one image, Linux, I think unifies that, aligns everything and makes it simple. Now the reason why we think this can be successful is because

when you're in this environment, you're interacting with PowerShell. You're interacting with the Azure commandlets. You're not managing that machine. That machine could be an AS 400, it doesn't matter. You don't add users to that. You don't manage services to that. You don't manage processes to that. That environment has exactly one function.

Run the tools to manage Azure. And in that regard, we think in the end when we pull in that thread, we'll do Linux only. Cuz it gives us most efficiency and gives us a common set of tools that can be up to date constantly. We have this desired state, and I'm not sure this is a prediction as

much as we're already doing it. Desired state configuration. We have a desired state configuration, these local configuration manager. And where's Kenneth? I told Kenneth we'd never, ever, ever have more than one of those things. He kept coming back, he said, we need more than one, we need more than one. I said, well, you can't have more than one until you prove these

design problems. And he came back with the team and solved them. So now we can have more than one of these. And so basically what you're gonna have is you're gonna have multiple LCMs with different implementation technologies. We have one in native code, very, very lightweight, very fast,

fantastic, used in all the security stuff. Then at some point you'll be able to say, hey, I think I'd like to write some of these things, these providers in .NET. Have a .NET core and then a full .NET one. Having multiple LCMs, they can be on different schedules. So in fact, maybe you'll have one that's in a process that gets updated

every couple minutes, whereas one for the system updates every half an hour or so. So I think that's gonna work out. I predict that at some point the Linux distributions will look at what's going on in PowerShell and decide to include it in their distributions. Won't that be fun?

And there's this term in the development world called a full stack developer. I believe in the IT world, we're gonna have a corresponding thing, and that's what I call the cross stack developer. Cross stack developer, full stack developers are very in fashion these days. They make a lot of money and they're sought after quite vigorously by companies.

A lot of competition for these full stack developers. I think exactly the same thing's gonna happen to IT for cross stack IT. Cross stack IT are those people that are able to manage the entire stacks. You got Windows, you got Linux, you got this service, you got AWS,

you got Google, you have Azure, doesn't matter, I can manage that for you. I think that is gonna be an incredible skill. How do you do that? Not by being an expert at all those things. You're gonna become an expert at learning, you're gonna become an expert at learning, learning, engaging the community, that's how that works.

So I think that's gonna become very, very popular. And lastly, we do not intend, Microsoft is not gonna invest in full PowerShell running on, sorry, PowerShell version 6 running on full .NET, but we're open source.

And so anybody in this room can decide, hey, I think that's a good idea. And I predict somebody here will do that, not sure where it'll go, but. Now with that, here's what I wanted to say. Digital transformation is gonna change everything, and it's automation that enables digital transformation.

I mentioned to you that it's 2018, PowerShell's never been more important, but here's the real story. It's 2018, and you have never been more important. You've been never more important to your customers, to your companies, to your community. So what's in PowerShell version next?

I don't know, 50% of it's gonna come from people like you in the room, okay? So you're gonna find the new future. So lean in, reach out, meet people. This is the greatest opportunity of this conference, is to meet the people sitting next to you. Build stuff and make sure you publish it so other people can benefit from it.

And with that, I think we have some time for questions. Nope. Oh, we don't. Did I go long? Jeffrey Snover, everybody. Okay.