Google Cloud Platform’s new interactive CLI | Hacker News Reader

Google Cloud Platform’s new interactive CLI

cloudplatform.googleblog.com

247 pointsCSDude76 comments

I wish they would spend more time finishing the halfway done projects they've started (and fully documenting them), rather than continue to launch new ones.

For instance...Google CloudSQL - Great! Postgres - Beta...Postgres from AppEngine python...err, we'll get around to it, maybe.

Just giving one example, but my point is - finish what you've started before making new. I think recent articles I've read about launching being the track to promotion explain some of the state of things within GCP.

It's repeated enough that it's a conscious decision. Google offers good application platform, but locks in the data layer.

See AppEngine. Had (and still has) much bigger potential than heroku since the beginning. But where do you store data? Random stores with random limits.

CloudSQL is great? Backup/restore in CloudSQL is half baked. Multi master for MySQL is half baked. All these are very well solved with RDS, but Google wants to sell you 3 or 4 different data stores with different arbitrary limits.

AWS free tier provides a tiny RDS insurance for you to store useful data. Google cloud free tier? No standard SQL databases. Again, arbitrary locked in custom nosql with random functionality and usage limits.

It's spread out enough that it looks like a planned strategy to give an open computation platform but lock in the data, even at the risk of driving away potential new/small customers.

+100 - i was waiting for them to launch Postgres prod. It just doesnt go live. Even worse, they have had trouble in exposing max_connections as configurable PostgreSQL flag (https://issuetracker.google.com/issues/37271935)

That is an understandably automatic control feature to keep the DB instance running well since PostgreSQL doesn't handle connection scaling well. The recommendation is to use pgbouncer, which you can also combine with the GCP cloudsql proxy into a separate container and use that way.

We deploy that onto GKE as a service and have our apps use that. Some setup required but cleaner overall.

I assume CloudSQL is google’s alternative to AWS RDS. Less of an excuse to not make the setting user configurable when the competition (AWS) does.

It's a double edged sword. When you don't limit connections and customers push their servers beyond their limits, some of them then ask why Google didn't do anything to prevent the situation from happening. Ideally, this would be solved by having better failure modes but that's not really the case today.

Most product decisions are not set in stone and can be changed if there's sufficient evidence to suggest that they do more harm than good. There's a lot of work that goes on behind the scenes to keep the service running smoothly and unfortunately/fortunately customers are not exposed to them. Some things that may appear to be simple on the surface are not when you take things like supportability into consideration.

Source: Used to work on Cloud SQL

There's no excuse, it's about a different philosophy.

AWS gives you lots of tuning controls and complexity while GCP tends to hide most of it with easier scaling and performance. It'll vary with individual products themselves but it looks like Cloud SQL is designed with that general outlook.

None of the clouds are perfect, the only viable strategy is to use the best parts of them all that fit your needs.

I'm afraid all of you are getting it wrong. The setting is hardcoded to 100.

Check this out - https://issuetracker.google.com/issues/37271935#comment39 and then the update https://issuetracker.google.com/issues/37271935#comment49

This is not a feature. It is a bug. It needs to be at par with RDS.

As actually stated in the comment you linked to, it is not hardcoded but scales with the instance size to protect against an out-of-memory condition. The lack of it being user configurable is a separate issue, and not a bug but rather a design detail of their managed service.

It's a product decision to not make this configurable to make the service supportable. It's not a technical issue.

I don't know if Google advocates horizontal movement to different orgs/teams specifically, or if its just anecdata I've picked up talking to Googlers and reading about their org structure, but I wonder if this and the promotional scheme of "launch and move on" has caused teams to splinter and lose serious velocity - becoming the direct cause to stuff like this.

Personally I think Google App Engine has always had massive potential but has been at about 80% of its potential since its inception.

EDIT: Also I don't want to take away from this press release, the CLI is awesome and its going to help a lot of people.

> I wish they would spend more time finishing the halfway done projects they've started (and fully documenting them), rather than continue to launch new ones.

Perhaps I am reading too much into your comment but you make it seem as though releasing other products slows down the development of those projects that you consider halfway done.

This is definitely not the case; it's not as though the engineers who were working on CloudSQL or AppEngine decided to start working on a CLI instead.

> I think recent articles I've read about launching being the track to promotion explain some of the state of things within GCP.

There are certainly issues with promotion but if anything I'd imagine getting a highly requested customer feature like Postgres out of beta would be awesome for promotion so I don't think that's the underlying issue here.

This -- _so_ much. That was my first thinking as well.

IAM in GCP is still half-baked. How about they finish that? I understand that GCP is a massive engineering effort with endless things going on in series, but core parts of their platform are still mediocre at best. I'd prefer not to see more hackweek projects on their blog.

What feature do you need from IAM?

gcp pm here - got time to chat?

Real IPv6 support is another one. I get that it's harder for them because they do such advanced networking at such a scale but... at this point their statements of support seem like empty talk. They are a late adopter.

We don't know if they have teams working on this or not...my guess is they do. What if it just takes a long time to ship those features to GA? Should they hold off on other features?

Yeah. Google Cloud Functions - Beta. Also had a multiple hour outage recently. Been waiting for Postgres to move out of beta for ages.

The good thing about Google Cloud is that once things are out of beta, it is usually easier, cheaper and often faster to use than AWS equivalents. The "AWS way" of charging of every little thing is migraine inducing. (Ex. IOPS for RDS is tied to instance size but can also be scaled independently.)

Hi all, the Google Cloud SDK team here. The Interactive CLI feature is currently in Alpha, but part of our overall Cloud SDK. The SDK is very much in GA, but we continue to look for your feedback on what we can do to make the SDK experience better and easier to use. If you’ve got feedback, we have a built-in mechanism in the SDK. Just enter ‘gcloud feedback’, and let us know.

I have 300$ of trial credit, but couldn't use it when I wanted to create Cloud Datalab notebooks for an ML MOOC under the pressure of deadlines. I was willing to spend more money on something that is working (Floydhub) than use these GCP credits and figure out how to use it.

That's the biggest problem with GCP. Not these small projects (since they have multiple teams working on things and everything progresses in parallel) but the very big lack of managed services and polished features.

The underlying tech and building primitives are the best, so if you just need fast VMs with solid cpu/io/networking then it all works well. Unfortunately that's not enough to compete with AWS and Azure which have so many turnkey services that let you focus on more productive things.

I've been waiting for Cloud Postgres as well and wish I could have used it on my most recent project. I was told last month by a "Cloud Specialist" that they were targeting early Q2 of this year to leave beta, but I'll believe it when I see it.

I also find it frustrating that they don't have more turnkey services. In particular, search. It's ironic that Google's doesn't offer a search service (except if you use App Engine).

>I wish they would spend more time finishing the halfway done projects they've started

Do you expect other teams to halt what they're doing and wait for other teams to finish before they continue their work?

No - I wish they'd release fully baked features before starting new ones - i.e. there'd be nothing to halt. I realize it's not that simple, but, generally speaking - I do not see near the level of readiness/polish/documentation out of existing features as exists on AWS.

It seems that it is the same problem that plagues Google as a whole.

Google is notorious for this behavior. Don't you remember the years-long "beta" status for GMail?

This is an interesting accommodation to less terminal savvy users. I'm not interested personally. But, it's an interesting concept.

In fact, I think it would be an interesting thing to standardize, like super-completion.

Someone else in this thread mentioned that Amazon is working on a similar interactive shell [0], and there is a whole group of tools like this for database CLI's [1], including PostgreSQL, MySQL, MS-SQL, and VerticaDB.

It's a shame that each of these projects have to somewhat re-invent the wheel (though prompt-toolkit does a lot of heavy lifting [2]). And it's even more of a shame that each of these tools require a seperate environment. So, you have to exit Google's interactive shell to do something in AWS.

[0] https://github.com/awslabs/aws-shell

[1] https://www.dbcli.co

[2] https://github.com/jonathanslenders/python-prompt-toolkit

Eh, I wouldn't say it's just for less terminal savvy users. Running -h, finding the command you want, putting it in, is slower than this method. No matter how skilled you are, if you aren't using GCP CLI all day every day you're gonna forget stuff and this is a quick and easy way to remember it.

It's definitely not for less terminal savvy users. If anything, it's for more savvy people, as less savvy people hardly use tab completion, hotkeys and vi/emacs mode. It's meant for power users. Tab completion makes you faster and more efficient. I do agree though that it should be standardized.

AWS also has something similar called AWS Shell: https://github.com/awslabs/aws-shell

Azure has one too

https://docs.microsoft.com/en-us/azure/cloud-shell/overview

An interactive CLI (this) is not the really at all the same thing as a JavaScript TTY connected to a container (Cloud Shell).

(Though, Google does also have a Cloud Console that is comparable to Azure's Cloud Shell.)

Cloud Shell has an interactive mode - https://docs.microsoft.com/en-us/cli/azure/interactive-azure...

That's the CLI (it's right there in the title of the article)... which yes, can be run from the Cloud Shell, as the Cloud Shell is just a bash docker container that has the CLI pre-installed, etc.

  python3 -m venv az.env
  source ./az.env/bin/activate
  pip install azure-cli
  az --help

Although ms has a strange fetish for complicated installation, one might prefer running it from docker:

https://docs.microsoft.com/en-us/cli/azure/install-azure-cli...

https://pypi.python.org/pypi/azure-cli

With the interactive CLI, we set out with a similar mission as other cloud CLIs - our first priority was helping users use the GCP CLIs including gcloud and gsutil. With our Interactive CLI, we’ve tried to build something that doesn’t just help new users discover what they can do, but also helps make more advanced users productive, for scenarios such as piping between commands, and shell redirection for read-edit-write workflows. The Interactive CLI provides a full shell environment, and isn’t restricted exclusively to the use of GCP tools.

Interactive CLIs like are a little different than a "cloud shell", which provides a fully cloud-hosted CLI environment. If you want a fully curated cloud-hosted option, check out https://cloud.google.com/shell/. Note that the Cloud Shell includes the Cloud SDK.

Here's an alternative approach for an AWS cli (old, and stuck in beta/alpha but I still use it for quick ec2 operations)

https://github.com/carlsborg/dust

Is this an open-source library one could use to make one's own interactive tools? Just curious. Anyone have pointers?

Edit: I am slightly familiar with this family of tools. I was curious if there was a pointer to exactly the one used here.

I think this is quite popular: https://github.com/jonathanslenders/python-prompt-toolkit

For Rust this library seems nice: https://github.com/kbknapp/clap-rs (it generates autocompletion scripts for shells)

To build on Rust's options, there's the Structopt library[0] that generates a CLI interface using clap-rs from an annotated struct, which is a very, very nice experience for making command line tools.

[0]https://github.com/TeXitoi/structopt

It's a pretty neat tool. I've played around with it a lot, and it's used in the aws-shell[0] to a very similar effect as the OP. (Disclaimer: I work for aws and have contributed to the aws-shell.)

[0]: https://github.com/awslabs/aws-shell

I believe this looks awfully familiar to this: https://github.com/c-bata/go-prompt (which is based on the previously mentioned `python-promt-toolkit`)

Still requires Python 2.7, right? What year is it again?

Thanks for the feedback. We are actively working on Python 3 support. Stay tuned!

Are you sure? App Engine Standard Environment has had that on the "roadmap" forever. Almost 10 years in fact.

https://issuetracker.google.com/issues/35876441

http://www.googblogs.com/enhancing-the-python-experience-on-...

Does it? I don't see that written anywhere, and prompt-toolkit supports python3.

"Cloud SDK runs on Linux, Mac OS X and Windows, and requires Python 2.7.x."

https://cloud.google.com/sdk/downloads

This is awesome, interactive CLIs are great for simple use cases. I hope they continue to have support for non-interactive scenarios so that automation can continue to work (apologies if I missed that in the article).

Thanks. Yes, this is completely additive to the existing SDK.

While we're on the topic, Cool Retro Term is open source or free and so much fun to play with. I have a real thing for the amber monitors. I got to see some ancient ones still operating the world in my early career on the dying open outcry trading floors of the American Stock Exchange in the mid 2000s. LMGTFY: https://www.google.com/search?q=amber+monitor&tbm=isch&sourc...:

Yes, I'm adding to the tangent here, but..

I use these 2:

https://github.com/sjmulder/trickle

http://sensi.org/~svo/glasstty/

in combination with a regular terminal application to achieve my retro vt220 VAX/BSD UNIX goodness. Doesn't have the phosphor fade like the above, but still feels pretty 'right'.

Here is a link to the github repo with the images and codebase: https://github.com/Swordfish90/cool-retro-term

missing good old googlecl which Google killed themselves by making OAuth2 mandatory and not beeing able to switch from OAuth1 to OAuth2 in their own command line tool: https://code.google.com/archive/p/googlecl/issues/573

I tried this with kubectl, but it crashed... so I used gcloud feedback to send a stacktrace, it sent me to a page with a 400 response.

Overall, seems a bit too early to start promoting this for any real use.

I made something even better. Its for AWS though: https://github.com/svolpe43/cfsh

Nice! I worked a little bit on something similar for Azure in PowerShell. PowerShell has a really cool feature where you basically implement the filesystem navigation API for your app in C# or similar - how to show a path, get its children etc., and then all the PowerShell built-ins just work when you point it there.

That is pretty cool! I had to write all that stuff from scratch.

I just looked at the first animation. If I find myself typing commands this long, I know I'm doing it wrong.

You must've not used the AWS or GCP CLI tools before... the commands are all very verbose with lots of mandatory parameters. There's really no way to avoid long commands.

I have not. But I have used several other similar CLI tools. I prefer short programs of my own instead of long verbose commands.

Did anyone manage to get this to work with fish shell?

Feels... PowerShellish.

Err, how are they in ANY way similar?

LOL @ the bright green on black terminal pictures. How shall I say it, it feels very "l33t". Too bad they didn't use more normal terminal colours, it would improve readability IMO.

It is using my terminal's standard colour scheme here (grey on black, with "bold" text being white.

I guess it just uses whatever theme your terminal is configured for.

I don't think its a "l33t" thing its just cultural. A fair number of engineers grew up with old computers that looked like this: https://i.imgur.com/WERwVsS.jpg

Personally I learned to code on an old cathode ray tube monitor with green text, hooked up to a Tandy 1000. The CRT made a lot of heat and emitted a faint electronic tonal noise when it was running.

I think the use of green color in terminals today is kind of a throwback thing to those ancient devices. Even though I wouldn't really want to use an old CRT today I still remember the CRT I grew up using fondly as a much more "live" feeling device compared to modern electronics that are much colder, silent, and sterile bright. When I see a green text terminal it instantly feels familiar and comfortable, in the same way.

The eyes are more sensitive to either yellow-green or blue-green, depending on whether there is light or little of it. Amber/orange/yellow was probably the second most popular choice for terminals back then.

on the down side, if you work on one too long, it fries those particular cones in your eyes pretty good, at least in the case of green and if the contrast is too high..

my daily driver is grey-on-black these days for that reason, though I keep a warm-and fuzzy green-on-black with vt220 font and slow-baud emulator around for the occasional one-off shell command.

What? The green on black contrast is really easy to read and blends well with other colors for syntax highlighting. It's a super common scheme among developers...

I wouldn't say it's a common scheme. I've never seen someone use it IRL, only on pictures online.

I do agree it's not a disagreeable contrast.

It's pretty normal and expected for those of us that spent significant time on an actual VT220 or similar. Maybe the choice was just driven by someone similar.

It also indicates that "this is a terminal" to someone generally browsing the page.

Or maybe they are fans of The Matrix.

I've been using a green on black scheme for years now, imo it is the best color combination for low light environments.

Amber on black (à la DEC VT420 terminals and some early PC monochrome monitors) also works well in low light.

These aging eyes have configured all my CLI work (which is most of it) to use amber on black.

Reply on news.ycombinator.com