As developers we always seek to have the most efficient environment, and that often means buying a high-end laptop. We're going to see in this post that using VS Code Remote Development with Azure can provide a much better environment, for a lower cost.
I believe this is a revolution for consulting companies and freelancers, and that this could change the way we work in the future.
But let's start with a story!
The Surface Go, an awesome machine for developers?
I currently bought myself a Surface Go for my own personal use. This was before I worked at Microsoft, and in fact is totally unrelated to my work activities. My reasons were that :
- It's extremely light and small
- It's very cheap, on Amazon there are always discounts and you can get them for less than $500
- It has Windows 10 with its applications store, including Netflix (a must-have for anyone with kids, as we all know how those offline "Paw Patrol" episodes are useful when traveling)
- It has a UBS-C port, so I can just plug it into my monitor I have for work (Dell UltraSharp 27 - U2719DC) and everything works out-of-the-box
Very important note : there are 2 editions of the Surface Go, use the high-end one. Not only do you have double the RAM and disk, but also you have a real SSD disk which is much faster.
Of course, as a developer, I'm also using it to code, so the question is : how good is this for coding ?
My development setup
I set up everything using the awesome Chocolatey package manager, including :
- AdoptOpenJDK JDK distribution.
- NodeJS.
- Cmder terminal emulator.
- Visual Studio Code Insiders, which gives daily builds of VS Studio Code, and is the way to get access to Visual Studio Code remote extensions at the time at this writing.
Initial performance numbers
As the lead of the JHipster project, I'm of course doing those performance tests with a JHipster application, but there's nothing really specific to JHipster here, so they should be the same for about any Java process, or even any process that uses quite a lot of CPU, RAM and disk.
I created a simple project at https://github.com/jdubois/simple-jhipster-app, which you can test on your own machine easily :
- Clone the project :
git clone git@github.com:jdubois/simple-jhipster-app.git
- Run the Maven wrapper :
./mvnw
From a performance point of view, this doesn't look very good :
- Maven takes a long time to run
- Spring Boot starts in 13.5 seconds
Let's see how we can improve this!
Surface Go vs. Surface Book
Thankfully, for work I have a mid-range (core i5) Surface Book, so it should be better with that hardware, isn't it?
I've installed the same setup on this machine : starting the Spring Boot application takes now 12 seconds, instead of 13.5 seconds! What we are doing is a bit dependant on the CPU, but most of our problems are probably I/O related, and both hardware have the same memory and probably a similar SSD.
So, first interesting lesson from a cost perspective : buying a $500 Surface Go is a very good deal here, as it costs a quarter of the price of the Surface Book, and is also quarter of the weight in your backpack!
Using VS Code and removing Maven
Let's open the application using Visual Studio Code Insiders, and install of course the "Java Extension Pack" from Microsoft.
As Spring Boot applications are also normal "Main" Java classes, it is possible to simply run the application by running its main
method, in the SimpleApp
class. It's much easier than running Maven, but also much faster. And you can also debug the application with one click!
We are now gaining the Maven start-up time, but the application still starts in 13.5 seconds.
Using VS Studio Code Remote Development
Open up again Visual Studio Code Insiders, and install the "Remote Development" extension from Microsoft.
This will allow us to work on a SSH machine, that will be provided by Azure.
Let's create the virtual machine on Azure :
- Go to the Azure portal.
- Create a new virtual machine.
- Choose the default machine type, D2Sv3 at the time of this writing. This costs $0,1120 per hour.
- Add your public key on the first screen, and in the networking screen, don't forget to open the SSH port in the
Select inbound ports
drop-down list. - Keep all the other options by default, and create the machine.
Once the machine is created, let's configure it with our usual working environment. I personally have my own setup script, which you can of course reuse :
- The script is available at https://github.com/jdubois/jdubois-configuration/blob/master/install.sh
- Login to your new Azure virtual machine using SSH :
ssh username@machine-ip
(please note you can find your machine's IP address on its "overview" page on the Azure portal), and become root :sudo su
- Once you are logged in, run my installation script as root :
sh -c "$(curl -fsSL https://raw.githubusercontent.com/jdubois/jdubois-configuration/master/install.sh)"
Congratulations, your Azure machine is ready!
Let's go back to VS Code and connect to it. As we will use this SSH connection quite often, I recommend that you create a .ssh/config
file in your home folder, with a setup similar to this one :
Host jdubois-azure
HostName 52.232.60.209
User julien
Once you are connected to the Azure virtual machine :
- Use the extension management tab to install the "Java Extension Pack" from Microsoft again, but this time on the remote SSH host.
- Use the command palette to do a Git clone of our sample application
https://github.com/jdubois/simple-jhipster-app.git
. - Run the
SimpleApp
class as we did before.
As a result, our application now starts in 10.3 seconds! That's a bit better than on our Surface Go, but clearly the default Virtual Machine isn't the best option for us.
Please note that if you want to access your application locally on http://localhost:8080, the "Remote Development" tab gives you a graphical utility to create an SSH tunnel.
Testing with better machines, and optimizing price
As we are using Virtual Machines, there are a few very interesting things we can do to optimize both our costs and performance :
- Those machines should only run when you use them, so you should turn them on and off when you work, like a normal computer in fact! Please note that there is an "Auto-shutdown" menu on the Azure portal, and it's probably a good idea to shut down machines automatically for the night or the week-end, in case you forget to do so.
- There is a "Size" menu, which allows you to change the machine type you are using, in order to tune it depending on your desired cost and performance. This doesn't work for all machines, unfortunately : they need to be in the same region, and in the same family.
Let's run our test again, and see the best performance we can get for our application, and calculate its daily associated cost (we are considering here that you work 10 hours per day, 240 days per year). Here are the results, with the associated cost (for the "West Europe" region), with the machines which looked the most promising :
Machine type | Application start-up time | Daily cost (10 hours) | Yearly cost (240 days) |
---|---|---|---|
D2S v3 (default) | 10.3 seconds | 1.20 | 288 |
F2s v2 | 5.8 seconds | 0.97 | 233 |
F4s v2 | 4.0 seconds | 1.94 | 466 |
F8s v2 | 3.4 seconds | 3.88 | 931 |
H8 | 2.9 seconds | 10.32 | 2,467 |
H8 Promo | 2.9 seconds | 6.20 | 1,488 |
Let's study those numbers :
- The default machine (D2S v2) isn't very interesting : it's 30% faster than the Surface Go, so it's not really worth the price and the trouble.
- The "F" machines, which are the "compute-optimized" machines on Azure. Starting with the "F4s" they also have access to premium SSD and accelerated networking, so you get more than just CPU power when you upgrade.
- The "H" machines are for "High performance compute", so basically they have better CPUs than the "F" machines. However, they are much more expensive, and as we saw earlier we are not that much CPU-dependant. Currently there is a "Promo" on some of them, which makes their price more attractive, and in that case they can be an interesting alternative to "F" machines.
As a result, it does seem the "F" machines are the best deal. I would personally use either F4s v2 or F8s v2, and use the "resize" feature to switch depending on my needs. As I have an MSDN subscription, I have $130 of Azure credits every month, so even the H8 Promo could work!
Conclusion an thoughts
Clearly, running our application on "F" machines types is much faster than on the Surface Go, for a reasonable price. Also, we are able to "resize" and shutdown those machines in order to adapt to the cost and performance we require.
For consulting companies and freelancers, I believe there is here a very compelling alternative to the usual $2,500 Macbook Pro that everybody currently buys :
- The upfront cost is very cheap (about $500), so buying one isn't such a big decision as with a MacBook Pro.
- It's the usual CAPEX vs OPEX calculation we do with the cloud : as a consultant, I'd rather not spend those $2,500 when I start my business, but rather spend a few Dollars each day, depending on my billable work.
- I believe those few Dollars per day could be billed to customers : this doesn't cost much (compared to how much consultants bill their time!), wins time on people on-boarding, and gives better security (code isn't copied on everyone's laptop).
Top comments (14)
Interesting article. Thanks for the effort in the perf numbers. I think you forgot the killer feature from my perspective. Battery life improvements not having to run all that code locally.
Which has the equivalent downside: can't access your code in the cloud when you're offline or with a crappy connection.
Oh you're right! My Macbook Pro used to have only 2 hours of battery time when my Surface Go lasts all day... There's probably a very interesting ecological argument here, between the used batteries, the less efficient power usage and the power sources which are probably greener in a datacenter than in a city. Also, less heat in the office during the summer!
I use a Chromebook 14 to remote develop. it's the best of all worlds with really outstanding battery life and good keyboard. also light and costs half of the surface. what you get from apple is a joke in comparison (price, keyboard breaking with dust, performance).
also you can use Google remote desktop to have an desktop experience and battery life is still great. but I think you could also using something like coder.com, last time I tested it, it was not for me yet, but I think it came a long way since then...
Do these costs factor in disk storage - from experience premium disks are expensive and are charged even when VM is not in use? Although maybe this has changed in recent times.
No, I just used the VM price, as I expected the disks to be small and cheap (same thing for network, etc). Indeed, premium disks are more expensive, which is logical, but for a small disk that shouldn't make a huge difference according to azure.microsoft.com/is-is/pricing/...
When the VM is not in use, I guess you are always charged, even for standard disks, as long as you use them. You could create a snapshot to save them, but personally I just recreate everything - it's just temporary stuff for the day, I have a script that sets up everything, and at the end of the day I commit everything and kill the whole thing (in fact I delete the resource group).
Serverless developer machine xD
The pricing is very appealing compared to iPad.
I have the Surface Go w/LTE. Nice little machine. I actually replaced my 2017 iPad Pro with it, since I couldn't justify spending $1,300 minimum on latest iPad Pro model.
I don't think you're comparing apples-to-apples (pun!), though. If you're looking for a pure tablet experience, the Surface Go isn't it. In fact, Windows isn't it. Unfortunately, iPads are the only pure tablet experience I can think of. Android tablets continue to suffer from vendor fragmentation and mostly sub-par specs. Windows tablets suffer from Windows.
Obviously, even though I'm bashing on Windows here, I have a Surface Go that I like very much. But it really isn't a tablet. It's a netbook in tablet's clothing. Once you understand that, it's a nice little device.
This is funny π
Yes, totally agreed!!
Nice article.
The front-end part (webpack + hot reload) run locally ?
Thanks ! For this post I only wrote about the backend, but you can have indeed the whole JHipster stuff running on the server, including Webpack with hot reload. All you need to do is open an SSH tunnel on port 9000.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.