WEBVTT

00:00.250 --> 00:02.926
You. Hello and welcome to the let's Talk.

00:02.948 --> 00:07.914
Azure Podcast with your hosts, Sam Foote and Alan Armstrong.

00:08.042 --> 00:50.380
If you're new here, we're a pair of Azure and Microsoft three six five focused It security professionals. It's episode nine of season four. Alan and I had a discussion around Microsoft Deadbox recently. It's an Azure service to quickly spin up and manage development environments in the cloud. Here are a few things that we covered. What dev boxes can be useful? How you can manage them? How devboxes can streamline your development workflow? And what are the costs associated with running dev boxes? We've noticed a large number of you aren't subscribed. If you do enjoy our podcast, please do consider subscribing. It would mean a lot for us for you to show your support to the show. It's a really great episode. So let's get started. Hey, Alan, how are you doing?

00:51.010 --> 00:53.454
Hey, Sam. Not doing too bad. How are you?

00:53.652 --> 01:09.170
Yeah, good, thank you. Yeah, really good. It's summer. We had a bit of sun this week, which was nice for our very rainy start to August that we had. So, yeah, it's feeling a lot more summery here in the UK.

01:09.910 --> 01:19.750
Yeah, definitely. This week's been a lot better. I've been off and I so it's been a nice week off. Previous week was terrible.

01:20.650 --> 01:22.070
Weather wise, hopefully.

01:22.650 --> 01:23.400
Yes.

01:24.650 --> 01:31.980
You picked a great week, to be totally honest with you. So, Alan devbox, should we jump into it?

01:32.510 --> 01:33.594
Yeah, sure.

01:33.792 --> 01:34.154
Okay.

01:34.192 --> 01:42.494
So should we start with sort know, why would you need a development environment in the so, you know, it's probably.

01:42.532 --> 04:50.060
Worth starting from how a software is developed and the sort of software and third party systems that you might need. So if you're a developer, you may have things like an integrated development environment. Think Visual Studio. Visual studio code. And then you'd obviously have the code that you would write for your application. Maybe as example that we use like a Web application developer or something like that. You might have your integrated development environment. You might have a database that you need to run. You might also have all of the other frameworks SDKs that you need to actually develop that software. And what can happen is just to get that software installed can take up a lot of space on your machine. It can also take a lot of memory. So Ram inside of your machine to run as well. That's one part you're maybe constrained by local resources. Maybe you've got a thin and light laptop. Maybe you don't have oodles of Ram and CPU performance. Also, the configuration of all of those tools to work together is complex. It can take with a fresh machine, it can take a few hours to get all of that. Maybe even more than that if you have a complicated sort of tool chain and an application. So dev boxes hosted in a cloud service can make a lot of sense. There's sort of infinitely more compute there. There's larger instances that you can sort of access remote into. It's a virtualization technology. So snapshotting, restoring, modifying, rebuilding is all possible now. That's all possible locally as well. You can run your development environments and say HyperV and virtualize them so that you can get that snapshotting and and everything that you need there. In some organizations as well, it may be that you want to save the time in each member of the team building their own development environments. Having a standardized sort of image for your development environment can be really advantageous. Let's say that a new team member joins the organization. One part of their sort of onboarding process is to get their development environment set up. It maybe could be a brand new application that they're working on, a brand new business that they're working with, and that can take some time. So just the learning to get all of those bits together, there could be gaps in your documentation because you don't change your laptop that often. So those kinds of challenges can be overcome with a cloud based system.

04:52.030 --> 05:23.220
Okay, so as well is there some scenarios where you may be working on a couple of projects on different languages and they won't sometimes configuring? Those environments have to be you almost have to have new machines for each sort of type of build because you don't want to contaminate or kind of contaminate bring additional things in that maybe the general repos don't need, I guess. Is that another reason why to have something in the cloud?

05:23.670 --> 08:16.970
Yeah, just to work through. Sort of a real life example of that happening in the past as Microsoft moved from the net framework over to Net Core, and now what we know as Net Standard, or just Net as it is today. You may be going through a stage of porting your application from an older framework version to a newer framework version. And having both of those sort of installed and jumping between them can be complex. I mean, there is tooling and there's support in some of those newer frameworks to support that because that is kind of a common developer scenario. But you are completely right. You don't know how different SDKs frameworks and software are going to interact with each other and there's that to deal with. Another area that I've sort of missed, I think as well, is that having a separate machine to develop on, you can have a very different security policy applied to that machine. Right. We kind of know that developers need local admin because of all the various amounts of software that they need to install. And even when they run certain SDKs and frameworks, they need to have admin privileges to do that. So developers can be on a security lens, developers can be like a really sort of high profile target because they work with a lot of intellectual property and also they generally tend to have admin sort of level permissions to their boxes as well. So they're installing loads of different software and that is when threat vulnerability management then comes into it. Are all those frameworks and SDKs being patched regularly with their cycles and all kept up to date and X, Y and Z. So sort of shifting that machine into the cloud, I mean, ultimately you don't take away that requirement to have admin privileges. But for instance, where developers read their email is a completely segregated system to where they actually do their development. So you get that there is an element of isolation there as well. On the basic scenario to explain it. Basically you're remote desktopping into another machine. So there is still a way that if somebody had access to your machine that they could watch what you were doing and that side of things. But it is a completely isolated environment from your local machine.

08:17.790 --> 08:43.330
Yeah, it would just be reducing risk there because like you said, there's still a method to get there from an attack path perspective, but we're just reducing or making it more difficult to get to that point. And as you said, compromising that machine might not then compromise the IP and things like that. It's on another machine.

08:44.230 --> 09:10.090
It might be from a sort of an IP loss perspective and a data loss prevention perspective. It might be that you would disable, copy and paste in and out of the dev box right. To start to protect against unintentional data leakage for insider risk. Right. There's other protection mechanisms there as well, to have that completely isolated environment.

09:10.750 --> 09:54.730
Yeah, absolutely. And what network it's coming out from and things like that to make sure it's like an internal network rather than big because we're hybrid working now. And I think developers were kind of already doing that kind of most of the time, I think, anyway. So, yeah, it just moves. Yeah, there's different angles there. And like you said, being in the cloud means you've got technically as much resource as you need to use for what you need, providing you're willing to pay for yeah, you don't have to pay upfront for the compute. Maybe if you've got like servers and stuff like that, you need to buy on prem. Okay, so, Sam, what is devbox?

09:56.270 --> 12:01.620
Okay, devbox in a real very sort of basic lens is a virtual machine that is running in Azure that you can remote into. And I'll talk more about management later on, but effectively a developer, instead of running all of those pieces of software, builds X, Y and Z on their local machine. They would remote into a machine inside of Azure that does require them to be online at all times because they need an active Internet connection to do that remoting into that environment. But what devbox really gives you because in theory you could just create a virtual machine in Azure right. And RDP remote desktop into that machine in a very simple scenario. But what devbox really does is it sort of layers on building, sort of SKUs, cost control, and sort of out of the box configurations with different images and pooling of dev boxes. So it's effectively like a management layer. On top of that, there is also some differences with the pricing as well. But essentially it allows platform engineers to build sort of the organization policies, network configurations and security settings. It also allows administrators of the projects, the development projects, to sort of come in, look at cost control, the development experience, and to build that project structures out. And then from a developer perspective, they get the ability to just double click on a box, log into it and start working. If it's a fresh box, it can be pre configured, sort of out of the box for them.

12:03.350 --> 12:09.880
Okay, cool. So it kind of sounds a little bit like Windows Three Six Five.

12:10.490 --> 12:27.546
Yeah. So if you think Windows Three Six Five is is that exact same model, really, but just for endpoints, I'll call them standard users, really. I suppose you can use it for privileged workstations and bits and bobs. Right?

12:27.728 --> 12:33.040
Yeah. But it's more subscription based, isn't it, and sort of one per user kind of thing.

12:33.410 --> 12:58.790
Yeah, that is true. And I suppose the SKUs that are available are very different. The starting SKUs for devbox are probably the maximum SKUs for Windows Three Six Five. Right, from that perspective, but yes, very similar concept for that remote endpoint scenario.

12:59.930 --> 13:04.230
Okay, so how do you manage the boxes then, the dev boxes?

13:05.050 --> 17:29.260
Okay, so there's a few steps that you would go through to get a developer into a dev box. Now, it really depends on the size of your organization because when I talk about these three different sort of roles and responsibilities that I'm going to go through, it could well be just one person as well. So it's not absolutely massively onerous to do that. But what you do is you start off by creating a dev center. And what that really is, is it's a way to sort of a container for all of the elements of devbox. So when you want to go and manage your dev boxes, you go into the dev center in the Azure Portal. You would configure the network connection so how the machine communicates to and from the Internet effectively, and other potential resources. In Azure, you would create a dev box definition. So that is sort of defining the SKUs, the image that's going to be deployed onto that box as well. So you create these definition files and then what you then do is you create a devbox project and that might also represent your actual project inside your organization. So it could well be that for a given development project, you might have multiple dev boxes, maybe for different people, maybe you might have different dev boxes for different parts of your application. Maybe your application, some of your engineers work on the web application, some people work on the mobile applications, other people work on the marketing website and other people work on the retail store. There may be different projects in sort of your overall business. Now, these types of tasks are really a platform engineer's role. So platform engineering is really there to help manage the infrastructure and the configurations of machines in the cloud. Now, the massive benefit for platform engineers is that this is like a management layer for them. They're not deploying, as we've spoken about before, but they're not deploying virtual machines. Managing access into it, maybe setting up VPNs or port forwarding or peering and then installing all the tool chains and bits and bobs like that. This is really wrapping all of that experience up into a service. There's also sort of organizational policies that go in place there and security settings that can be applied to these virtual machines as they are actually deployed. Once you've created your project, you'll also create your pool of potential dev boxes. And then once you've created those, you would then provide access to the project. So there's an element of RBAC inbuilt into here so that you can enable access to certain developers and also other project admins as well into those projects. And then really, once that pool is set up, the developers can then access, create dev boxes, spin them up, and then they can use them basically from there. So really you've got platform engineers sort of providing devbox in the infrastructure. You've got project admins sort of sitting in the middle there configuring the potential projects. They've also got cost control functionality, so they can just say what SKUs can be spun up, which ones can't, and really they can help to customize the tool sets that get deployed onto these boxes. And then the developers, then they don't really have to worry about any of the infrastructure or anything like that. They can just simply spin dev boxes up in line with those policies that have been defined for them.

17:31.230 --> 17:47.140
Cool. That sounds really simple, doesn't it? Especially for the developers. They have to worry about knowing Azure from a virtual machine perspective or anything like that, just in effect, power them on or get them to build, let them provision and then use them.

17:49.350 --> 18:28.830
And it's probably just worth calling out is we'll talk about it more when we come to pricing, but there's built in auto shutdown hibernation in place here because there is a consumption aspect, pricing to DevOps, DevOps, devbox, sorry. So you can do things like schedule shutdowns in the evenings to turn those machines off and that's all integrated into Windows as well. It pops up and says, hey, this is going to be shut down. And you can delay it actually from the box itself. So there's a lot of really powerful integrated automation there as well on a day to day basis.

18:30.050 --> 18:52.198
Okay, cool. So I think these are, if I remember, these are like Windows Ten, windows Eleven devices endpoints rather than because you want to be able to verify them, you don't want them to be a server sort of OS kind of thing. So they can obviously be managed with Intune. But can you use custom images or settings for the box?

18:52.364 --> 19:55.420
Yep. So you can use the sort of standard image library from Azure. You can also build your own images. So it may be that you would probably spin up a virtual machine, configure it how you wish, and then make a quick start image from it. I would have thought if you've got a singular box that's there. What's also great is that these machines have direct access to other infrastructure in Azure is probably worth talking about because your development teams might run from an actual shared development database, for instance, where they can all sort of interact with it. You've sort of got a ring fenced sort of network environment there as well. But yeah, so we've got policies, we've got management within Tune and then we've got images and settings for the actual dev experience sort of built in to the product.

19:57.150 --> 20:05.310
Okay, cool. So you kind of mentioned about talking to other resources in Azure and things like that. So what networking options are supported?

20:07.330 --> 22:03.010
Yeah, basically as you set it up, you can create a network connection inside of the devbox center, which can be a connection into a VNet that you may control. It's going to do the same thing as Windows 365 and Azure Virtual Desktop. It's going to handle your connection, broker your connection into the machine even with that VNet peering in place. And as you've sort of spoken about Azure ad and hybrid Azure ad join within, intune is fully supported. So you're really getting the ability to connect into that private networking that you've potentially got in Azure to really silo these devices away. It might be that you would look to create a separate VNet potentially for just development that is completely isolated because of the, I would say more dangerous, day to day dangerous activity that's potentially happening on those dev boxes, running potentially untested non production code. You may wish to completely segregate all of that infrastructure away from anywhere else effectively. Right. So this will give you the ability to do that. These dev boxes aren't running potentially in the same networks inside your organization on the machines next to other end user endpoints. So that's really powerful from that perspective for isolation and segregation.

22:04.470 --> 23:17.994
Yeah. Okay. Having the ability to potentially restrict the Internet access for those devices as well to limited to development scenarios. So you don't have to, like you said, stop email, things like that. Because they're connected to a VNet that's maybe got a firewall on the end of it, separating it so that, like you said, they're running code that then can just be in that environment and they can access all the resources directly, like they would potentially or like the services they're building would do in Azure. So maybe if you're building, like you said, a web app, and it's talking directly to the SQL over a private endpoint or via the VNet, they can in effect prove all that sort of stuff works as well. Not that it should be too much difference, but it's one of those extra things that you can check before doing it. Okay, so I guess they're out there. Developers are using them day in, day out. Can we track their usage, make sure they're being used? We haven't got resources sort of left powered on. I know you said there's some auto shutdown, things like that, but I guess that's if some of it's configured, yes.

23:18.032 --> 24:42.550
So there's diagnostic settings built in. So there's a completely separate table. I can't remember the name of the table that's created. I think it's Dev Center diagnostic logs, I believe, which is completely sort of segregated. There's various different operations that are actually tracked inside of there and the results of those operations. So you could feed that into another system to monitor that day to day to look at the access that's happening there. And you've obviously got the endpoint analytics that you can pull from those boxes as well. So it really gives you a as we've spoken about, you can potentially isolate that environment, pull the logs from it, and really see what's happening in and out of that environment sort of in near real time, basically. So yeah, that is supported out of the box because these machines, they could have your most sensitive intellectual property on them. Right. You know, they are it's, it's sometimes scary the amount of value that are placed on, on these workstations. Right, so so having that visibility and that segregated access is really powerful.

24:43.850 --> 25:30.870
Yeah, well, as you said, the intellectual property being stolen, things like that is one thing. But also if we think about supply chain attacks, just a little bit of malicious code just dropping itself in there, and you not noticing seeing those kind of things happening on those boxes. I mean, that is, say, worst case scenarios here of that happening, but we've seen it in the world, things like solar, wind, things like that, where it's been put into the software. So it's one thing to sort of keep at the back of minds and things like that. Okay, so we kind of talked about it a little bit, but how much does devbox cost? What's the pricing sort of mechanisms?

25:31.690 --> 26:05.810
Okay, so I think I will probably start with the SKUs, really, and just explain sort of how the sort of level that they start at. So the worst skew, I'm using Air quotes that you can't see it's eight virtual CPU cores, 32GB of Ram, and 256 gig of storage is the worst SKU. The best SKU is 32 virtual CPU cores, 128GB of Ram, and two terabytes worth of storage.

26:06.630 --> 26:07.090
Wow.

26:07.160 --> 26:25.382
So we're really talking about very high end potential resources now. I don't know of, let's say, a laptop that has 32 CPU cores. There must be maybe there's workstation laptops that I don't know about. I'm guessing there is.

26:25.436 --> 26:28.170
They're probably pretty heavy. Heavy.

26:28.510 --> 27:36.960
Not very portable for Alan on the train. Yes, Alan. So really you've got the flexibility of being able to sort of set your SKU for your in your devbox definition, you'll set your SKU to what it is that you want to run your development environments from. Some people may decide to run their development environments at a lower SKU to see what potential performance bottlenecks or impacts there are potentially. So there's different strategies like that. There's a range anywhere from 816 32 virtual cores from 32 gig of Ram up to 128GB of Ram. There's absolutely plenty of performance there. And I think it's probably worth noting that different projects with different roles can have different SKUs depending on what they need. It may be that one of your applications requires huge amounts of memory, as an example. Others may be more CPU bound. So there's things to think about and to change there.

27:37.810 --> 27:50.370
Okay, just before you go, not so Microsoft has specified SKUs that you're allowed to use, rather than it being any type of VM on Azure.

27:50.870 --> 27:52.740
Yes, that's correct. Yeah.

27:53.350 --> 28:14.970
Okay. So it does definitely kind of sound like AVD, where they're specifying the SKUs that you're allowed to use. The differences. Like you said, it's well, I guess we'll talk about in a minute. But with Windows three six five, you buy it as a subscription, so it's paid for, in effect, monthly. So how do you pay for these ones? Is it the same thing?

28:15.120 --> 28:52.066
Probably one thing to call out, actually, which is slightly different with the SKUs as well, is you can't mix and match virtual CPUs and memory and storage. So if you have eight virtual CPU cores, you always have 32 gig of Ram. The only difference between the SKUs is the storage. 16 virtual CPUs is 64GB of Ram, and the only difference is the storage. And then 32 virtual CPUs is 128GB of Ram. So, you know, like in Windows three six five, you can really tune I want more cores, less Ram. Can't you do it in that one there's?

28:52.098 --> 29:08.140
A little bit yeah, it's still a little bit sort of rigid. There is more flexibility. So you're kind of saying there's three CPU and Ram combinations, and then it's then disk space changes.

29:08.830 --> 30:26.866
Yeah, but like you mentioned, no picking of the actual SKU in Azure or anything like that. That's all handled Microsoft side. Yeah, and the actual pricing is interesting because it's like a capped consumption pricing model. So I'll use the quotes lowest SKU as the example. So eight virtual cores, 32 gig of Ram, and 256GB of storage. Now, the hourly compute on that box is I'll do it in dollars one dollars, 69. The monthly storage cost is $21.47 for the 256GB of storage. Okay. But I'll ignore that because that obviously needs to be factored into your pricing. But that's not what affects this consumption limit pricing. Now, what's interesting is the maximum price for that SKU per month is $156. Okay? And what happens is once you've used it for a certain amount of once, you get to let me just work that out. I'm just going to fire up my.

30:26.888 --> 30:29.526
Calculator because I'm 156 hours or something.

30:29.548 --> 30:34.614
Isn'T it divided by one dollars, 69, 92 hours.

30:34.812 --> 30:35.222
Okay?

30:35.276 --> 31:23.640
Right. So once you get to 92 hours, you're then capped at the $156 price point. So if I divide 92 by 4.4 for the average number of weeks in a month, you get to basically 21 hours a week. So if you were to use it, say, 35 hours a week, then anything over 21 hours a week is just going to be it's not free because you've already paid for it, but it's going to be capped at that rate. So I think this is beneficial for both sort of ends of the extreme. People that use these machines, 24/7.

31:25.770 --> 31:26.098
It'S.

31:26.114 --> 32:54.770
Going to be great because they are capped at $156. Right. And $156 for eight virtual CPU cores and 32 gig of Ram is a pretty good deal because these are Windows Ten, Windows Eleven endpoints. It probably should also be known that you need to provide that user needs to be licensed for the operating system. That's the same as windows. Three, six, five. Right. You need to be licensed correct for that. So operating system is a separate layer. On top of this, we're just talking about compute at this point. You're looking at a capped, what was it? 92 hours of compute. But if you don't use it for 92 hours, right, there's potential for certain developer boxes to only be used in scenarios. You might have a QA box that you run up that you test on. Maybe you download your production releases on it, and you run through a test suite. You boot it up potentially, and maybe you go through that process manually. Maybe you can't fully CI CD that testing process. I'm just using some examples. But basically, up to that 92 hours, there is just a per hourly compute cost for that infrastructure.

32:56.810 --> 33:22.540
Okay? So when this was in preview, I think when we first looked at these, we were worried about it being the full price and there not being a cap. We couldn't quite understand in some sense what their usage was, I think when we were first looking at why because it seemed quite expensive, I think. But with that cap, it kind of seems quite nice. Again, I think.

33:23.070 --> 34:15.790
Yeah, exactly. And it's that, you know, because basically it gives you the best of both worlds. Because if you do use it for, say, an unlimited amount you can't use it for an unlimited amount because only a certain number of hours in a month. Right. So in theory, it's capped by time. But if you do use it a lot, I don't really think $156 for that instance is potentially that expensive. I mean, you could always make the argument of capexing a laptop and then using it for four years, but an eight CPU core, 32 gig of Ram machine is what, two and a half, maybe more than that, if you're going workstations.

34:16.290 --> 34:27.042
Yeah. And it's not just that though, is it? It's the WAV as it breaks scenarios, things like that. You got to buy another one to replace it. We got the downtime, probably worth calling.

34:27.096 --> 34:38.146
Out sorry, that you can connect to it with a browser. Just like windows. Yeah, you can connect to Windows three.

34:38.168 --> 34:39.890
Six, both AVD and Windows and AVD.

34:39.970 --> 35:29.830
Yeah, you can do those both. I saw the same thing. It's not the same thing, but it is the same thing. So there is that business continuity perspective as well. Right. Laptop dies. In theory, you could connect to it from an iPad. You could connect to it from another spare on the shelf inventory laptop without having to rebuild everything there's that part of it, yeah. Then just probably worth calling out the licensing. So you're looking at F three, E three, A three, and above E five, A five, licensing business premium. And I'm not sure what else there would be, but effectively where you get that is it Windows Enterprise license? Is that what the benefit is called?

35:29.980 --> 35:48.186
Windows enterprise or Windows for business. If you're using the business premium side of your subscription scooter to give you, in effect, still around, but the VDA license in effect to allow you to remote onto another machine from an yeah, exactly.

35:48.288 --> 36:19.270
So, you know, and it will know infighting in the organization where certain people have better laptops than other people. Right. Everybody's got the same right. It's easy peasy at that point. Definitely a more modern, I would say advanced development methodology and system. But it's definitely a very modern and well thought out approach to those potentially sensitive workstations.

36:20.570 --> 36:53.742
Yeah, it definitely sounds good. I mean, when we first seen it, like we said, it seemed from a management perspective seemed really good, pricing seemed a little bit high. But as you just said now it seems really good now. And yeah, it's probably worth calling out that the broker part of it is in effect, azure Veg Desktop, AVD, Windows three six Five, they're all using that same technology, same brokers, because it just works, doesn't it? So why rebuild something different? Just jump on the same service.

36:53.876 --> 37:50.274
Yeah, and the underlying tech might be the same, but the management planes are very different to all of them. Right. They're very specifically focused into their actual use cases. I should probably just call out the maximum SKU monthly cost, because that's also. Sometimes exciting as well. So 32 virtual CPU cores, 128GB of Ram, two terabytes of storage. Your monthly storage cost is $171 for two terabytes of, I assume, premium SSD, and your hourly compute is $6.74, capped at $710 a month. So if you have a development need that requires 32 virtual cores and 108 gig of Ram yeah, there's a skew there for you as well. Slightly eye watering at that price, but fingers crossed you're not running it.

37:50.392 --> 37:53.380
Can you imagine the cost of a physical device, though?

37:55.690 --> 38:25.340
And that's it. What is that? Is that Mac studio? Probably, I would have thought, and other probably high end workstations. Right. And you're probably talking I don't know, actually. I don't know those sort of crazy high numbers, what the ROI is on both sides. Right. It might be actually the more Ram you put in per gigabyte, it becomes cheaper. I don't know.

38:25.950 --> 38:41.490
Yeah. I guess in some of those boxes, though, if we're thinking it's going to be more of a desktop than a laptop, then you're also stopping yourself from being mobile. I mean, yes, you can remote that machine, but then, like you said, you got to put in VPNs and everything to jump on all the software to jump onto it, at least.

38:41.640 --> 38:57.400
Yeah. And it's your responsibility, like all of the infrastructure and all the layers in between. This is Microsoft providing it to you as a service, so it's for them to worry about the uptime of it.

38:59.310 --> 39:06.502
Okay, cool. So is there anything else you can think of around devboxes? More devbox?

39:06.646 --> 39:37.350
No, I think it's going to be up to an organization to work out the ROI, the risk reduction, potentially the reduction in management and overhead, whether it's going to be worth it for them, I think for the repeatable environments and development experience, I think get massive savings there just straight away. And being able to change your SKUs and decide your performance is pretty powerful.

39:37.930 --> 40:08.798
I guess, as well, if anybody wanted to try it out. It's relatively simple. Not necessarily. It is simple to kind of set up, but there's no upfront cost to get it set up. You can start using it and paying that one dollars an hour, turn it on, set up all the configuration, then get a dev or get someone to jump onto a box, see what it's like, see what your worst case is. $156 for one box. If it ran for a month, you.

40:08.804 --> 40:16.500
Just put the order nice on it and you'd shut it down. Right. Just like you deallocate a virtual machine. It's the same concept there.

40:17.350 --> 40:17.762
Exactly.

40:17.816 --> 40:21.140
In very low barrier to entry. For sure. Definitely.

40:22.310 --> 40:55.054
Yeah. Cool. Okay. So it's probably worth because we did say around this, that it's very similar to AVD and Windows Three six Five. So if you're sort of interested in some of those sort of that technology, it's probably worth jumping back to our season three, Episode 20, where we did an AVD versus or AVD and Windows three six five comparison now thinking we should add devbox into that into that mix as well.

40:55.092 --> 41:16.740
Yeah, to be fair. Well, actually, you could say that AVD would be quite a good other technology to compare this against. Really. Right. Because if you do need SKU, flexibility and images, AVD can also do quite a lot of that, can't it? If you can provision that.

41:17.110 --> 41:37.498
Yeah, I think it's a blend of the two, though. I think it's kind of taking 60, 80% of the management away from you, but giving you the flexibility to be consumption. I think it's that sort of mix. I think it's like the happy place for this scenario at least, is it.

41:37.504 --> 41:40.540
The goldilocks, they're just right.

41:43.010 --> 42:03.200
Because you haven't got to manage the hosts and everything in AVD, give someone a SKU that's only one per. What? You can get more than one per user, but they have to have different SKUs in effect, and you have to pay one month at a time, three months at a time. It's not just like you said, turn off, turn on kind of thing.

42:04.610 --> 42:09.270
So Alan, it's your episode next. What are you going to be covering?

42:11.050 --> 42:56.054
So I'm going to cover what Microsoft recently announced with the rebrand of Microsoft Entra or Microsoft or Azure ad being now called Microsoft Entraid. As part of that coming out, or that announcement, they announced the Microsoft Entra Global Secure Access, which is quite interesting about how you can secure your endpoints and how they access the internet wherever they are. It's kind of similar to a secure web sort of gateway kind of thing. So I'm looking at it, it's very new to me because it's just come out, but I've been setting it up and yeah, we'll talk about it.

42:56.172 --> 42:58.600
Okay, great. Yeah, sounds really good.

43:00.330 --> 43:15.062
So did you enjoy this episode? If so, please do consider leaving us a review on Apple or Spotify. This really helps us to reach more people like you. If you have any specific feedback or suggestions, we have a link in our show notes to get in contact with us.

43:15.196 --> 43:19.480
Yeah. And if you've made it this far, thanks very much for listening and we'll catch you on the next one.

43:20.050 --> 43:22.890
Yeah, thanks for listening. See ya. Bye.