Reminds me that I'm missing GoogleCL a lot. Info: Project is discontinued and not working anymore because it was using OAuth1... they could not upgrade to OAuth2 oO
Google Cloud Shell
41–50 of 162 posts
Re: Google Cloud Shell
#42Nice idea. I do a lot of my development SSHing to a resource rich VPS. For things that take a long time to run (Haskel stack builds, a long running machine learning calculation, etc.) it is great to not run that stuff on a laptop. Cloud Shell is a bit different in the sense you would not want to try anything resource intensive on a micro instance. But for coordinating other services it makes sense. I think Google nee…
Mark, if you'd like to try our version of a "web based IDE that gives you access to work with any code you have in your private Google-hosted git repos", check out the Source Editor feature of the Cloud Source Repositories: https://cloud.google.com/tools/cloud-repositories/docs/cloud...
Also, we're alpha testing some integration with the Source Editor and the Cloud Shell right now, so anyone that would like to participate in that alpha test can drop me a line: csells@google.com.
Chris Sells Cloud Developer Tooling Product Manager
Re: Google Cloud Shell
#43Wait, so this runs in a browser? Is the idea that you can then use a machine like a Chromebook to handle your development?
That's absolutely the goal, Colin. Give it a try and let us know what you think.
Chris Sells Cloud Developer Tooling Product Manager csells@google.com
Re: Google Cloud Shell
#44Earlier quoted context omitted.
So $1.20 more per month than more powerful VPS from competitors like OVH.
I normally am quite reserved about language use, but comparing google to OVH? Seriously? OVH is a dysfunctional company that somehow turns a profit. We almost lost our company's domain name twice due to their incompetence.
Please, make your contribution worth something by explaining your issues with OVH.
I've been a very happy customer for years now.
Re: Google Cloud Shell
#45Earlier quoted context omitted.
I wasn't explicit with my earlier comment, you're right about the beta period. I was referring to after when they exit beta and are a good, useful service for a year or two.
Disclosure: I work for Google. To the best of my recollection, I don't believe we've ever shutdown a product. Was there one in particular that hit you? (Reader, Wave, etc are totally different divisions.)
Google Code was first turned into a graveyard, then deprecated, and soon will shut down altogether. Reader was not strictly a development tool (which is what I guess you refer to as "your division"), but was heavily used by developers, so it significantly disrupted people's workflow. Same for Wave and any web API (there's quite a few of them which were unceremoniously dumped).
Re: Google Cloud Shell
#46Earlier quoted context omitted.
So $1.20 more per month than more powerful VPS from competitors like OVH.
I understand worrying about burn rate and all that, but when the entire service costs the same as a single cup of coffee per month, it might just not matter. How well it works, what features it provides, and how well it interfaces with the rest of the cloud services you're using are much, much more important concerns than saving a buck a month.
Well, not always. As a student, you don’t want to spend 4$ for a cloud console, plus 4$ for cloud IRC, plus 20$ for a VPS, plus 12$ for your phone contract, plus 120$ for a new phone every 2 years...
I – like most people – don’t let useless devices run on standby either, costing me upwards of 30$ a year for a TV on standby.
As a student, I don’t buy totally overpriced coffee that costs that much either.
Re: Google Cloud Shell
#47Coming from an AWS shop, I guess I don't understand the use case(s) for this. What this enable me to do that I couldn't accomplish by ssh'ing to any of the boxes in my environment?
I use AWS extensively as well, but really like this product plan.
Ultimately what AWSClassic does is give you a lot of baremetal boxes to drop AMIs on. Google's changing that to the containerized model by offering direct services that are scheduled on hardware. As Kubernetes becomes more and more the primary method for deploying apps on Google's managed services, this approach will pay off more.
But it's worth nothing that for many people this is what Amazon needs to do as well. As VPCs become the mandatory methodology for AWS, it's increasingly annoying just to set up the bare minimum you need to get a capable shell inside your environment. Even experienced AWS users have trouble getting VPCs right given the state of the current documentation.
Re: Google Cloud Shell
#48Coming from an AWS shop, I guess I don't understand the use case(s) for this. What this enable me to do that I couldn't accomplish by ssh'ing to any of the boxes in my environment?
I think GCP's long term strategy is still to move all devops work into Google. They've stated this with GAE for awhile, and this is a logical extension move as part of that strategy for app devs who like to "SSH into their machines". Like a lot of "cloud services", this is indeed nothing you can't do on your own box, and I imagine tens of thousands of people have done it before and will do it again on AWS. Google has…
I think their long term strategy is to move to a containerized world. The fact that there are managed Kubernetes instances is very telling, because that was a LOT of work.
Re: Google Cloud Shell
#49I like this, and it feels "Google-y". Worried that a handful of us will use it, lean on it heavily, and then Google will do what Google does and pull the plug on it.
Google drops ONE service people really used and now discontinuing anything outdated is "pulling a google." Yeesh!
Re: Google Cloud Shell
#50Earlier quoted context omitted.
Disclosure: I work for Google. To the best of my recollection, I don't believe we've ever shutdown a product. Was there one in particular that hit you? (Reader, Wave, etc are totally different divisions.)
Google Code was first turned into a graveyard, then deprecated, and soon will shut down altogether. Reader was not strictly a development tool (which is what I guess you refer to as "your division"), but was heavily used by developers, so it significantly disrupted people's workflow. Same for Wave and any web API (there's quite a few of them which were unceremoniously dumped).
It is not really Google's fault that Code was not a successful product, other than that they simply didn't have the energy/budget/will to actually make it a competitive product with Github.