The Modern .NET Show

Episode 110 - JetBrains and Remote Development with Maarten Balliauw

Embedded Player

Episode 110 - JetBrains and Remote Development with Maarten Balliauw
The .NET Core Podcast

Episode 110 - JetBrains and Remote Development with Maarten Balliauw

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Transcription

Hello everyone and welcome to THE .NET Core Podcast. An award-winning podcast where we reach into the core of the .NET technology stack and, with the help of the .NET community, present you with the information that you need in order to grok the many moving parts of one of the biggest cross-platform, multi-application frameworks on the planet.

I am your host, Jamie “GaProgMan” Taylor. In this episode, I talked with Maarten Balliauw about how JetBrains (and many of the other IDE manufacturers) are building remote development tools, what they are, and how they work.

Along the way, we cover the differences in the amount of effort required to onboard new developers when you have to manually install all of the supporting tools, spin up VMs, and ensuring that the source code remains secure vs using something like Spaces from JetBrains.

So let’s sit back, open up a terminal, type in dotnet new podcast and let the show begin.

The following is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Jamie

So welcome to the show, Martin. We’re, I’m very excited to talk about what we’re talking about now. Because to me, this idea of remote development and not having to have the world’s most powerful computer, in order to do the work is very exciting to me. We’ll come back to that in a moment. But I love this idea of being able to use - and I dislike the term, but I like the technique. And that’s, you know, back in the day, there was a thing called a dumb terminal which was just a computer that just connected to a server. We’re going back towards that. I’m very excited. But before we do all of that, welcome to the show.

Maarten

Thank you very much. I’m super happy to be here. So thanks for having me.

Jamie

Hey, not a problem. Not a problem. Um, would you mind just sort of introducing yourself to the listeners giving them a bit of a flavor of who you are and the work you do?

Maarten

Yeah, exactly. So I’m Maarten Balliauw. I live in Antwerp, Belgium. So that might be close to you might be far away from you. I’m a developer advocate at JetBrains. And that is both developer and advocate. So I tried to develop on some of our tools, the Azure plugin in Rider, for example. But I’m also a developer advocate, trying to get people excited about all of our .NET tools like Resharper, Rider, and even things like Space and remote development. So pretty much everything. My heart lies with web development, and everything, clouds and all the architectures around that as well, which is surprisingly similar to how IDEs work with message buses and communicating between different parts of the IDE and so on. So I think that’s a really good fits to be at JetBrains. And building that kind of tools as well.

Jamie

Excellent, excellent. I was trying to explain - for the listeners, we’re recording this a little ahead of time. At the time of recording, I’ve got an apprentice that I’m working with. And I’m sure he wouldn’t mind me saying, “I don’t want to work in web, because web is not where the fun stuff is,” and I’m like, “trust me, web is where the fun stuff is. And if you can get the web stuff, if you can get your head around how web stuff works, you can make asynchronous desktop apps. Just it’s the same idea. It’s just a different technology stack.” Right?

Maarten

I would almost even argue that it’s more difficult to work on desktop versus web. Because on web, at least with React and stuff. You You still have state management and all of those things. But the typical client server, make a request, get a response back is stateless. It’s perfect. It’s bliss, you don’t have to care about any of that state management.

Jamie

That’s very true. Very true. Yeah, we’ve been, we’ve been playing around with .NET, Maui, as part of their, their their project that they building. And we’d started working with it. Two weeks before it was like officially released as a version one. And yeah, the state management, the stuff that goes on with that is, it’s fun to deal with.

Maarten

I can imagine yes.

Jamie

Excellent. But we’re not here to talk about .NET Maui. We are, like I hinted at earlier, we’re talking a little bit about remote development and some of the tools that are available. Now we got talking originally many months ago, many moons ago, about JetBrains Fleet. And I was very excited, then I’m as excited now, right? Because this is, I mean, I’ll let you give the proper, brilliant introduction. But my layman’s term vision of it is like, “I can install this tool, I can push a button and it will spin up maybe a container or something somewhere for me to run my code in. And I don’t have to have the world’s most powerful computer in order to do my development work anymore.”

Maarten

Yeah, exactly. Yeah, I can give you a little bit of a background or a little bit of the story around what is available. So at JetBrains, we’ve historically been building IDEs, I think we started with IntelliJ for Java developers, and a lot of our other tools like WebStorm, PHPStorm, DataGrip, Rider even are built on top of that IntelliJ platform, which is really it’s an open source project. Actually, Google is using its to build Android Studio as well.

But IntelliJ is, I’m not gonna say too old, but it’s fairly old. And it’s quite mature in that. But it also has its own opinionated way of doing things. And that’s why we also started thinking about Fleet a new next generation IDE, which would take the learnings that we have from building IntelliJ for 20 years and trying to see where we would end up if we were building a new IDE from scratch with everything that is out there currently and everything that we have learned over time. At the same time, remote development became a thing. You have lots of vendors popping up, that see the benefits of doing remote remote development and nets. And with fleets, we thought, “okay, let’s take that angle from the get go, let’s let’s start building Fleet as a distributed IDE that can run on one machine. But that can also run kind of split brain where you have parts of the IDE on different parts of your ecosystem.” So it could be a VM, could be your local machine, could be a Docker container, or whatever. And to make things even more complex, at the same time, we also started building remote development into IntelliJ, which became our JetBrains gateway client, where you can just run IntelliJ as a server somewhere, connect to it, and then work locally. So that’s more or less how things fit together or the differences between all of those things.

Jamie

Wow so there’s an awful lot going on there. An awful lot going on. And yeah, like I said, it’s super exciting to be able to have this right, because you’ve said all of those; you’ve said quite a lot. And like I said, the first thing that came to mind was what I said earlier on, right, “I may no longer have to have an incredibly powerful computer,” maybe I could just - I’m guessing this is hyperbole, this is me just just taking your example of running with it - maybe I can use a relatively cheap, not so powerful throw away laptop, to then do my development, right?

Maarten

Yeah, absolutely. So that’s, that’s a really interesting one. So at JetBrains, we are working on our own back end for remote development, where you could go into our Space tool, go into any repository, and essentially click open an IDE, which will spin up a VM for you, which will set up the connection and everything so we can get started. At the same time, we’re also working with a number of partners, for example, GitPod is one of our partners, they also do something similar: they handle the orchestration of spinning up everything in the backend and then connecting our IDE to it. And I know one of the developers there is actually using GitPods to build GitPods. And what they have is I think a Chromebook are like a really underpowered device and just working remotely all the time with the IDE running on a more powerful server.

Jamie

I like it, I like it. And you’d said about, you could perhaps have a hybrid setup. So you’ve got your super powerful computer. But maybe there’s something that would take lots of horsepower to do, you might be able to shove that part of the code off somewhere else and go, hey, you know, do this, right? This is me talking, this is not you talking, this is not JetBrains talking, but my example might be, “hey, I have this machine learning model, you need to go generate, go do that somewhere on my super hyper powerful server with a ba-billion cores, and 18 kajillion gigabytes of RAM. And then when you’re done, give me the file and I can carry on with what I’m doing, right?”

Maarten

Yeah, that’s indeed the idea. So most of the week, I might be working on some codes that could run on any type of common VM with, let’s say, eight or 16 gigabytes of RAM. And then once a week, for a couple of hours, I need this hugely powerful machine that has a graphics card that has 25 teraflops - I don’t know what I’m saying even but - like a really powerful machine, you could just spin it up, connect to it and develop there as if you were working locally, but just have more power available.

Jamie

I like it. There’s a lot to be talking about here and a lot of stuff there. And I really do like that ability to do that work remotely. You know, the work that I do is 100% remote, and it was 100% remote for a little while before the world went all wobbly - we tend not to talk about the current situation, right, because it’s we don’t want to talk about - but before the world went wobbly, you know, I was fully remote as well. But it meant that I needed, you know, a powerful machine to be able to do all the work. But I like the idea that I maybe don’t need to anymore. But also I feel like it’d be quicker for onboarding people. Is that the benefit as well?

Maarten

Yeah, absolutely. So there’s, there’s even a couple of additional benefits, like if you are a consultant, and maybe you work for two different customers every week. I’ve been in that situation where I was a consultant and actually was carrying two laptops around one for each customer. In this case, that laptop could be something remote, and you just log on and work in the IDE at that customer, maybe even have a pre configured for you and everything that is there.

So that is essentially one of the real massive benefits, I think, in terms of remote development is that first of all, everything can run on the infrastructure or the clouds of the customer you’re working for in that case, which means you get more security. There’s no codes on your laptop. If you’re sitting on a train or in a tube and you lose your laptop. The code is still in the cloud. It’s not on that laptop. So that’s it good thing to have. The other thing is like you say, onboarding and standardizing remote development environments. We call that orchestration. And that is something that Space does that GitPod does that GitHub Code Spaces does for example, as well. Where essentially you give the orchestrator, a Docker file and you say, “look, I want to work on this Ubuntu virtual machine, install the latest .NET versions for me, install the git tooling. By the way, I customize my terminal like this, also make sure that that is pre configured.” And the next time boom, you have the exact same environments; could be a completely new machine, but the Dockerfile is standardized, and you get the exact same machine. So if you would onboard someone, they would also get that machine with those tools installed, and it would start off the same for everyone. Instead of having this massive Confluence document or something where you explain to team how to get started, how to set everything up.

Jamie

I like that, because, um, yeah, I’ve looked into sort of automating onboarding people in the past. And there’s, you know, loads of different tools for different things. There’s like Chef, Ansible, puppet, all these kinds of things. And I found that the majority of them are kind of a little bit fragile. Like if you’re scripting, setting up a machine, then you’re saying - I mean, this is my own personal experience, right? This is not me, saying, hey, they are or they’re not - you’re scripting it. And you’re saying, “right, install this particular version of this tool, because it’s required.” And that tool is then maybe deprecated. And you don’t know you or you don’t realize, or maybe you’re installing something that has a direct dependency on a specific version of a binary, that your operating system ships; actually I had this not so long back, I started working on a new project. And we were writing some Python code, and a required a specific version of Python. And then partway through the project, I was using an Ubuntu based system, and it popped up saying, “hey, you need to update your OS, otherwise, you won’t get any support anymore.” I’m like, “okay, I’ll do that. Yeah, sure. Update.” And when it rebooted, nothing worked, because they’d forced upgrade onto Python, like the vNext version, which had a whole bunch of breaking changes. And I was like, “well, that’s kind of no good.” You know, I’m not trying to say a bad thing about Ubuntu or Python or anything. But that can happen even in the Windows world, right?

Maarten

Yeah, exactly. I think in past years, we have all been working on getting a better DevOps cycle and scripting your environments, essentially, infrastructure as code where the target environment for your application would be scripted, and would be reproducible. If you need to spin up a new staging or development environment, you could do that using the same scripts. But remote development is interesting, because there you are, essentially standardizing your developer workflow as well. So you are making sure that the development environment starts off the same for everyone. And the interesting bit there is because we source control everything, you write your code in source control, maybe you are working on a feature branch or whatever. You could also customize the environment for that specific branch with additional tooling, newer versions, or whatever you want to do. And everything would spin up a new environment based on that thing would have that new development environment available.

Jamie

Yep. And all of the magic of things like tools embedded into certain paths. All of that’s taken care of, right?

Maarten

Yeah, exactly. It’s even nicer. With Space, we do this - and I know some other vendors do this as well - where a lot of those systems that orchestrate your remote development environments work on the basis of Docker, because there’s lots of images that you can use and reuse and get started with. What we do in Space, for example, to prepare your development environments, is we already built a Docker container so that the next time you run it, you don’t have to go through all of the build steps. And maybe if you’re downloading half of the internet, then you don’t have to wait for that, and the environment can get started more quickly. What we also do there is the first time we built that image, we launched the IDE that you will be using on there as well, so that it already has indexes of your code and everything. So the really interesting thing there is when you click “open in IDE” you essentially really have a ready to go environment with everything pre loaded everything warm. If you want to npm install, and again, download all of the NPM packages that you need in your projects. We have that ready for you so you can get started immediately.

The downside of that is of course, you don’t have much time to wait for things and go grab a coffee, but I think that’s a good thing over time.

Jamie

Yeah, you see that? That’s something that I think perhaps not a lot of developers think about or maybe they do and they’re just not very vocal about it when talking to me is: the time that it takes from, “okay, so I’ve got my operating system. I’ve got my tools installed. Now I’m going to git pull code or check out the code somewhere, I’m gonna get the code to my computer. And now I want to build it. Okay. So before I do that, it’s going to restore all of these dependencies,” like you said, maybe NPM, maybe nuget, maybe Ruby gem. And then there is, like you said, it’s got to pull that from somewhere, maybe it’s pulling from an internal server where everything’s being checked off. Or maybe he’s just pulling it directly from the, the outer repository, whichever way works for you.

But that, like you said, it’s a process takes time. And then once it’s done that, whatever tool you’re using will likely after recache all of your code, and the dependencies

Maarten

Exactly that

Jamie

That wonderful IntelliSense or AutoCorrect - or whatever you want to call it - experience, if I hit dot, and it just fills in a menu for me. Because that’s all got to be, like you said, it’s got to be warmed up, that’s got to be ready for you. And, you know, it’s these… I’m worried about saying micro optimizations, I don’t want to be able to think, “oh, it’s only half, half a second or whatever.” But this is like 10s of seconds, minutes of time, right?

Maarten

Yeah, absolutely. There is a small tangent I want to make here as well. And that is, because a lot of people might have never tried remote development in that case, or haven’t really looked into it. So it’s not like you are connecting to a virtual machine using remote desktop or VNC, or whatever. In our case, and I know in a lot of competitors cases as well, you would connect to a remote machine, but the machine is running your IDE. But the UI of your IDE is actually running locally on your machine, which means if you’re typing, if you’re editing code, things go smoothly and go fast without you having to wait for what is essentially images being streamed from the server to your desktop. You have the IDE running, and you’re sending commands over the wire back and forth on what should be changing, and what you want to be doing.

Jamie

Excellent. Yeah, that’s because that was going to be my next question was like, without giving away the secret sauce, how does it all work? Right? You’ve you’ve just answered, he’s got this, this connection that it uses, and it’s passing, like you say, your commands, your keystrokes, your mouse movements directly backwards and forwards rather than… because like, if you if folks don’t know, if you connect to a remote desktop or a VNC server, it’s mirroring the visual of what would be displayed on that machine, on your machine, right. So it’s got to almost like stream the video backwards and forwards.

Maarten

Yeah, and in this case, it’s actually better than just sending keystrokes over the wire and mouse clicks over the wire. So the way in the JetBrains, IDEs, IntelliJ, WebStorm, and all of that, if you’re working with remote development, the way it works is we have a shared view model between client and server or between your client and the IDE that is running remotely. So just like you say, with Maui and state management’s, we essentially have a view model running, that knows about the inspections that should be showing for a particular line of code and so on. It knows about the IDs, it knows about the icon ID that should be displayed. But all of that is in the view model that is sent back and forth between the server and the client. And whenever something changes, whenever there’s a new inspection to be shown, the server essentially pushes a new ID - like an ID and description and whatever - into that view model and the client will render it for you. So it’s, it’s actually smarter than just sending keystrokes over the wire.

Jamie

I like it. So let’s say that I’ve got some code base. And I want to run it entirely locally, right? I can still do that? Or do I have to have something that’s the like how? Yeah, let’s say that right? Can I still run everything on my machine locally, or do I need this server component just to be sitting there ready to go?

Maarten

It depends on how you want to work. So you can still I mean, the IDEs are there. So if you’re using Rider, for example, you can build your ASP .NET apps locally on your machine, run and test everything locally. And that will work out just fine. But then again, maybe you are on an underpowered device and you want to work with the code remotely and get a powerful machine backing your code and doing everything, you launch it remotely. And then things will start and you can work on that as well.

An interesting thing, ASP .NET, for example, is really cool. In fact, with remote developments in Rider. Your IDE may be running remotely. If you debug your application, the application is also running remotely on that server that you’re using. The debugger is also running remotely on that server that you’re using. But you still of course get to inspect everything on your machine. What I find really cool in what we built is that we also detect ports that are being opened on the server on the remote so if you run your ASP NET application, it might open up port 5000 and listen for HTTP requests on localhosts. But the thing is localhost in that case is your server because everything is running there, right? So what we do is we detect when it happens, and bridge the connection. So that’s on your local machine on your actual localhost, we forward that port over the same wire that we have with the server. And you can run in your own local browser, your localhost port 5000. But it’s going to be whatever is running on the server that gives you back the response there. So it feels like you’re running locally, but it’s essentially running on the remotes.

Jamie

Right. That, to me is a wonderful bit of value-add, I mean, it’s probably not a value-add product for yourselves. But like, as a developer, I don’t then have to mess around with IP tables or my hosts file or whatever. It’s just, it’s all taken care of.

Maarten

Yeah, exactly.

Jamie

I like it. I like it.

Maarten

Of course, there’s a couple of - and this is going through detailed territory. But there’s a couple of weird things as well, where in the case of ASP. Net, for example, you get this developer certificates that will be generated on the server on the localhost, that is your server. Whereas on your actual localhost, you don’t have the same certificate because you’re on a different device. So you get an SSL warning. So you have to do some trickery there as well. But in general, it will all work out of the box and look like if you’re working remotely.

Jamie

I’ll take having to do trickery, if the majority of all of the setup is done for me, right? Because I can imagine that in a different situation. If I wasn’t using, you know, the remote development tools, if I was actually running it on a server, I’d then have to do something like ngrok or something to

Maarten

exactly

Jamie

Manage that connection and I’d have to manage all of that magic, or maybe use tailscale or something like that. Right. I have to use some other app to map that off for me. So usually, I’m against magic, but when it’s magic that takes away all the stress I’m happy.

Maarten

Totally agree. Yep.

Jamie

Okay. So let’s just really quickly talk about the difference between a VM and orchestration, right. We’ve hinted at it a little bit about when we said, you know, you’re not using a VM, you’re orchestrating something in the cloud, and you’re not connecting to it via remote desktop, right? Yeah. So for because I know that there’s a lot of devs out there, who maybe haven’t had the experience of setting up virtual machines and setting up servers and stuff, it was really good, you just really quickly give us a brief difference between spinning up a VM and orchestrating your entire force or

Maarten

whatever, I think spinning up a VM is very similar to how you would set up your local machine. So what you would have to do is, if you need this big machine with lots of memory, and lots of disk drive, or graphics cards, or whatever, you would have to, first of all, get a cloud provider or get a place where you can run that VM. Next you remote desktop into it, or you VNC into it, or you SSH into it. And then you have to start setting things up, install all of the tools that you need to clone the repository, make sure that you have certificates, user accounts, all of those things ready to go. And only then you can start working. You also have the downside of it being a VM and like we talked instead of solely the VM or remote desktop, you will essentially be streaming the video cards of the remote server to your local machine. If you’re on a high latency connection, or imagine I’m in Belgium working on something and my VM is somewhere on the West Coast, because the company requires that you will incur latency. And things will not feel as snappy as you would want to work. So there’s, there’s a number of downsides to that. It’s a good approach, it works because the goats remains remotes, nothing on your machine. So you get that benefit, you can use a big VM, you get that benefit as well. But it tends to work against you because you have to set up the VM. And you have that problem of potentially incurring latency because it’s the remote desktop that you’re working with. Orchestration with remote development is sort of like a nice way. So in space, for example, on get bought, for example, you still get a virtual machine. But what the vendor does in that case is they run some of our tooling some of their magic on top of it to help you set up that VM so that it can be used by you. So what we do in space, for example, is that you would set up a Docker file, you could say, Okay, I want this Docker file to be based on the latest .NET Six SDK. You can install git on it, you can install whatever tooling you may need on they’re using just Docker commands essentially. So if you want to try this out, see what your VM or your, your machine is gonna look like. You can run it on your local Docker that you have on your machine yet. thing set up. And then what the vendor also does is make sure that when you launch that Docker file, it maps the volume with the latest sources that you can start working on, it might open up the IDE beforehand to do all of the indexing and give you all the IntelliSense kind of things, as well. So it essentially automates a lot of that manual setup that you would have to do otherwise. And we talked about this a little, you have TerraForm, and you have all of those tools to set up a VM as well. There’s an absolute benefit to that. And if you’re using the traditional VM way of doing remote development, absolutely go for tools like that. But it doesn’t take away the downside of running it. And where you still have to connect over Remote Desktop, get that latency and all of that. An added benefit is that because it’s a Docker container, and your source code is going to be mapped on a volume in a Docker container on the remote machine that is running. It’s also very easy to upgrade that Docker container, you need new tooling, switch a branch or whatever, you spin up a new container, reattach the existing volume with all of the User Home folders and source code that you may have. And you’re ready to go. Again, you don’t have to make sure that everything is pre configured or reconfigured, connect to it installed things all of that is there and easily to swap it out with a newer version of things.

Jamie

Excellent. Excellent. I love I love the simplicity of it, right? Because Plus, I’m guessing there’s an element of speed, right? Because if I’m, if I’m having to spin up a VM on demand, now, let’s just take away the cloud for now, right? If I’m having to spin up a VM on demand on prem, assuming I have the hardware, I’ve got to go get the installation media, I’ve got to sit and run through the installer, set up all of the partitions or whatever, then like you say, I gotta get all my to link or I set it up. Gotta get that right, then I’ve got to pull the source code from somewhere. And that’s just getting me to the point where I can log in.

Maarten

Yeah, exactly. And that is taken away by all of the orchestration that you will have. Most are working in a similar way, like spacing, get bots, they’re both using Docker containers, there’s typically some Yamo files involved as well to just set some specifics like which Id you want to load and all that. But in general, once you’ve figured out how one works, then the other ones will be easy to try out as well.

Jamie

Sure, okay. So how do I go about, let’s say, let’s say I’m convinced here’s my credit card, let’s do this, right? And I want to replicate my local environment. Is it just a case of, well, you know, what, I’m, what am I running locally, right? Choose that Docker container? Which tools on my running, choose that Docker container, choose these options? Or is it a case of right, okay, I’ve got to start from scratch. I’m going to bring up a Docker, like a Docker container file or a Docker, what’s the command now?

Maarten

Docker composure?

Jamie

Yes. Thank you Docker Compose, you know, maybe I’ve got to fill in a Docker compose file and say, well, I need this image, I need that image in eSports mapping to those posts. Is it? Is it automated? Or is it or partially automated? Or is it completely manual? I’m gonna disappoint

Maarten

you there that is completely manual. So the way most of the vendors work in that include space is that there’s typically this pre configured environment that has lots of tooling installed. So like for space, I think we install several JDK versions, because maybe you want to do Java development, I think we have two versions of Python installed, or the latest .NET is installed on there. I think there’s a PHP interpreter as well. So just like a generalized fits most of the cases type of Docker container that you can get started with more easily. Now, of course, all of those tools take space, all of those tools may be running in your, in your target environment. So maybe you want to simplify things. And that is where you start customizing with your own Docker container. The way you go about that is completely up to you. I’m a big fan of using, for example, the .NET Six SDK container as the base image for whatever I’m doing. I know I have a colleague who is working on their private stuff. And they actually have Ubuntu and they use the .NET installer to essentially achieve the same points, getting to develop dotnet code on a remote machine. But it’s preference and I guess, standards on how you want to do things. I want to make another tangent there if that’s possible. So you mentioned Docker Compose, that’s a really interesting thing that also tacks on to the benefits of having orchestration available. So imagine you are building a dotnet application and you need the Azure Storage emulator. You maybe need a SQL database. Maybe you need an SMTP server because your application is going to send emails and all of that. What you can do with orchestration there as well is not only generate a Docker file that will host your ID He typically what will also happen on those platforms in space does this out of the box as well, is that they run Docker on there as well. So if you have those requirements of requiring a SQL Server requiring a mail server, all of that, you essentially get a compose like solution where it can get those things started whenever you open your project in the ID. So also there, if you have someone new who is onboarding to your projects, they essentially open an ID, it will spin up a SQL Server, for example, and you have writer remote ID ready to go and that can connect to the database and you can get started with it’s.

A Request To You All

If you’re enjoying this show, would you mind sharing it with a colleague? Check your podcatcher for a link to show notes, which has an embedded player within it and a transcription and all that stuff, and share that link with them. I’d really appreciate it if you could indeed share the show.

But if you’d like other ways to support it, you could:

I would love it if you would share the show with a friend or colleague or leave a rating or review. The other options are completely up to you, and are not required at all to continue enjoying the show.

Anyway, let’s get back to it.

Jamie

See, that’s that’s another thing that a lot of perhaps a lot of devs, who have been working on a project for a long time, don’t realize is that like, just getting things up and running, like you said, right, you got to install SQL Server, which version of SQL Server and that opens a whole bunch of ports on your computer. And then it’s like, where do they where do the database files go? And is it a good idea to store on this drive, or that drive and all that good stuff, there’s

Maarten

even a couple of additional benefits because you’re not constrained to having just one remotes development environment, you can have one per branch or one per feature that you’re working on with different states of the environment as well. So imagine you have two branches, where the database schema has diverged completely. Instead of having to run database migrations, every time you switch your branch and hope for the best that your data is, in order to get started again, you just essentially have two environments, in that case for every branch with different types of data in the database ready

Jamie

to go. I like that that makes it so much easier, right? You’re then no longer having to write maybe a script or migration, just just to be able to switch branches, right? Yeah, exactly. I imagine that could get really difficult to manage, like, I’m working in this branch, they feature at this new table, which requires me to add 50 new database tables away, I need to leap over to this branch back to main or whatever, because I’ve got this bug fix in place. Well, now my database doesn’t match the code. I’ve got to undo those migrations. Well, that’s a manual process. But if I accidentally leap over to another server, essentially, and do the work there, that’s as magic.

Maarten

It definitely feels like it. But it’s so much more productive in those cases where you have to switch branches and essentially update the environment every time you switch branches. I like it.

Jamie

So we talked, we talked a lot about how how it kind of can help developers right, but we touched on this a little bit, but like, what is it actually, without giving away the secret sauce, right? Or when you can get in trouble by telling me and the listeners will like, oh, well, you know, it starts with public static void. But like, what’s, what’s the technology is built on them. We’ve talked about Docker a lot and get pod, right? Yeah.

Maarten

So the orchestration in space is our own implementation, I can really talk about how that works, I can talk a little bit about how that works. It’s essentially Docker and VMs, that are pre loaded and ready to go. And we provision your Docker container on there and you have the orchestration running and you can connect to it, the actual IDE that is working remotely, I can talk a little bit about that as well. So all of our remote developments that we have in the IntelliJ based IDEs, is based on what we have been doing in writer for a number of years now. So maybe give you a little bit of history. IntelliJ was a Java ID. And it’s still a Java ID. It’s also an open source project built on the JVM. So if you tomorrow want to start building your own IDE, you could use it and and start working on top of that. We have Resharper, which is a Visual Studio plugin that does all of the dotnet stuff that you can do with Resharper. And it’s written in dotnet. The two technologies don’t really mix and match. One is JVM one is dotnet. And when we started thinking about building a cross platform IDE, we had a couple of options. One was built a new WinForms or WPF, UI on top of Resharper. And you know how it goes that would be a project that takes ages and will never get completed. The other option was to essentially rebuild Resharper inside IntelliJ using Java and all the tooling there as well. Again, same problem that is a big rewrites, that’s taking 18 years of learning in Resharper, and replicating all of the features and bugs and edge cases and all of that in in IntelliJ. So that was not a good option. And we started experimenting with bridging the two by using a communication protocol to essentially have IntelliJ send the commands to your back end Resharper and vice versa. We tried a couple of things. They’re using a rest like approach where you have a request response whenever you click some In it would fire off to the server and then Resharper would respond and IntelliJ would do something with that. Their notes that didn’t work at all, or at least it worked. But it’s it felt it didn’t feel snappy, it didn’t feel like you would expect your IDE to feel when you’re working.

So we started looking into making that better and improving it. And that’s where we thought, okay, this view model approach may be a good approach to take. So we started building, essentially a third IDE in terms of a view model, where there would be no logic in that view model, but still all of the state management and all of the things that could fire between two sides of the equation, I think I alluded already to that a little bit, where if you have inspections, for example, in writer Resharper, can say, hey, this line, this column, this character, or you should show this inspection there. But at the same time, IntelliJ itself is also an IDE. So if you’re working in a razor file, for example, that combines HTML, and C Sharp Resharper may contribute to that view model. But also IntelliJ may contribute to that view model and essentially give you the best of both worlds the best of both ideas by just contributing to that view model. And based on whatever happens, where Resharper, or IntelliJ, can pick up an action that you click. So that protocol is there, we have been using it in writer for a long, long time. Now, it’s also open source. So if you want to explore, it’s pretty cool. You built the protocol layer using a DSL. So you essentially have a new programming language where you say, Okay, I want to have this class with this collection of items on there, you click a button that generates codes, it generates JavaScript for you, it generates C sharp for you, it generates Kotlin, which is a JVM language for you. And you hook it up into your application and magic happens, you can use the language that was generated to contribute to that model, and the protocol layer will take care of communicating between things. So that’s what we have in Writer. It’s been there for a long, long time. And when we started looking into into making pair programming possible with code with me, we thought, well, let’s maybe see if we can reuse this protocol because the protocol lives on a socket. And in writer, it lives on one machine on a socket. But what if we take two machines and just bridge over a network connection, whatever is going on, on that view model. So that became our peer group pair programming programming solution code with me, where essentially two parts of the equation run on different sides of the internet’s potentially. So that’s the technology we use there. And then we start thinking, Okay, we have this code with me, we already made this step of pulling apart a server in the clients where you can have one server, which would be the host of a pair programming session. And one or multiple clients could be a classroom, for example, connecting to that host. So we thought, okay, we have that, why not take this and make the hosts and attendants sort of running on a server without there being human interaction? And have you as someone who wants to work remotely just connect to that host that is running somewhere. So all of that is working on the same protocol that Ryder was built on top of.

Jamie

Right? Okay, so it’s it’s all right, as far as what you saying?

Maarten

Pretty much. Yes. Yeah.

Jamie

Oh, my goodness. So I can imagine that. Now, this, you may not be able to answer this, you may not want to answer this. But I can imagine that. I can imagine that. With JetBrains being like a distributed team, you might possibly be using this to develop it. Is that what’s happening? I mean, you may not be using the software, you may not be dogfooding Eropa. Are you just this is a color sort of question. I’m interested to see whether your your dog fooding

Maarten

happy to go into that. Oh, so yes, we dog foods, it depends on the person. So we are very liberal in what you can choose in terms of tooling you want to work with. So we have some people who essentially built from Master every morning and use that as their main ID to work on in IntelliJ team or in the writer team. You have other people just using stable. And we also use code with me, for example, if a developer on the team has a question about something, they jump into a pair programming session and have someone else join and and work on that remote development as well. We have a lot of the developers on the writer team, for example, work in writer just to do their developments also in IntelliJ, because of course, they have to work on the JVM version there as well. But as you can imagine, it’s a massive project. I think writer alone is 300 .NET projects. So it requires a lot of power. And maybe you’re working on a longer live branch that takes a couple of days to work to build. And we have some folks on the team actually We’re using remote development in space to have that one specific branch running where they can just connect using either IntelliJ or writer to connect to the server that is running there and continue working whenever there’s something to be done on that branch. Right.

Jamie

And this, this, what we’re talking about now is different to to space. So I’ve I know it is fleet is fleet different to space as well, just because we’ve have the two, it’s getting

Maarten

complex here. Sorry. So space is our one in one size fits all software development solution. Imagine it’s like GitHub or GitLab meets JIRA meets remote development with it’s a server side product where you can work together on things. And it comes with an orchestrator for these things. You have IntelliJ IntelliJ ecosystem, so to speak, WebStorm, PHP stormrider falls under that as well. That is the the existing ID, and then there’s fleets that is the new ID completely separate. It can also run on a remote development environment running in space, but fleet is a different ID in that case.

Jamie

Right? I see. And code with me is yet another thing, right allows you to do that collaborative remote development. So we’re not just talking about me sitting in front of a machine using another more powerful machine to do the heavy lifting. We’re talking about you and me working on the same code base that is perhaps on my machine, but you’re dialing in, right.

Maarten

Yeah, exactly. So code with me is the technology or feature depending on how you want to call it that we have in the IntelliJ ecosystem to work together on one code base. So we see teams and team members using it to work together on something to step through some problem that they may be having the back together and see what is going on. Do actual modprobe break programming as well, I know we have some folks having tried that’s working on the same thing where a couple of people just crunching out codes on one machine with the hosts. But they can all write code in other environments. At the same time, we see code with me being used in classroom environments, for example, where the teacher has the host privileges, and they can have the entire classroom follow along. Even during a debugging session, give everyone the opportunity to inspect variables and all of that that are in there. While it’s only running on one machine in that case, so that is there. Then remote development’s same thing, except the host is a server that has no human involved at all. Currently, the server in remote development can only have one client, which means it’s your server and you can connect to it. I think the idea is to also make it possible to have one server with multiple clients. So you can do remote pair programming or remote mob programming if you want to. And I think it’s not there by far. But I think that would be a really cool thing, where you can schedule remote developments sessions, for example. So imagine, every Thursday morning, between nine and 10am, we work together on a random problem. What you could do in that case is maybe use that orchestrator to spin up a machine by 9am. So that everyone who wants to join can just connect to it, the machine is ready, you can start working on it and play with it.

Jamie

I like that that feels like it would it would help like you said you mentioned about perhaps using it in the classroom or it. I like the idea of being able to sort of help with knowledge sharing, right? So we spin up some, some something to facilitate the video portion of me and you chatting away, right? Maybe it’s zoom, maybe scope, maybe it’s Google mate, whatever. And then, then you say to me, Look, here’s his just joined my code with me session. And we’ll walk through it and I will talk you through how the code all fits together, right? And then I can then say I get then like independently view I can be like, huh, but what is this God, but do and I can go off on my own lunch Exactly. And investigate things.

Maarten

And that’s actually a couple of the modes that are available in code with me and you can just switch as you go. So there’s a mode where every guest can just browse freely roam freely through the code base, there is a force everyone to follow you as a host where you can say, Okay, everyone, my cursor is leading. Whenever I click a new tab, whenever I go to a new file, you will see the same file and the same line of code that I’m selecting. So it depends on the situation, you can switch back and forth, it’s pretty much continuously. There’s also an interesting thing, in that it’s not only the code that you’re sharing in that case, you’re also sharing the full ID, which means that guests connecting to you using code with me could get terminal privileges as well. Now, of course, that’s something where everyone who connects and gets that privilege always tries to type rm dash RF to remove your root filesystem. So that’s why we don’t enable some things by default, but you can open it up so Um, if you’re teaching something where the command line is required as well, you can show students in such a classroom setup, what the Docker commands or the git commands on the command line would be as well.

Jamie

You see, you see, I like that I really do. Okay, so, so we talked about how space is this one big server solution that has everything you need project management’s got your tooling, it’s got all that kind of stuff.

Maarten

Is that something that I can do on prem? Or is it something that’s on on your servers, right? So like, if I’m, if I put my project manager or C#, CTO hat on? Do I need to build a server myself, or you’re going to happily sort of let me run that on some infrastructure, you spin up or something? Yeah, so space started off as a cloud solution. And actually, even at the time of recording, I think my colleagues are currently making the unprimed version available. So especially by the time the recording will be up, it will be available, where you can run space on your own infrastructure. Now, of course, base is quite complex, there’s good hosting, there’s all of the other stuff, there’s the remote development, you want to make sure that things are secure, and all that. So there are some requirements where you need either a Kubernetes cluster, you can actually try it locally if you use Docker Compose, but you will need a very beefy machine to run all of the components in that case. But essentially, we will require you to have a Kubernetes cluster ready to go with certain policies set up and all of that, but yes, it will be possible to run on prem.

Jamie

Excellent. I really liked that idea, too. Because like, I’ve worked with some clients in the past, where they’re like, Well, yeah, we’ll use JIRA, because, you know, we just go to atlassian.com. And, you know, whatever. We’re not sponsored by them. I’m just saying, that’s an example where everybody knows that one product, or, you know, we’ll go to as your DevOps and we’ll do it that way, or GitHub projects, or, you know, we’ll use Git lab or something, right. But then, but then we’ve got to go else, we’ve got to leave that ecosystem and go elsewhere, to get the code. And then we got to leave that ecosystem and go elsewhere to get the tools, right. And, yeah, just for simplifying things. I like the idea of just go to one place, and it’s all there, right?

Maarten

So yes, you can use space, completely all of the components that are in there. But if you want, if you’re using best of breed in your company, what you could also do is just use the remotes development or the remote orchestration parts, and combine it with whatever existing issue tracker you have. So you can mix and match however you however you please.

Jamie

Sure. Okay. So there’s, there’s a one, there’s a like a, I’m not sure about the phrase, but that’s like a one stop shop solution. Or those, you can pick the parts that you want and use whatever you like, I like that gives people the option, right? Yeah, exactly. I have worked with some clients where they’re like, yes, we’ll do that. But we want everything out, you know, 100%, under our control, or we don’t want to change this, because I can imagine exporting data from one tool and importing into another takes a lot of time, right?

Maarten

There’s that and also the the integration of all those tools. I mean, maybe you’re using slack in your organization. If you go look at the number of integrations with third party tools, there’s going to be integrations with I don’t know, pager duty to monitor uptime, there’s going to be integration with your CI CD to get built status notifications. There’s security across all of those different tools. And it’s a lot of things that you have to manage and make sure that if someone leaves the company or joins the company, they have access to everything. Maybe at some point, someone set up a connection in Slack, they leave the company and all of a sudden for a week, you get you no longer get C ICD status, notifications, things like that you have to take into account. And that is, of course, where this this all in one solution shines, where everything is just one thing that has all of those things out of the box.

Jamie

Cool, okay. Well, you know, this, this has been a very interesting conversation for me, because like I say, I am all about that remote development animal about speeding up the adoption of or the onboarding of a new a new member of the team, right. So for instance, with the with the apprentice that we have, you know, after sourcing the hardware, it was a case of, well, they’re going to be running Windows because they’re running Windows because they need Visual Studio, whatever it was, you know, reformat the machine install, I literally, I sat next to my work machine, and I was like, okay, run this script that will install all the apps. And it was doing it for two or three hours, just installing apps silently and I’m working away. They finally it’s like ding done. Excellent. So I log in as the apprentice and none of the apps are installed. Gotta run the run the script again, because I didn’t do it as overall users, you know. So that’s another two, three hours of just sitting there watching our progress, but so I like the idea of being able to, in effect once you’ve set it up effectively push a button. And you’ve got all your tools. Right? I love that.

Maarten

Yeah, absolutely. There is a thing, it’s it makes development so much nicer. Actually, space. The orchestrator that we have also has a massive SDK available, where you can, essentially everything that you can do through UI, you can also do through the API. And I’m working, I mentioned, I’m a developer advocate, but also developer as part of that. So I work on that SDK for our, for the dotnet. side. So if you want to integrate with space using dotnet, you can log your bugs with me. But the interesting thing is I use remote development there. Because to generate part of the code against the latest API specification, we have just a lot of hoops that I have to jump through in terms of making sure that I’m authenticated that I get the right set of API’s to access and all of that, and I use remote development there and space injects the secrets for me into that environment. So I don’t have to care about that. When I switch machines when the gears rotate, when whenever something like that happens, I can still just open that remote development environment and start working on the SDK there. Which is mind blowing in, in my opinion.

Jamie

Yeah, that’s, that’s one thing we didn’t really talk about was secrets, right? So that might be your connection strings, your API keys, your whatever’s managing those is I mean, yeah, we’ve, if we’re in an ASP .NET Core context, yeah, we’ve all got app settings, JSON. But then you do get add dot, and whoops, you’ve just added source control. Yeah, you’ve got user secrets. But then, like you say, when you move machines, you got to take that JSON file with you. Yeah,

Maarten

exactly. Yeah, that is there in space, for example. And oh, get PATA has the same thing where you can set environment variables and environment secrets. And you can load those into the IDE. A small tangent here for listeners who may be using one password, that’s something that I discovered last week. They also have something like that. So if you don’t want to work with remote development, or anything like that, you can actually have passwords in one password and loads the secrets on your development machine from that thing as well. Just as a small side note there, I was pretty enthusiast about it.

Jamie

Yeah, that’s pretty cool. That’s pretty cool. Yeah. Wow. Yeah. And then with with things like that, you don’t have to worry about who has the keys to the castle when they leave, right? Because so as an example, when I stop working on a project for a client, what I do is I’ll generally wipe the machine and start again, right? Because all of the tools that I use cash, everything, including will, I would hope not including all the secrets, but then I’ve also got all of the secrets on the machine, wipe the machine, then, theoretically, unless I go to a, like a data recovery company, I’ve no longer have any of that information. Using something like these remote development tools. I don’t need to do that. And I don’t need to worry about that. Because it’s all on the server, right? Yeah, exactly.

Maarten

And not only connection strings and things like that, but also the source code itself. I mean, yes, you can run a zip on the remote server, and then somehow get that zip file of all of the sources to you. But during the day to day work, you probably won’t be doing that. So what you have is that the source code lives on the server, you leave the company or whatever, you can even take the laptop, there’s nothing on your laptop, except that at some point, you connect it to some remote development environment that you now no longer have access to.

Jamie

I like it, I like it. Well, Martha this, this conversation has really enlightened a lot of stuff in me. And I’m very excited to check it out. All of the different things that JetBrains have got cooking up, especially space. I love this idea. But so what about getting in touch with you or learning more about all of the different stuff we’ve talked about today? If you got some, I can see. So for for the listeners benefit. We have this document that we have backwards and forwards. I’ve already got a bunch of the links. So whatever links you’re about to shout out, they will be in the show notes. But what are the some of the ways that people can get in touch with you or learn a bit more?

Maarten

You can find me on Twitter, and that’s the place that I’m active on. I tried Tik Tok last week, but I gave up so that’s that’s not gonna work. So yeah, you can reach out on Twitter, I have a blog. The company has blogs for every separate product. There’s the landing pages. And we try to give you as much information as possible on how to get started for many things, including writer including remote development with space for example, as well. There’s some background blog posts that you can find as well. So if you’re interested in learning more about the technology, nothing to the very detailed but high level how everything fits together and how everything works together. Then you will find those things as well. So definitely check out the links in the in the show notes.

Jamie

Awesome. Thank you ever so much. Well yeah like as a thank you for this wonderful, enlightening conversation, and I can’t wait to get my hands on space and give it a try. Because it sounds like it sounds like it’s going to be really, really simple for throwing together these these these applications. And especially if you’re managing a large team of developers, maybe they’re all working on different projects. Seems like it’s kind of like the the next big step right.

Maarten

I think it is definitely the next big step. And I think not only if you don’t look at JetBrains, but look at other competitors, you will see similar flows of companies going the remote way and getting everything together and getting essentially the codes and the resources off of the developer machine and onto something more powerful and more secure.

Jamie

Excellent. Well, like I said Maarten, my thank you ever so much for this conversation.

Maarten

Thank you for for having me.

Jamie

Hey, you’re very welcome.

The above is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Wrapping Up

That was my interview with Maarten Balliauw. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at dotnetcore.show, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/review for ways to do that - reach out via out contact page, and to come back next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places