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 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.
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).
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.
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.
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.
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.
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.
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.)
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).
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...:
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'.
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
Readit News
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.
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.
We deploy that onto GKE as a service and have our apps use that. Some setup required but cleaner overall.
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.
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.
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.
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.)
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 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).
Do you expect other teams to halt what they're doing and wait for other teams to finish before they continue their work?
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
https://docs.microsoft.com/en-us/azure/cloud-shell/overview
(Though, Google does also have a Cloud Console that is comparable to Azure's Cloud Shell.)
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.
https://github.com/carlsborg/dust
Edit: I am slightly familiar with this family of tools. I was curious if there was a pointer to exactly the one used here.
For Rust this library seems nice: https://github.com/kbknapp/clap-rs (it generates autocompletion scripts for shells)
[0]https://github.com/TeXitoi/structopt
[0]: https://github.com/awslabs/aws-shell
Deleted Comment
https://issuetracker.google.com/issues/35876441
http://www.googblogs.com/enhancing-the-python-experience-on-...
https://cloud.google.com/sdk/downloads
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'.