Google Cloud Workstations managed development environment is now GA | Hacker News Reader

Google Cloud Workstations managed development environment is now GA

cloud.google.com

109 pointsrbanffy110 comments

I've been running my dev env on a bare metal for almost 2 years now, the setup was pretty much just and SSH client setup with VSCode remote SSH extension.

Running on a Hetzner AX41-NVMe (6 cores, 64GB Ram, 2x512GB NVMe) for around $40ish. With GCP workstation for a e2-standard-4 (4 cores, 16GB Ram) would cost $230 + $10/mo for the 100GB storage

No hourly charge crap, can run all night do time and resource consuming tasks, huge storage space etc... all around good experience so far

Are there any latency issues running VSCode on a remote server?

I have also similar setup (was not my choice first), 0 issues (including latency) so far. Working great.

It all depends on the stability of where your workstation is in terms of internet. Latency is the killer depending where you are from.

I'm use to 260-280ms latency, which is a lot better than it use to be.

Perth, Australia. Glad they finally have decent international cables. And fibrr drastically improved latency.

Day2day usage? no not really, everything is smooth including the terminal and the built-in port-forwarding feature

You may notice a tiny delay when refreshing files or when using hot/live reload stuff, but it's sub-second and only becomes an issue of you dig for it

That’s pretty interesting and i think that hetzner price is cheaper than i can self-host.

Powering that host would cost me around £12/mo

That bandwidth is £44/mo

That host itself amortised over 3 years would be £22/mo

Amusingly this seems to have the exact opposite purpose than what most devs would like to use a remote VM for.

Dev thought process: "I can have a working clean remote Linux machine since IT imposes work impeding crapware, barely working net connection, account restrictions and OS on the laptop - it's cheap too"

This: "Dev work happens on a highly monitored and locked down Linux environment rather than a uncontrollable local laptop - we can also charge a lot becuase it's security"

The cloud represents the return to timesharing development environments.

It turns out that having development environments only accessible via telnet and X Windows is great from IT management point of view.

As a dev this is exactly what I would expect and want out of such service. The alternative is that I have all this crap on my machine.

Having it on a remote VM is so much better :

- my device isn't crippled

- a lot of potential security issues are now not my problem

- environment setup is dealt with by someone else

- I can code on a potato as long as it can render the screens I need

I can have what you're describing with a standard VM instance and SSH port open (or my home desktop and cloud flare tunnel)

Until they decide this remote machine can only be accessed from properly secured devices...

I get the feeling that the enterprise environments targeted by this product are already restricting access in this way.

This is already standard. I've worked at several places which had hardware white lists on the VPN and only company controlled and secured hardware could connect. Working on your own hardware was strictly forbidden.

I don't understand. We all know corporate IT, and how this plays out in reality.

1) my device isn't crippled

WHY would you assume they're not going to cripple your device? In the past they made it worse. One product that had exactly this purpose was "Sun Ray" machines. They weren't just crippled in software, they were utterly crippled in hardware. You see the problem with crippled hardware ... is that it's not really much cheaper than non-crippled hardware, but years behind. A bad chromebook is actually a pretty good crippled computer.

So you get the worst of everything

a) very slow processor (that actually costs more than a decent one)

b) too low amount of memory (that actually costs more than a sufficient amount of memory)

c) no local access whatsoever. So checking what ip address the thin client got ... not possible.

d) a low-res horrible headache-inducing screen. And forget about multi-monitor or anything like that.

2) a lot of potential security issues are now not my problem

Yeah because if there's one thing other departments in companies easily and quickly do it's accept responsibility for problems ...

3) environment setup is dealt with by someone else

Seriously ... why would they do this.

4) I can code on a potato as long as it can render the screens I need

You can't. You can only code on their potate. The one with spikes that leaks the suspicious black liquid and can't be replaced. Not because it isn't easy to replace, but because the problem is IT, not the technology.

At university they tried to introduce Sun Rays for us. The main thing I remember was the horrible monitor ... and when I brought my own full hd monitor from home, it crashed. Eventually I found out why: the thin client had so little memory the higher resolution made the framebuffer not fit in memory.

Having a managed and even versioned workspace is an awesome proposition.

Unfortunately you pay for a 4-core 8GB RAM instance, which is only used 40 hours a week, more than for a comparable 8 to 16-core 32GB RAM local PC or laptop, which you use for three years.

The numbers don’t start to approach similarity probably until you’re managing dev machines for hundreds, if not thousands of developers. Then you’re starting to talk about the scale needed have managers dedicated to the sysadmins, managers dedicated to dev network ops, etc etc. Those are all people you could outsource to the cloud.

But I imagine it’s the same value prop as other cloud services. It’s often cheaper to run legacy architecture in legacy ways, but there are technologies and concepts only available when running at cloud scale, and for those use cases you’re getting a discount over trying to roll your own.

You're mostly right. The problem I experienced is, that those people managing the old machine spec the new to lowly, because the prices are high. The optimize like before: for them and not the users.

The result is not just added latency, but actually slower build times etc. compared to your local laptop, not to speak about a high-performance PC.

Shocked about the prices. Outside of AWS/Azure/GCP, many companies offer bare-metal dedicated server, with very high specs and would cost a lot less (around $40-60) per month. And they can be used as remote workstations.

I myself use a Hetzner server as a remote workstation, which I connect via RDP. 12 cores Intel processor, 64 GB RAM, 2x1 TB HDD and 2x512 GB SSD for US$ 60. If there’s any hardware issue it’s their problem and they will fix it really quickly, so I don’t have to worry about it.

GCP/Azure/AWS prices are insane.

Agree on the cloud prices, though there are use cases for very abrupt scaling.

Btw azure has a tco calculator so you can see what assumptions you have to make for the cloud to come out ahead.

Fair point about the scaling but a 9-5 job is pretty much the opposite... Very predictable usage and even on better priced cloud providers you can quickly provision new hardware when needed, e.g. some kind of load testing (which would be more ops than dev anyways)

Oh, I don't disagree that it is a bad fit for this particular use case (except if your company hires a lot of seasonal data-enty WFH workers).

I fully agree (I also use Hetzner servers, BTW). I'm amazed so many people pay the huge premium to get "instant scalability", even though they don't actually need instant scalability and might in fact never need it.

> I'm amazed so many people pay the huge premium to get "instant scalability",

For personal use, the interesting part about cloud isn't the scaling up—it's the ability to scale down rapidly to (near) zero costs. I have a couple of GPU instances on AWS that I only use sporadically at spot-prices; when turned off, I'm only paying for the EBS storage.

If I were to rent servers from Hetzner (which I have done it the past for longer running things), it would cost me €40-80 a month, vs €10 a month.

(There's other minor niceties from cloud as well, for example: I also have a lambda in my account that when any instance starts, it checks for a DnsName tag, and configures a appropriate A records pointing toward that instance's new IP address)

Maybe just me but the cloud desktops pricing still isn't all that attractive for some businesses to make a big shift to using them, but also not terrible for some businesses that could use the extra security or cloud environment benefits:

8hrs per workday for a 4 vCPU and 16 GB RAM = $217.36 per month[1]

1: https://cloud.google.com/workstations/pricing#pricing-exampl...

Also, that isn't exactly a powerful machine at 4 cores and 16GB of ram. Probably have to double it or what is the point? Security, maybe?

Aren't vCPUs only hyperthreads? So this is actually similar to a dualcore processor?

The 4 vCPU 16 GB RAM range from 0.32-0.39 $/hour With 8 hours per day and 22 workdays per month its at most 68.64$.

Your price includes the "workstation cluster fee", whatever that includes. Anyways this fee is fixed and does not increase for more workstations.

1 Dev => 68.64 + 144

100 Devs => 100 * 68.64 + 144

I guess $70, or even $140 with better hardware, might be worth it in some szenarios.

Personally, I'd never want to work with a company that doesn't trust me with a regular notebook.

> I'd never want to work with a company that doesn't trust me with a regular notebook.

The value proposition has nothing to do with trust.

The use case for this would be a cheap device that’s thin and light and has excellent battery life hooked up to a cloud machine that is very powerful.

It could also be used to do wfh without having to bring your company laptop or mix your personal data.

Not trusting someone with a regular laptop is common practice in enterprise consulting.

Either a VM accessible via citrix, RDP, X Windows, Bastille,.... or a throw away laptop locked down to the project.

Cloud desktops move the numbers game from CapEx to OpEx.

“CFOs love this one cool trick!”

You can buy a better specced laptop in a year.

How many big corps in the US (I live in the US so that’s my reference) are doing engineering hardware rotation at sub-2 years? Most are likely to be 3.

The “frugal” FAANG is four…

"Most" companies in the USA are on a 5-year laptop replacement cycle because that's what the IRS set the MACRS depreciation schedule to for "consumer electronics" (really, category 00.12 in Table B-1 of Publication 946). Each year following the purchase they can write off the following on their taxes:

Year 1: 20%

Year 2: 32%

Year 3: 19.20%

Year 4: 11.52%

Year 5: 11.52%

Year 6: 5.76%

Why accountants are actually in charge of the rate at which laptops get purchased, instead of just the paperwork for the tax deductions caused by the rate of laptop purchases....I truly do not understand.

Yeah, but hardly companies want to do that for contractors working on delivery, for non software focused industries.

$217/month is absolutely nothing for any company of any size. It’s a rounding error.

Duh, but you wouldn't rent one instance, but one for every employee.

That's not chump change considering the measly specs.

And $217 per employee is still nothing once you consider the fully allocated expense of an employee.

The first time I used a remote workstation for any period of time kinda spoiled me. It was beefier than my real laptop, I had super low latency. The experience overall was kinda nice actually, convenient to leave long running task active while I put the laptop in the bag. The laptop was always cool and quiet (unusual at the time considering the workloads).

After that, they have always been ridiculously slow, locked down, goes into hibernation if you leave it unconnected for too long. Mostly running windows. Sometimes forced to use video conferencing through it, with horrendous audio/video latency. Almost impossible to be productive on.

I think remote workstations, "done right" actually can be nice. Especially considering new editor integrations and/or e.g gpu intensive tasks. But I wonder if any org actually bothers to do it "right".

Seems we are back to the mainframe era, or getting very close to it. I like to use my own tools, like emacs of vim, instead seems people will all be using the same tools (IDE/browser) for development if this goes mainstream.

Time-sharing! It's back!

> I like to use my own tools, like emacs of vim

So you just need to rent a VPS to get the same type of offering which is not a solution to IDE users.

There's nothing bad about IDEs.

You can run an IDE on a VPS using x11 forwarding, or even with vnc/rdp

IntelliJ/IDEA now has the ability to have a local ui and a remote server. The successor , Fleet, has it as well. Visual Studio Code has it as well.

Then there are options like theia or other self hosted workspaces.

Rendering can all be done locally with compute remote, only communicating minimal amounts of changes.

This is really intended for development work on complex codebases with long running build/test times.

Developing and running builds on a powerful remote system in a data center from your laptop is a game changer, as long as you have a good connection and low latency.

Low latency definitely makes for a better experience, but since it's javascript running the browser, I assume typing into the editor textarea and most features will go as fast as javascript will go.

Do you type faster than what javascript is able to handle?

Depends on how much JS is trying to handle.

I think you’re forgetting that javascript in this context needs to be constantly re-evaluating the whole document; It must do this for syntax highlighting alone, not to mention other plugins, spell checkers and auto-completes

but since most editors are also just electron apps, it's not much of a difference

What kind of workload favors the cloud over a powerful laptop, let alone a desktop machine? Surely the security is the only real advantage.

code close to data is the real one; managed services for companies that fire a lot of devs is a cynical one; always-on security updates probably big too.

(at school they call me a "box hugger")

Anytime that your bandwidth is low and you need to work with data hosted on your cloud provider or even pulling down Docker containers.

I can also provision VMs that are much more powerful than any reasonable desktop temporarily.

But most developers don’t use desktops any more do they? Even if you’re hybrid and were forced to return to office, you would still want a laptop.

If your bandwidth is that low, how would this remote desktop experience feel good? It won't.

I’ve done a Remote Desktop equivalent over a modem with PCAnywhere in late 90s. Even VNC which is horribly inefficient compared to better protocols is good enough.

A laptop or desktop machine is only one machine. It might have multiple cores and gobs of RAM but at its heart it's still one machine with all the limitations that brings. Working on the cloud with a big build cluster means when you hit compile it spawns a ton more jobs than a single machine ever could run, and then the binary gets delivered and runs in the right dev environment with all the decencies set up for you already. After running a fleet of automated testing on top of that.

I suppose if you have some kind of compilation that can saturate 100+ cores for so long it makes sense to send out the work to other machines then this could be useful. One machine is an advantage when we're thinking about the I/O overhead. I suppose giant Infinibuild projects exist so there's a market for some C++ devs perhaps. It still seems fairly niche to me.

The aggressively parallel automated testing is nice but I don't see why that requires the IDE in the cloud.

Server cpus have way more cache and faster ram than laptops of the same generation. Also, people here usually mean ‘MacBook pro’ when they say ‘laptop’, and macOS is amazingly bad at docker when compared with native Linux, which is what you’ll likely be running on the remote workstation.

I see this promulgated a lot by big corpos but little uptake or enthusiasm among actual developers, nor the companies that employ them.

For compliance with various anti-data-leak standards we currently use a very janky remote development setup at work. We're working on improving this situation while maintaining compliance. The thing I keep hearing from devs is "wouldn't it be nice if we could develop pn our Macs?"

I guess the bigcorps will have to deprecate and eventually stop development on local IDEs if they really want us to work this way, but I don't see that happening.

This supports VScode remote development, so your engineers can run VScode in their Mac's and access the remote.

I have been doing VScode remote development for ages now and it is awesome. Even from a Chromebook

If they don't mind the telemetry.

If they don't mind the telemetry.

Well, it's Google Cloud Workstations. So you're already dancing with a devil. Might as well dance with two.

How does the data / telemetry Google collects on everyone compare with Google Cloud data collected on paying customers?

Not necessarily, it's open protocol with vim plugin. Mainly just ssh and running commands. And a part of ide running on server and client

I mean if the telemetry means they know their shitty software crashes at this one point and then they fix that, I'm not sure I really mind.

We already do VSCode remote development. We'd rather just hack on our Macs.

Vs code remote is fantastic. It’s as good as local development on vs code.

Unfortunately vs code has way too many things missing compared to JetBrains.

This never stop being a standard practice in big corps.

There was a short time between the transition of UNIX into Linux, and Citrix was growing up, that we actually used local development in consulting projects, coupled with RSA keys for access.

Around 2010, it was back into thin clients connecting to development VMs on Amazon EC2 instances.

more people should recognize or write about the pendulum of centralization/decentralization in computing and impacts like this one.

Seems we are back to the mainframe era, or getting very close to it.

Or the thin clients that were all the rage for a week-and-a-half back in the late 90's.

Salesdroid: "Why spend $3,000 on each computer for your office, when you can use our thin client, which is only $1,500, including keyboard and mouse?"

Dell: - Starts shipping full computers for $299 -

Thin clients never went away in non software focused industries.

What do you think restaurants, downtown shops, travel agencies, factory floor,doctors,.... are using?

10 year old Windows 7 PCs full of malware? Not so much "thin" as "plague-ridden and emaciated"...

Lenovo ThinkCentre, HP Thin, Android tablets,...

ThinkCentres and Android tablets aren't really thin clients. They can run thin client software, but so can pretty much all thick clients.

They are given that they don't work without the browser based software, or Web widgets, that those business rely on.

...they absolutely work without browser based software.

Unless your definition of 'thin client's is 'anything with a browser regardless of whatever other software it runs'. Or unless you're counting stuff like electron as 'thin clients'.

There's ThinkCentre M, their small thin client segment, but that's a tiny part of the whole ThinkCentre line, which includes normal desktops and workstations.

My definition of thin client is how the computer gets configured by the contracting services company, locked dow to use the SaaS product, to be used by muggles on the floor.

Yes, it isn't something booting over tftp, with either green or Amber colors, or a X Windows Server terminal like the IBM ones.

It doesn't matter, they are configured and used just the same, and their resources are relatively limited compared to a random desktop.

> My definition of thin client is how the computer gets configured by the contracting services company, locked dow to use the SaaS product, to be used by muggles on the floor.

So you invented your own definition.

I’ve been calling cloud “mainframe 2.0” since the 2000s. There are certain scale, convenience, and security benefits to mainframes but they come at the price of privacy, autonomy, latency, and sometimes cost depending on your exact utilization pattern.

Personally I find it very dystopian but I’m a child of the PC and early Internet era and the idea of personal computing always seemed magical.

On cost it’s like other capital assets: if you use it heavily and evenly it makes more sense to buy, but if you use it rarely or you need “burstable” use it’s better to rent.

The difference being that Web shell and browser are somehow better than orange and green phosphor terminals.

It’s just a Linux environment. You can still use your own tools.

That depends on how it gets managed by IT.

With my SecDevOps hat on, it would be as locked down as it needs for project delivery.

And how is that different than a local computer with the same policy? It’s not the Cloud IDE that’s limiting you, it is the internal policy.

No physical access, can be dynamically reconfigured in hardware capabilities.

We are, since I went back to cloud native development, I am back on the early university days using DG/UX, or the commercial UNIX development servers from early 2000's.

These managed development environments are wonderful: consistent experience, secure, compliant, scalable, etc. That is, right up until it goes down. Then the productivity of your entire development team (and thus the output of the six figure salaries they are paid) drops to exactly zero while you bring up the managed development environment again.

True. But I found stacks that are simple (and micro service) enough to run on my laptop to be much faster to develop on.

That's pretty much everything these days. But it isn't a big deal because most companies are not efficient enough to have downtime-from-dev-environment be a significant negative factor for any performance metric.

It is a big deal, because ad-hoc development environments don’t break simultaneously. They can also be fixed by the developer using them. Even if, say, GitHub goes down, I can still email / DM a git am patch to a colleague for a code review (and they can send me a patch with comments).

Choosing a shared environment is basically choosing to randomly give your development team a snow day. Maybe you’re okay with that tradeoff, but when it rains it pours… prod likely will go down when you can’t use the cloud dev machines.

Seems like it would also not be so wonderful if your remote employees are in rural areas (like the Joshua Tree area I reside in); I don't think I could handle the latency between keystrokes.

Surely you have options though? In Rural NZ we have a choice between 4g which runs at about 50mbps and latency of about 15ms and starlink which runs at around 100mbps and has a latency of about 25ms.

Both should be good enough for remote work.

I like how you're implying I haven't worked here for years and don't know the options. I have the best possible option and that system can be flaky for hours on end depending on a lot of factors.

I wasn't implying that at all, more I was shocked at how a country like America doesn't have high speed broadband ubiquitously available. So it was more rhetorical than anything.

Fair enough. You have my apologies

California by itself is bigger (by population and surface area) than all of NZ, to say nothing of the rest of the US. I'm not saying that the US has done a great job with internet access, just that it's not exactly a fair comparison.

Having more people in a bigger area increases the aggregate expense, but also provides more people to spread it around (and the US also has a higher per capita GDP.)

There may be legitimate differences that make this harder for the US that aren’t simple failures, but you haven’t identified one.

I just set up IntelliJ to use my remote workstation for LSP and Build and Test, but all of the text editing happens locally.

Specifically the files are also hosted remotely but the local text buffers are synced in the background not every keystroke.

How did you manage this? Every time I tried it, Idea insistent on managing the lsp server itself and locally.

But the frontend runs locally via JavaScript, so while latency is real, there shouldn't be more between keystrokes than, say, VScode. (Because otherwise that would be intolerable.)

How often do you think the entire global infrastructure or even a multi region service goes down?

Using AWS as an example (because that’s what I know), if Cloud 9 in us-east goes down and it’s not the entire service, I just launch from another region, do a git clone and keep moving.

It takes less than 2 minutes to bring up an environment if GCP’s offering is similar to AWS’s. I am assuming it will be.

I guess this and Windows 365 is instead of Citrix or Thin Clients. It's not about price, it's about security, control and flexibility. Not meant to compete on price. Now I admit I kind of don't get it either.

This part, in the second paragraph:

Today, we are thrilled to announce the general availability of Cloud Workstations with a list of new enhanced features, providing fully managed integrated development environments (IDEs) on Google Cloud.

Makes me I believe that GA here means "general availability". Holy cr*p that is some lousy writing with an undefined acronym in the title. I guess I'm completely outside the target audience who're supposed to know these things.

For better or worse, the term "GA" is used by all cloud providers.

Might be so, but it's always a good practice to spell things out.

When I read this title, I first saw it as "Google Cloud Workstations managed development environment is now [on] Google Analytics." I did a double-take (as this is clearly ridiculous) and then realized what it meant.

Google Analytics is also a thing. Not in this context but I had to think about it before reconsidering

It’s a common acronym and term in the software product life cycle. It’s been around for many years. https://en.wikipedia.org/wiki/Software_release_life_cycle#Ge...

Here are some other examples in common use:

https://dev.mysql.com/downloads/mysql

https://httpd.apache.org/download.cgi

If you’d rather use a self-hosted alternative, we are building Hocus [0]. It’s still in alpha, but already supports prebuilds, VSCode, shared environment variables, and more.

[0] https://github.com/hocus-dev/hocus

Not only is this pricing nucking futs (like what, 10x the cost of buying a decent tower and setting up tailscale), but in my experience (which admittedly includes only GitHub CodeSpaces, GitPod, Azure's thing, and Amazon Workspaces... but not this Google offering), when compared to doing this yourself these services are dog shit slow.

The fastest of any of those 4 I tried — "16-core" with 32GB of RAM — is like several multiples slower than my aging commodity-hardware Linux tower with 11th-generation Core i9 11900K and 64GB RAM and medium-fast NVMe (older-generation but still 5GB/sec or so reads).

I mean things that take 2 minutes on my self-managed "remote" box take 10-15 minutes on these hosted VMs. And that thing cost around $2000, years ago.

I'm not talking crazy workflows, either. Sometimes I build a big open source project like Swift or the Deno runtime, but the speed differential is totally apparent even just building medium-sized web apps and doing 'npm install'.

I completely endorse this general model of doing development on a centrally-located beefy machine (or perhaps set of purpose-specific VMs/containers hosted on that beefy machine), and making it available remotely to whatever device.

(BTW if you have kids, this model works awesome for them, too, once they get old enough to start wanting their own computing environment.)

But even if you are OK with the costs of these services, which are basically like buying a max-spec MacBook Pro every 2 years, the performance doesn't come close.

And yeah, I haven't tried this specific new one, but I am confident it is in the same ballpark because otherwise they would be shouting, "OVER 10X FASTER THAN GITHUB CODESPACES!" but they are not.

This would've been really helpful for all those companies who are embracing remote work and so could quickly provision powerful development environment for all their remote devs who aren't being made to return to the office...................

I think y'all may be missing a significant use case.

M1 Macs. Some places use only Macs for reasons and m1 is now the only option. But software is still optimized for x86 and emulation is not good enough yet. Not even that it's slow, but some things just don't work.

Yeah these cost money, but it works right now.

Reply on news.ycombinator.com