 Good morning and welcome to a new episode off the Visual Studio Office hours. I'm your host for the next hour. My name is Matt Christensen and today we're talking about Visual Studio Coatspaces. So that's a new and very exciting thing that we've been working on on the Visual Studio team for quite a while. With me, I've got two of the lead PMs for the project, Nick Malner and Anthony Kenkeliozzi. And so I was hoping that you two gentlemen could start by introducing yourself and what it is exactly that you're doing on Coatspaces. So Nick, if you will begin. Sure, hi everyone. My name is Nick Malner. As Matt mentioned, I'm a PM on the Coatspaces team. I work from home and in Austin, Texas. I was one of the original PMs on the Coatspaces team and I was involved with the public preview launch that we did back at Ignite in November for Coatspaces that are Linux based and that use VS Code and the web editor. And I kind of have my fingers in lots of Coatspaces pies. So I'm involved in kind of Coatspaces in all shapes and forms. All right, and Anthony. So Nick, it used to be original that you work from home. Now we all work from home, which is why Coatspaces is becoming so awesome. I'm Anthony Kenkeliozzi and I'm the group program manager for VS Core. I work on a number of shared features across the platform of the IDE. Basically, if it touches every project system in the IDE or every project type that you use, it probably falls on the core team. So our team has been super busy enabling the IDE and the features of the IDE to kind of be connected to and driven by the backend of a Visual Studio Coatspace. It's been pretty excited to see the progress there. Awesome, thank you. So I think I wanna start with you, Nick, because my understanding of Coatspaces is that it's a service in the cloud. And that's what you're working on. And Anthony works on the part of Visual Studio that can connect to that service in the cloud. And so maybe you can start by explaining what is Coatspaces from a service perspective and then we can take it from there. That sounds fantastic, Mads. Yeah, the beginning is usually the best place to start. So really Coatspaces is an Azure service that's oriented towards provisioning the resources that a developer needs to do development, right? So it gives you your compute, your CPU and your RAM and the storage all up in the cloud. And we do that in such a way that when we create that compute for you, right? When we create this environment, what we call a Coatspace for you, we make the whole thing very easy to get up and running. So you can click a button either on our portal, which is at online.visualstudio.com. Visual Studio Online was the old name. If you've heard of Visual Studio Online and Coatspaces is new for you, it's because we changed the name and that URL will get updated, but it is still the old URL online at visualstudio.com. Or we have GitHub integration now in private preview. Either way, you're gonna go click a button at one of those two places. We're gonna point, you're gonna point us to one of your repos and we're gonna spin up everything that you need in the cloud in about 30 seconds. So that way you can edit, run, do everything that you want to with your code from wherever you are, because you can use either VS Code on the desktop, you can use VS IDE, VS 2019 on the desktop, or you can use a browser and have nothing installed on your machine. So maybe you're sitting on like a Chromebook somewhere or some thin laptop, maybe you're at your mother-in-laws and she has an AOL connection from the CD, and that's all you have access to, but you gotta get that PR in, you can do that. Does it work from an iPad? It does work from an iPad actually, that's a very hotly requested feature, and so it's there. I may have known about that feature request. I'm glad that it landed. So, okay, so that's the service side of things. And then, so you mentioned that there are three things that can connect to it. There's the VS Code, there's Visual Studio, the IDE, and then there's a web client, a browser basically. So, Anthony, do they all like connect in the same way? Are we getting sort of the same experience? Like is it just three different clients and that more could be coming? Like what is the role of the client against the service? Yeah, great question, Mads. So in some ways they all kind of have the same core kind of promises of being able to kind of connect to your code running inside of the cloud. So that part of it is shared no matter which client you're connecting from. Browsing code, core editing of the code, all that's available no matter which client you're connecting from. All of your core Git operations, a lot of these fundamentals are shared across many of the clients. There are differences that you're gonna see depending on which client you're using. A lot of that kind of comes down to what the IDE versus VS Code are really best at and where they kind of shine. So if you take the Visual Studio IDE, for example, that is a kind of world-class app development experience for .NET and C++ developers. I mean, those customers absolutely love the integrated debugging experience, the unit testing experience that you get there, the rich editing and tele-sense, all the richness that comes from a single IDE, that's why developers love IDEs because it all kind of comes together packaged into one deal. And it's been really tuned and optimized for those kinds of workloads around .NET and C++. And so in those places, the IDE is really gonna shine because it's able to light up a lot of the functionality that just comes right with Visual Studio that makes the Visual Studio so great. Now, Visual Studio Code, on the other hand, has a lot of breadth in terms of being able to reach many different kinds of languages, whether it is front-end web development, Python, Node.js, and a number of other languages that you can kind of reach breadth-wise through extensions that you can plug into VS Code. And so while Visual Studio and VS Code have extensions as well, VS Code really can scale up quite broadly with its ecosystem that's available in VS Code that's also available from within the browser experience. Okay, that was a very thorough answer, thank you. Okay, so we have these clients connecting. So let's say that I'm a developer and I'm working at a company and I wanna try out code spaces. So my source code has to then live in that service and code spaces, right? It's GitHub, it might be on GitHub and it's being cloned into the code space. And so when Visual Studio or VS Code wherever connects to it, everything is happening in the cloud, right? So the source code is in the cloud, the compute to run the compiler and the testing and whatever all the debugging and all this sort of stuff happens in the cloud. Is that right, Nick? Yeah, you got it exactly right, Matt. I think that kind of the easiest analogy or maybe mental model to keep in your head is to think about how we work with databases. Because databases have always been about remote development, right? You open up whatever tool, maybe it's SQL Server Management Studio or whatever tool it is that you're gonna use to work on a database. And what is the first question that asks you? Where is the database? What is the connection string, right? And now maybe it's running local, right? And you're gonna put in some connection string that somewhere in there says local host or 127.0.0.1, right? You're gonna put in something like that. But you're connecting to this thing. And like I said, it could be local host or it's up in the cloud. And then you type in your query or whatever you hit execute and that query everybody understands gets shipped up to wherever the database is. The database runs the result and sends back the data grid or whatever it is that you're gonna look at. Codespaces is bringing that model to the rest of developers. So when I do a control shift B to do a build, that's a command that goes up to the server and the build happens in the cloud and then the results are sent back. Maybe you have some warnings or errors or whatever, right? When I do a control space to prompt IntelliSense, the listing of things that comes down that's coming from the cloud. So that has a few really nice properties. One, it means that you can connect to it from whatever tool you want from whatever place you want like what we've already talked about and same goes for the database analogy. But it also means that my local machine is no longer competing for resources with my editor. All right, like I'm a PM now, right? So I have a lot of outlook running and PowerPoint decks and Spotify running and all of these things, right? And then I hit build and sometimes my machine grabs to a halt, not anymore because all of that processing has been pushed up to the cloud. All right, so that means that my machine is no longer doing the heavy lifting. So if I had a Chromebook, I was about to say a netbook. Remember netbooks back in the day, they were like the thing? Then this would totally work with like a little powered machine like this, Anthony. Yeah, I was gonna add to that that absolutely I love the analogy of the database and kind of connecting to kind of all of that remote compute and horsepower. But I think it's also worth mentioning some of the kind of unique advantages that we have in this model of being a native running client like Visual Studio Code or the IDE connecting to one of those databases. And that's kind of a lot of one of the questions that we'll often get is how do I do a latency? And having a native client actually gives us the ability to kind of merge a little bit of the best of both worlds where we're actually able to kind of manage a cache and a buffer of typing as you're typing and editing in the editor and then send that cache over to the code space. It's then processing that information, updating it on the backend and then responding to it. And so together with that backend processing and the remote cache, we can actually give users a very responsive low latency native feeling user experience while still working in a remote connected world. All right. So that latency, I mean, there has to be a latency then I guess, right? Because there has to. What is sort of the consequence or the cost of running sort of those things in the cloud which could be many miles from where your internet connection is, Nick? Matt, you are right. There is still latency. Unfortunately, we haven't fixed physics yet. So we're keeping on working on that in the R&D department. No, I mean, as with all things performance, there's a trade-off that needs to be made. So what we find is for people who have done remote development in the past, maybe they would turn to using something like remote desktop or VDI, right? And that is a very kind of, it can be a very bandwidth heavy style of communication, or you're passing literally bitmap images back and forth. With something like code spaces and the fact that you're connecting through the editor as Anthony was mentioning, we have the benefit of all that we really need to pass around on the wire is the context that's required for you to do software development, which happens to be actually quite small, right? Developers are working with text-based documents, which we know compress well, so we can ship them around the net very fast. We're just sending over the command that we need to do to do a build, just sending over the list. It's these very highly compressible assets that actually move around pretty quickly in terms of latency. Plus, we have the Azure building on Azure, right? And so as a public preview service right now, we're only in four regions, but they're pretty evenly spaced around the globe. And so I actually, to test things, I'll sometimes connect to the furthest data center that we have from my home, which is in Southeast Asia. And admittedly, I can tell a little bit of a lag when I'm connecting to the farthest data point, so the farthest region, sorry. When I connect to one of the two that are closer to me, it feels like local. And actually, you may find this hard to believe. Many of our users say that it feels faster than local. And this is the reason why, because that machine up in the cloud that's running all of your compute for you is dedicated to just that one thing that VS or VS code is doing for you. So you don't have noisy neighbor problems like with Spotify kind of taking over. Also, you happen to be on cloud scale hardware, really high end hardware with high IOPS on your disk. It's an SSD, you may not have that. And the bandwidth is screaming compared to anything that you have at home or even at most corporate offices. Yeah, that's a really good point. So the whole competition for your resources locally kind of disappears, it evaporates here in this model, right? Because your machine doesn't do anything. So I can have, I assume many different instances of Visual Studio, Visual Studio Code open and work on many different code spaces at the same time without running out of memory, without even on a lower part machine, I can do things that require some heavy duty hardware. That's really fantastic. But let's touch on another thing that you mentioned, which was VMs because we've had for quite a while an ability for anyone that wanted to run DevTest on Azure VMs with Visual Studio, so they could connect to a full VM in the cloud that has Visual Studio and then work from there. And so how does those two experiences then, because we still have that, I guess, we still offer that. So how do those two experiences differ and why would I choose one over the other entity? Yeah, they're actually, it's not about one being better than the other. There are certain environments that are kind of fit to purpose for the right tool for the job. One of the really useful benefits of a code space that you have is your ability to kind of provision that whole environment, have that focused environment or code space just for that compute responsibility. And one of the things that we'll probably spend some time talking about is the ability to kind of configure that environment as code, which makes it really powerful to be able to get up and running in a new environment and reproduce environments across your team without those long periods of time that takes to set up those environments because you have that set up in advance. And so you kind of get, in addition to just getting the code cloned down for you, you also get the entire environment configured for you. So these are some of the things that we're able to provide when we have a controlled space like a code space to be able to offer some of those additional values. But there are definitely times where you need to run other tools side by side, you need to interact with other tools that need to run on the environment itself. That's a time where a virtual machine becomes really powerful. The other place where it can become very powerful is if you interact with lots of GUI applications, although we'll talk a little bit about app casting in a second and some of the remote, some of the remote port forwarding we have for web app scenarios. But if you need to interact with lots of different tools on the environment itself, a VM environment could be particularly, particularly useful for you as well. So it kind of is about finding kind of that right fit in which scenario you're trying to enable. Okay, that makes sense. So it's, yeah, so it depends on the scenario. Now you were mentioning something about like you could basically, you could, what did you say that you can configure the environment, the code space from your repo from code? Was that what it was? Can you explain what you're saying? Regression as code, yeah, yeah. Yeah, so, you know, there is, so the code spaces introduced this notion of a dev container, JSON configuration file that defines a number of settings about the code space and what you want to include in them, among them it allows you to define some dependencies of what you want inside of that code space. And there are some differences that we'll, that I don't know if we'll get into in this session or not between kind of configuring for a code space that will work in a Linux container versus a Windows code space. But ultimately what allows you to do is allows us to say, you know what, actually I need this set of SDKs. I need the .NET framework, this particular version of .NET Core. I need these particular NuGet packages to go with it. I also need these other custom tools that only my team uses. They may be internal tools that are pulled from some private share or they might be some other utilities that I need to pull in or some private feeds. And I can configure all of that so that I as maybe a tech lead for my team can define that up front. And as I have new team members joining the team, I just simply give them the repository they need to join and say, go join this repository or add this repository to your code space and they configure that code space. The code space service will then go and read that configuration file and go and execute all that for me. It'll provision the environment for me. It'll give me the environment ready with all those dependencies there ready and waiting for me so that when I connect to that code space it already has all that in place and I can actually get straight to coding. I get straight to building rather than spending all that time and I'm starting that off myself. That is amazing. That solves like one of the oldest problems which is reproducible development environments. That's like the Holy Grail or things like, yeah, okay, that's fantastic. So it basically follows. So that configuration of the environment basically follows the repo. Now, are you able to let you mention that a new employee starts in the company? Can you have that already prepared for that new employee or that new team member? Oftentimes we hear that it takes like a whole week to set up a new development machine when you just start a new company you have to install a bunch of things and get permissions. And then once you get the repo clone to your machine then you need to, then you understand that there's a bunch of SDKs and other prerequisites that you need to install. And so this just takes like a week sometimes. So Nick, is there anything like on the service side that let's say the team lead can prepare the whole environment up front so that it's maybe even easier or even faster than what Anthony said, which was pretty good too which was like setting up the environment but having it like already done for them basically. So the way that it works today is that this team lead person can go and configure everything that they want to specify what the developer environment should look like in the devcontainer.json that Anthony mentioned. And then literally hand the new employee and say, here you go, go click on this hyperlink and they click a hyperlink and in about 30 seconds they'll have that environment, right? So yes, the team can be working and they can have different versions of the dev environments on different branches or different projects can have different development environments that they can switch through. The compute is not provisioned until that new employee goes and clicks on the link because what happens at that point is we take their credentials that they log in with and we put them into the environment. So they're automatically logged into things like git and live share, right? So we don't let the manager create a code space and then hand that thing to the new employee because the manager's credentials would be in that machine. That's the way that it works today. Instead, what we do is we let them create the raw materials so that anybody can go and have this same creation experience in about 30 seconds. Now, the reason why that is important is these environments, we kind of think of them as disposable or ephemeral, like the razor that I clearly didn't use today, right? Like I shave and I don't sharpen the blade on that thing once a week like my grandpa did, right? I throw it away and I get a new one because it's just so easy and fast to get a new sharp blade. We think of code spaces the same way. So yeah, sure, maybe your manager on day one gave you a link and you clicked on it and that's the main code space you work in. But now I got to go review a PR. So I'm gonna click the button to make a code space just for that PR, I'm gonna be on it for an hour and then I'll throw it away. Or I'm gonna go work on a new feature for maybe two days, I'll create a code space for that. So you might have multiple code spaces for the same repo. And so kind of the speed and having those raw materials that anybody can continue to create these things quickly, we feel like it's a really big value proposition. And it's not just new people joining your team, right? As more and more open source and even inner source, which is like open source culture behind your company, Fireball ramps up and we all know this because Microsoft is very inner source friendly. Like I might go jump on some other code base that I've never seen before, but I'm gonna contribute to them for the next 15 minutes and then move on. And so the fact that the raw materials are there for me to go and create a code space very quickly, make a contribution and then throw that dev environment away. That works out really well for everybody involved. And Nick, I just wanna reiterate that you mentioned kind of creating configurations per branch, right? Like that opens up a whole realm of possibilities, for teams that wanna go back and fix a bug in production, but the team has moved ahead and they need to recreate this specific environment. They can rapidly kind of pull back and get the code from a particular release branch and configure the environment exactly the way it was configured at the time that that code was produced even though the configurations of dependencies may have moved on and changed over time from where they were at the time that that code was released. That opens up, like you mentioned, kind of a whole holy grail of new possibilities that are really empowering from a rapid development perspective and getting code out to customers quickly. Yeah, that whole problem where the developer is like, I don't know why it doesn't work for you. It works on my machine. And that problem is virtually gone now because we all can have the exact same definition of our machine at any point in history too. I can roll back to what your machine looked like two weeks ago if I want to. That's awesome. This is pretty significant. This changes the relationship to your development environment, right? I used to, like, I spent a lot of time customizing my environment and all this sort of, you know, extensions and what have you. But you're telling me that maybe a development environment is something you just throw away when you're done. Like, you go in, you do a PR, you do a contribution to an open source project or you work on some other teams code that you haven't seen before and you just throw away the code space afterwards and you never, you delete that and you never connect to it again. Like it's gone at that point. So how does that work from like, like I want to customize, I want to feel at home. Visual Studio to me is the place I feel at home. I don't want to lose that. Am I going to lose that, Nick? No, so you're right. Like what we've been talking about with code spaces so far is kind of following the cattle analogy that folks, you know, in the server rooms use the ops people, right? They don't treat their servers as precious, right? Do developers treat their machines as precious? We'll just look at the back of every developer machine covered in stickers, right? This is a pet. We love it. We decorate it. We care about what color it is. Yeah, we change all kinds of things. The theme, the color, I'm like a dark kind of color theme guy. Like my font's a little bit bigger because I'm starting to get old now and I got a lot of gray hair coming in, right? So it was really important for us to build code spaces in a way that would be very customizable, right? And that's everything that we've been talking about thus far. And that is customized on a per project basis or kind of a per repo basis, but then still make it feel very familiar to the end user so that they're personalizable. And so when you log into a code space, what you'll see is things like we have settings sync built in and we have the support to be able to pull in dot files, which is like a set of configuration files that you can maintain as a separate repo personal to yourself. So with my settings sync, when I log in and I create a brand new code space for the first time, the editor is going to look like the editor that I've always been using. If I want it to be a light theme, it'll be light. If Anthony goes and creates a code space for the exact same repo, exact same commit, but he prefers a darker theme, that's what he's going to get. My dot files will pull in any additional packages that I want installed, change my terminal to be whatever shell I want it to be, change my prompt, give me all my aliases, all of that kind of stuff. So you feel just like it always has. And I kind of mentioned and alluded to that earlier when I mentioned, you know, that you're automatically logged into Git because when I turned on my computer every single day, I don't log into Git again. I'm already logged into Git. I can just do a Git push origin master and it happens. And so we wanted that same experience. So there's been a lot of work to make it feel natural. Actually, I know Mads, you're a long time web dev like me. One of the like the little tiny details that I'm really excited that we got right is when you're in the browser based editor and you're typing code and you press F5, what do you expect to happen in a browser when you press F5? Well, I needed to open up in the browser. I needed to be my browser with my extensions and I wouldn't as a web developer, I wouldn't accept any other possibility. It has to be my browser, my Chrome or my Firefox with my setup. That's true. And my question was a little misleading. Like I'm now using code spaces browser based editor, right? I'm typing into something, I'm typing into VS code in a browser and I press F5. Usually when you press F5 on the web, it refreshes the page, right? Yeah, it needs to open a new tab with the app running. Yeah, but all of us developers using Visual Studio, we know F5 is how you build and debug that project, right? And so F5 does that, right? It builds and debugs the project, it doesn't refresh the tab. It's a little teeny tiny detail, but we wanted to make sure like even the key bindings worked the same way as much as possible, wherever you were. Oh, that's nice. Nice attention to detail there. I think we can all appreciate that. But actually, so okay, so I misunderstood you there for a little bit, but Anthony, this is a question for you because so when I'm in Visual Studio and I'm connected to a code space, and let's just say that I'm building a, what could that be? A console app or some sort of WPF app or what it might be? All right, you're building a web app. Yeah, let's do that story. And I hate F5. So what happens is that a build is being kicked off. On the code space? On the code space. And maybe a unit test runs as well. And after that, an app starts up and a debugger attaches and I've set a break point. That's how my workflow is locally, let's say. So now when all that is happening up in the cloud, how do I actually get to see the app running? Because if it's not running on my machine and it's running somewhere in the cloud, like how do I see it? Yeah, great question. There's two technologies that kind of help us there. If we're talking about the web app example that you described, another thing that I think the code spaces guys got right, that we're able to leverage inside of Visual Studio and all the clients, frankly, is the ability to forward the ports of that running web app from the code space to the local client. So that when you hit F5, just like, what do you expect when you hit F5 in a debugging session you expect to see the app to pop up? You expect to see a browser to pop up and you wanna see the app there, you wanna be able to interact with that app. Well, you get exactly that experience when you are running a web app that is in a code space because what's happening is even though the app is running on IIS Express in the code space that running app is getting forwarded to your local machine so you can actually interact within a local web browsing experience. So you can browse web pages, you can interact with UI. You see that whole web app as if it was getting debugged locally on your local machine. You get that very native feel with all of the processing happening offline. The other scenario you describe kind of the console app or we also have some support for UI based apps is a technology called app casting. And basically what that does is it basically screencasts or just streams down the UI from that process that's being debugged down to the local machine. So again, you can interact with that running app as if that native app was running on your local machine. It's great for line of business apps. It's great for console apps. It's great for things where you've kind of got lightweight UI that you need to interact with that they can stream down over the web down to your local machine. All right, so how does that work though? So you say you're streaming, is it like, when I hear streaming, I'm thinking like either like a video stream or I'm thinking, you know, like a Teams or a Skype call type of thing. Like what is the experience like? You can think about the experience as being very similar to any of the kind of Teams app sharing experiences that you have today where you can actually see the full app focused in on just that app you can enter and then where you can take control. So imagine taking control of someone else's Teams or some other app running across Teams. You can interact with that app. You can press buttons on it. You can see everything that's happening within the context of that process. That's the experience that you're seeing locally. You're just seeing this hosted frame that's hosting all the UI from that process, running on the remote code space, but being streamed down where you can interact with it the same way as if you would have interacted with it locally. And then just to kind of not to oversell the promise, right? Like this is streaming that UI down to the machine, right? So I mentioned this is great for line of business apps that, you know, where they, you know, they don't have high frame weight requirements scenarios, but where, you know, line of business apps where you're mostly kind of formed, you've got different kinds of controls and data grids that you might be presenting. It works really great for those kinds of scenarios. Okay. So it sounds like code spaces is able to handle like web app, desktop apps, console apps, I assume like class libraries. And if I want to, if my product is a NuGet package or something like that, I can use code spaces for that, no problem. Oh, sorry. Yes, so my question is like, what is actually support? Or is there something that is not supported? I know it's in preview and we're gonna get back to that, but yeah, Anthony? Great, yeah, I was trying to answer that question. I wanted to get it out. Yeah, so let me talk about it on the Visual Studio ID side. Cause this is some places where Visual Studio and Visual Studio kind of have a little bit of gap between them. And then maybe Nick, you can talk a bit about the kind of rental support on VS code and the Linux backed code spaces. So from within the IDE right now, we support a couple of core workloads. One is ASP.NET Core projects or all kind of the .NET Core family in general. So if it's .NET Core console apps, .NET Core libraries and ASP.NET Core apps, all those work great in code spacing. You build them, run them. You can actually even build and run .NET Core UI based apps. We just don't have design or support for them right now. And so the editing experience isn't quite where we want them. So I mentioned it here, but it's not something you'll see as kind of talk a whole lot about, but they actually do work and run. The other scenario that we have that works is C++ and CMake based projects. So you can build any console or a library app based on CMake or C++ running on Windows or Linux where CMake is cross platform. You can build or run any of those apps inside of a code space and they work wonderfully. Again, UI based apps do work, but again, we don't have any of the designer editing experiences after those either. All right. And Nick, do you have something to add? Yeah, I mean, I think to Anthony's point, right? The idea is that anything that you can do locally, eventually you'll be able to do in a code space. There are going to be scenarios that are better suited for local and some that are better suited for remote. On the Linux side, the sky is basically the limit there. One of the huge values of the Visual Studio family of products is the extension ecosystem that is available. So if there is a language that runs on Linux and has an extension for VS Code, which is going to be, the whole JavaScript node community, it's going to be .NET Core, C++, Java, Go, PHP, Python, right? The list goes on, right? But that kind of all of the big language is that people are using to do real work today. Those things all are cross-platform. They'll run out Windows and Linux. And so for code spaces that are based on Linux, you could run them there and you can use the extensions to go ahead and connect that. And the extension is just another customization point. So you can make sure that your repo has the extensions that you need to be successful right out of the back. Right, okay. So this wouldn't be a Visual Studio Office hours if we didn't go a little bit deeper into like how we actually build these things. And so like they're two very different, we talked about this, there's two different aspects, right? There's the service and then there are the clients, VS Code, VS and the web. And they're kind of independent to some extent, I understand. But like Nick, when did we start building the service side? And if we go from the beginning, like how did it all begin? And then up till now, like where are we in the flow today? Are we almost done and ready to ship to the world or are we still in preview? There's still things where we are gonna add things as we go along, like where are we? Sure. Yeah, that's kind of an interesting question to talk about. You remember that song Closing Time? Yeah. Yeah, every new beginning comes from some other beginnings end as one of the lyrics, right? And so like where does this story begin? Well, this story began 20 years ago with Visual Studio itself or 15 years ago when cloud computing began, right? And this is kind of an evolution where we just kind of keep on learning and going. So the most recent chapter that I kind of was a part of was LiveShare. And LiveShare is a technology that would allow Anthony and I to collaborate in real time across two different machines. And we had a bunch of users who were literally live sharing with themselves. They'd start a LiveShare session, email the link to their home computer, leave work, go to their home computer to connect in. And we're like, wait, like people want to do this remote work, right? And the VS Code team were finding kind of the same signals. And so they started to build out the remote extensions. So they have remote extensions for working with Docker and SSH and Windows subsystem for Linux, right? So there's kind of all of these giants that we get to stand on the shoulders of. So that's a little bit of a story about how we kind of got here. Of course, the global pandemic is exacerbating the need for people to do remote development. We have a little bit about the architecture. And so like, maybe I'll word architects, but effectively what you can think of has happened is both VS and VS Code have gone through and are continuing to go through a ripping apart. They're being pulled into kind of two pieces where all of the pieces that you can think of that you can see that render will still continue to run on your machine whether that's in your browser or installed on the desktop. And then all of kind of the guts that are running behind the scenes, the build pipelines, the debugger, all of that kind of stuff is getting put into the cloud. And those things are being able to use a network connection to communicate to each other. So that was kind of the first step that had to happen and you saw the remote development extensions in VS Code as kind of the first offering that was a journey in that architecture. The service itself that actually spins up the Azure resources for you and all of that, we started building that in January or February of 2019 and began our private preview at Build, which was kind of in the May timeframe of 2019. And that kind of looks like what you might expect it to, it's we spin up a VM. In fact, we actually have the VM already sitting there ready for you, which is part of the reason why we're able to make a code space for you much faster than you'd be able to go and create a VM because we have one ready and warm. It's like going to McDonald's and ordering a Big Mac. They already got one back there. They're just gonna hand it to you. But then we take that environment and we customize it. We layer on the mayonnaise and the pickles or however you've customized it. Maybe I'm stretching this analogy too much. It's also lunchtime here. We customize that environment with whatever that you want to and we attach a disc to it. And then you use that thing, right? We'll shut down the VM if you've gone idle and you can set a policy for how long you want that to be. And we dramatically reduce the price that you're paying when you're not actively using. You're just basically paying for the storage so you don't lose anything. And then we spin up that VM and attach that same disc to you when you come back. Yeah, so that's kind of audibly me trying to explain a little bit of how we got here and some of the architecture, but apparently in these office hours we go real deep. So let's keep on drilling. All right, so let's ask a similar question to Anthony because so VS Code had a little bit of a head start with the remote development and the extension host work that they did for the Linux subsystem for Windows and SSH and the stuff you mentioned. And then after that Visual Studio started, we started the work on Visual Studio. And so I've been working with Visual Studio for quite a bit and I know that the architecture of Visual Studio is very, very different than of VS Code and it's also like a much larger code base. Like there's just so much more stuff going on than what Visual Studio Code has. So I would imagine that it would require a lot more work maybe to basically separate the view from the logic in Visual Studio like Nick was describing. Is that the case? Yeah, I mean, I think to put it mildly, it's definitely been a lot of work. I mean, we pretty much have every team in the division right now working on some, contributing some resources and doing some work towards doing that kind of ripping apart that Nick described in separating the view from or creating this notion of a view from a model because much of this code was written at a time when view model architectures didn't even exist. It wasn't even a gleam in anybody's eye. And so there was no separation between logic and what you presented on the screen. It was all kind of written together into one big jump. So some of it involves actual complete rewrites of features to get them working in this new model and in this new world. And so there were kind of a couple of, to kind of keep, if we want to dig out and give a lot of the details behind the scenes, maybe it'll help folks who have gotten, 40 minutes into the session to understand more about how code spaces work. There are kind of what are called instance types in code spaces and in the code spaces service. There is the Linux instance type and there are Windows instance types. And then within those two variants there are them kind of compute levels for them. And there's a couple of reasons for that. One is it gives developers a choice about which platform they want their app to run inside of it. And so you have difference in areas where you might be building an app specifically for a given platform and so you want to make sure it's running in the platform you're targeting and that your customers are going to be using it in. But there was another important reason why that was necessary. And that was when we looked at how we were going to get Visual Studio to be able to kind of do that tearing apart, Visual Studio didn't start out as an app that ran on Windows and Linux like VS Code does. And so we kind of had a choice so we had to ask ourselves, do we go and rewrite large portions of Visual Studio to be cross platform and run on Linux too? Or do we look at kind of and then also do that tearing apart at the same time? Or do we focus on kind of doing that tearing apart first getting it running an environment that it can already run in Windows that'll get us kind of to the ability to offer some value to customers soon. And so there were definitely trade offs during those down that path but we chose a ladder path where we said, okay, let's focus on kind of doing that separation first and kind of enable the scenario. So we can start to get rapid feedback from customers because as all of us know, it's important for us to be able to get features out to customers, hear what they're looking for so that we can then kind of iterate, tune and pivot in the right direction. So for that reason then really kind of the guts of Visual Studio that we, of the Visual Studio ID that we pulled out have to run on a Windows in a subsystem. And so they have to run on the Windows code spaces. So really when you so right now the Visual Studio IDE will allow you to create Windows code spaces and connects to the Windows backed code spaces or their code spaces that use the Windows instance type if you want to describe it that way. The Visual Studio code clients on the other hand because they already had that advantage of being able to run cross platform are able to connect and run on either the Windows or the Linux code spaces. Okay. So Nick, what is the difference? Are there any difference really between the Windows and the Linux instances in their capabilities or pricing or whatever like from a customer perspective? I mean, there certainly are differences and differences by design because Windows and Linux are different and they do different things and they handle different tasks in different ways. The other thing is Linux based code spaces are in public preview right now while the Windows based ones are in private preview, right? And so that's kind of another difference. Conceptually, we're trying to make them work and feel as similar as possible, right? As Anthony mentioned, that work is ongoing. It's a big lift for the team but all of the benefits that we talked about for kind of onboarding a new team member really quickly being able to collaborate very easily the customization of an environment, the personalization that's available the ability to connect to it from anywhere with the different editors all of that stuff remains the same, right? But the differences that you would expect between Windows and Linux obviously continue because what we're doing is we're very much giving the developer the power to do what they would natively and naturally do, right? So there will be those differences between Windows and Linux. So that makes really good sense. So what Anthony was describing earlier about how to customize your code space in the repo you basically have a file that describes your environment. If I can then clone that repo into a Linux code space or a Windows code space and the same customizations would apply, right? To both of them unless it's a customization that is specific to that particular OS, is that right Nick? Is that right Nick? You know, I think it depends on what you refer to when you're referring to the customization. The concept would be the same, right? I want SQL Server installed on Linux or Windows, that's fine. But the truth of the matter is because they work differently, maybe in Windows I'm going to install that using a PowerShell scripts. And on Linux, I would install that using a Bash scripts, right? So I do kind of have to have mechanically those two different files. Now, maybe my project is a project as such that I could write it all in PowerShell since PowerShell is cross-platform and I could use that on Linux and Windows. And if you're in that scenario, then yes, you could have kind of one customization artifacts that runs in both. Okay, so there are components like PowerShell that are on both systems. So that if you stay to or you stay within sort of the common denominator when you describe your dependencies in the repo, you should be fine whether you use one over the other. Is that understood correctly? Essentially, right? There's some work that you'll need to do there, right? Because you're not going to install the exact same executable for SQL Server on Linux and Windows, right? There are two different files that you point to, right? So that PowerShell file is still going to have a NIF statement in it. Okay. Right, but yes, I mean like it just depends on what you're trying to optimize for in that case. All right, Anthony? Yeah, I mean, I think you could probably think about it as there are a set of, a set, yeah, shit, a set of... Hey, this is a true show, man, watch it out. Service-level configurations that you define once and they apply no matter what kind of instance type you're using. And so things like some port forwarding configurations that you have, some secrets management features will be available and shared across them. So there'll be a number of those that'll be shared across the two. And then there are going to be some that are going to be kind of platform-specific. So on the Linux side, right? Like you might define some container-specific customizations that are going to really only work when you're defining and provisioning a container of the things you can run in, actually run inside of a container. And so those will be configured in one way and then there are going to be other things that just simply can't run inside of a container. And there are customizations for running those inside of a Windows environment or in the Windows backcode spaces that are available for that scenario. So you kind of think of it a little bit more of a tree than kind of a write once, run anywhere kind of a model. Okay, that makes sense. So if I have for my open source projects, it would be really cool if I could make it easy for whoever wants to send me a PR or just build the source code for themselves. If I could just send them a link that would automatically stand this up, this code space, on the right instance type, let's say it's a Windows only kind of thing. So I want them to stand up a Windows environment. Is that something that's available? Is that even possible? That I could see how cool that would be from an open source perspective because I don't have to install all the dependencies on my local machine. I don't have to pollute my machine. I can pollute this code space that I can just delete afterwards. Is that possible? It is possible. And in fact, we'll, I assume that there's show notes. We'll put a link in the show notes to a repo that I have that requires node and Mongo. And there's a hyperlink right in the read me. So you'll go and look at that. You'll click on the hyperlink in the read me and it'll spin up that environment with everything that you need on it. And anybody can craft that hyperlink. That's not something special that I can do. It's very simple format, just passing around some query parameters and you can specify all of the options that you can use to specify in the form that you would manually fill out normally to create a code space. You can just put into that hyperlink. So you can say that you want it Windows. You can suggest a name. You can point back to the repo, all of those kinds of things. Oh, that's amazing. So in my, you know, on my team, if we have a wiki on how to get started for new team members or whatever, I could just have a link that says, that's all I need in my wiki is just one link. And that will just set up the entire dependency, code space, everything provisioning for the team member. And then that's it. Yeah, delete the eight page. Yeah, delete the eight pages of documentation you have today with how to get the environment set up and replace it with one hyperlink. That's the goal. Yeah. That's amazing. Okay, so it sounds like we have some really, really cool things here. I can sort of scale my own laptop into the cloud. So I don't have to use as beefy a machine at home, right? Because I can take advantage of that cloud power. I can also onboard to new teams, new companies, new open source repos super easily. And you mentioned that I could work from a browser even. Like I don't have to have Visual Studio, let's say I'm on vacation and all I've got is my iPad. I can still go in and be productive using a code space. What are we missing? Anything here? This is like, this is three incredibly fantastic things you got there. Anthony, you're raising your hand. What did I forget? Yeah, well, I mean, we talked about that. You mentioned scaling into the cloud, but one of the things that we can do now that I love about that is not only scale into the cloud, but scale up and down within the cloud. And so we didn't mention in this conversation yet that, yeah, you can create a code spaces and all your compute goes into or kind of all the heavy lifting happens in that remote environment, but you can actually define from a set of choices how much horsepower you want to throw at that problem. So you can start with a low horsepower environment with kind of some moderate compute. And I was reading some stats that about half of our developers have only four cores and less than eight gigs of RAM available, which is our kind of standard middle of the road instance type that we define in a code space. Half of our developers are running at that or less in terms of their existing compute. So that could be your standard starting point from a compute environment, but then you suddenly decide you need to work on, I don't know, some heavy analytics or you've got a build that you need to accelerate or you're running some workload that takes some additional horsepower. You can actually scale that up to a higher instance type on the fly. We start that environment, that code space with more compute backing you. And now suddenly you have a brand new higher horsepower environment for that new task that you're doing for as long as you're doing that task and then you can scale back down so that you're only paying for the resources you need when you need them and you can kind of keep your costs under control when you don't. That's really smart because let's say that I want to go with like, let's say the cheaper, more less powered instance type in the cloud and then I can always scale later if I wanted to but those let's say it's a four core machine, like I guess you meant like maybe a dual core with four logical processors, right? I take it because I think four core is still like pretty high end, high high sevens or whatever but still like Nick was mentioning this earlier those are a hundred percent dedicated to running your build, your debug, your unit test. And so they're actually more powerful than if you had the same specs on your machine because there's no competition for the resources, right? Absolutely, more room to share with Spotify and all the other things you might wanna run on your local machine that now don't have to compete for those resources locally. Think about kind of outlook indexing in the background while you're sitting there trying to do a build. It's not like the two of them are talking to each other and agreeing on when the best time is no, they're usually fighting for resources. And so now the only thing they're fighting with is the UI presentation of Visual Studio. Another, and actually kind of let's just kind of go down that road for a second. Another awesome thing that this kind of buys us with kind of ripping all the guts out of your local machine is I don't need to install any of that crap locally. So now we have the opportunity to dramatically shrink the size of Visual Studio installs from today what our tens of gigabytes to now what will probably come on the order of single digit gigabytes in our first pass and we're gonna get it down even smaller than that such that it'll take moments to install Visual Studio locally because really everything that you need is already getting provision installed in the code space and all the SDKs, right? Like just think about like Windows SDK, for example, you know, four or five gigabytes of content that gets installed with that SDK. If you check that workload, none of that's getting installed on your local machine. All of that is already available in the code space for you. So your local install of Visual Studio is minutes. So not only do you get a single click to get an environment up and running, but the bits that you need to install locally are much smaller as well. Yeah, okay. So I wanna make sure we get to it because we don't have that much time left and that is pricing. So Nick, you were mentioning a little bit about this whole idea that typically if you are working at a company, you don't as an individual want to pay with your Azure credits or whatever for a code space. You want the company you work for to pay for that but the code space is assigned to you. So you mentioned that it was like something that you stand up personally in your account or something like that. So how does that work when you're either your individual versus when you are part of an organization? Yeah, good question, Matt. So when I was mentioning that you, the individual owned the code space, you do own that code space and that is kind of your thing. Some other developer on your team is not gonna be able to go in there and get access to anything that you have in there that might be secrets, right? And even though they're on your team, right? I have secrets that I can't share with the two of you as my colleagues, right? You don't know my domain password and things like that. So that is still true in lockdown. That does live, however, within the context of the rest of the Azure ecosystem because even though it's visual studio code spaces it is an Azure service. So it will be in the resource group or subscription that your boss or company owns. And so they can continue to be paying for this on your behalf, even though you're the only one that can access that code space. So in terms of kind of building all of that, the lines of payment kind of worked the way that you would expect it to work with any other Azure service. But what it does mean also because it is an Azure service that if you as the developer watching this happen to have Azure credits from whatever program, like maybe your visual studio subscription, you get a monthly set of credits, you can go apply those to code spaces right now. And so you can go and try that with the credits that you have, or you can go create a new Azure account and get the free trial credits if you haven't done that before. Any of those kinds of programs that we have available for Azure users is available to apply for those credits. Let me mention a little bit about how the billing works because we are developers and so this is a service by developers for developers. And so we were very cognizant of how developers do their work day to day. And we all know that none of us are sitting there typing out code for eight hours straight. So what we have built in is a way to detect if you've gone idle, if you've stopped typing, right? Maybe you've gone off to a meeting or to lunch or something like that. And so while the code space is actively being used, you're gonna be charged based on the instance type that you're using. And that ranges anywhere from about eight cents an hour for kind of our low end instance type that Anthony was mentioning up to 34 cents an hour of active hour. But then once we notice that you've gone idle, we spin you down and you get charged virtually nothing. You get charged fractions of a penny an hour just to kind of keep the environment alive. And of course you can delete at any time. And we do down to the second billing. So even if I only spin that thing for 15 minutes, I'm not gonna get billed for a full hour. So it means, well, maybe in your scenario, it's better just to spin up your own VM and remote desktop to it and use it. And that's great. Please do that if that's good for you. In that case, you know, you need to make sure that you shut down that VM at night. So you're not gonna get charged for it to run all the time. We handle all of that for you. So we try to keep the cost as low as possible and really only charge you when you're actively doing development. Okay, so there's a good chance that anyone listening, you might already be able to use code spaces with the existing Azure credit that you've got. If you're using Visual Studio Enterprise, I think you definitely have a subscription and you definitely have Azure credit that come with that. So make sure to go and activate those. And there's a lot of other programs. So you might actually have full access. That's really, really cool. Before we stop here, we only have a few minutes. This is in public preview if you're using the web client or you're using Visual Studio code and anyone can go and do that right now. But if you want to do it from Visual Studio, we have a private preview. Anthony, can you talk a little bit about that? How people can sign up for this? Sure. Well, down in the video notes, we'll be sure to put the link for the sign up. And actually I can read it off to you from memory if you want to. It's http colon slash slash aka.ms slash vspreviews. No, darn it, I got it wrong. We'll put it in the notes because I didn't get it. No, that's the Visual Studio preview download. So never mind. We'll put the link in the notes. But anyway, you need to sign up for the preview. And if you sign up for the preview, we, on every week, we will take a new batch of developers and we will add them into the private preview. We're starting out with a slow dial right now because it's still early days. We're kind of learning about how code spaces and Visual Studio work together in different kinds of environments, different kinds of configurations. So we've been learning all sorts of things about kind of different environments and bugs and features that we need to add to make sure that it works easy and great for everybody to onboard. So we've been starting that dial slowly. We'll slowly add more and more developers in the weeks to come. And so just kind of hold tight if you don't get an email from us right away saying you're in the program. But we are certainly letting folks more and more folks in. While it's in private preview, it's worth noting that the code spaces themselves are free. So like, because you're helping us learn and you're helping give us feedback and we're making the product better with your help, we don't charge for the code spaces that you create during that time. So during the private preview, the code spaces you create for working with Visual Studio are free. You'll still have to pay for the Linux-backed code spaces that you're using from VS Code or from, well, I don't wanna say from the web browser because the truth is, is that you can connect from a web browser to the same code spaces you create from within VS as well. So it's really kind of the differences. When you create a code space, you get that choice. We talked about that instance type, the Linux or the Windows-based code spaces. When you create the Windows-based code spaces, those are free while you're in private preview. The Linux-based code spaces are the ones that right now are in public preview and are kind of charged. And we'll make sure we put a link to the pricing sheet there as well. All right, excellent. I just have one question that I forgot to ask but I need to ask is Visual Studio code spaces and GitHub code spaces the same thing, Nick? It is the same thing. The way to think about it is if you are an Azure user and you wanna come in and use it via Azure, then please go ahead and do that. And then what we've done is for users to kind of have their source code already at GitHub or prefer to use GitHub we're just doing a really tight integration. Now that integration where it's built right into GitHub.com's interface is also in a private preview just like Anthony was mentioning with the Visual Studio support. And you can sign up for that at GitHub.com slash code spaces but it's the same service built by the same people. So yeah. All right. I have a question since the camera's on me for one second, I know we're at a time. The people of the world are dying to know this, Mads. Oh yeah, how do you like when the tables are turned? I don't know. I'm fidgeting with this. Anthony is fidgeting with a spark plug, I see. What does Mads Christiansen fidget with? I have anything it would be as, usually it would be a coffee mug. Royal Copenhagen, my favorite mugs. But I have this- National pride. Yeah. The surface pen, which is, you know, I take a lot of screenshots and I- This is what he's holding up to show is this. Yeah. I think they can only see me, right? This is the first generation. So it's a couple of years old. Oh yeah, I think we have a set. Yeah. Yeah. Oh yeah, sorry. So the one time when I'm on the spot here, I forget to put myself into the people. Yeah, how do you like it? It's okay, I was showing everybody for you. Yeah, I saw that. Thank you for that. Yeah, that's it. It's good for taking screenshots and opening bug reports on people. Okay. We are out of time. We are respectful of the time of our audience and of course of you too. So thank you so much for joining us. I think we could go on. There's so much more content here. I think maybe we should do this again in a few months when we're closer to opening up for more people coming in. To try out both spaces and sign up for the preview, there's gonna be a link in the description. So go check that out, sign up, and you'll hear from us. And that's it for now. Next time, Thursday next week, 9 a.m. Pacific time, we're gonna talk to Dan Roth about Blazer. So see you then. See y'all. Bye.