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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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...
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.
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.