How Diane Greene Transformed Google's Cloud

sorry if it's the wrong place to report an issue that I faced recently with GCP.

I had reached the limit of max projects one can have in their dashboard. I deleted some projects and when I tried to create a new project, I was getting the same message .

I had to wait for a week to create a new project ( the time window in which user can stop project deletion )

this really prevented me from trying some new services in spite of GCP giving generous $300 credit.

We're a paying customer and I understand tiered support is available (as it is with every vendor) but there's a distinct difference in on-boarding, which is even more important and has to happen before we're a stable long-term client with a support contract. GCP is very barren in on-boarding resources and opaque in happenings. Here are some of my recommendations:

- The APIs (which are quite literally how applications connect to the platform) need a lot of work. I know there are idiomatic versions in progress but this has to be improved rapidly, like yesterday. They just don't seem production ready (they're even called alpha). I don't want to dig around github, I just expect to use them in whatever major language I'm writing.

- Documentation has recently gotten much better (good job!) but was terrible for a long time and is still confusing in parts. Add more solution/use-case oriented writeups. This is often the best way to understand how to use a new service rather than wondering how to make it best fit our app.

- Send an email as soon as an account is spending more than $1k/mth and see what they're doing and how you can help. Don't mention anything about buying a support plan or offer it free for the first quarter until everything is setup. The money is far outweighed by the goodwill.

- Properly staff the startups department so they can vet companies instead of outsourcing this to VCs/Accelerators. Right now you're turning away many companies that are bootstrapped or have other needs and are actually focused on building sustainable/profitable companies - the ones that will become long-term paying clients for you.

- Put out a roadmap with more detail or let companies take part in planning the next features. There seems to be only vague indications of what's coming up in the future.

Formality, reliability, assurance and easy access are critical, especially when you're asking companies to build on you as a foundation. The basics of computing are becoming commoditized so it's important that the services and service are able to differentiate.

I get the sense that the GCP team is aware of all this though so good luck, we all want a great platform and I can't wait to see what's in store.

Disclosure: I work on Compute Engine.

1. https://cloud.google.com/compute/docs/regions-zones/regions-...

My comment was somewhat terse (to remain as brief as possible) so perhaps it wasn't clear. My logic was "Google.com is supremely reliable, which is a supremely difficult task, so Google must have really good engineering chops, so their products must be really well engineered." In other words, I was saying that I had in my head an image of Google being filled with great engineers building generally well engineered products. I wasn't commenting on reliability of service, which we haven't had any issues with that I can presently recall (we're only in us-central1-c).

> [Edit: And please reach out to support! Don't be silently unhappy, have someone call us up, even if it's just to strangle a PM about how difficult it is to use.]

Google provides no way to contact support without paying them for a support contract. It makes no sense for us to pay Google for the privilege of debugging their service/software. And I've crawled my way to support through sales before. For all my effort, and an inability to use the platform for a week, I was left with "Sorry, here's an issue tracker". The same kind of issue tracker that's filled with stagnant issues that are months or a year old.

The same argument could naively be made about AWS, which also charges for the privilege of reporting issues to them. But in all the years that I've used AWS I've only once needed to contact them with a problem. It was a billing issue, which they fixed, and then comp'd us with free service for the trouble. With Google Cloud we would need to diagnose, debug, document, and report an issue roughly every day of development.

Some examples:

Cloud Storage doesn't support multi part uploads. The best it seems to have is the ability to compose objects. Honestly that's a better system than dodgy multi-part or resumable uploads, but there are hard restrictions on composing objects. You can't compose more than 32 objects, and you can't compose more than 2 layers deep. So with two iterations you can compose at most 1024 objects. That's not great for uploading large objects through our servers in small chunks. If our chunks are, say, 10MB than the largest final file size we can achieve is only 10 gigs.

On AWS when connecting EC2 to RDS we just threw together the VPC and then configured the EC2 servers with the RDS's hostname. Easy. On GCP we basically _had_ to use Cloud SQL Proxy. Now, again, it seems that Cloud SQL Proxy is a better system overall, but it required fiddling with our server setup, upgrading our MySQL library (which caused other issues), and other random dickery. Another annoyance.

We use Go for our backend servers, and GCP's Go API libraries are all autogenerated, and might as well not be documented. We frequently receive the opaque error "required: required" when trying to blindly figure out the API. It's become an office joke. "Why won't Ubuntu recognize this Wifi card?" "Because required: required man, obviously."

Google App Engine's dev_appserver.py completely broke after an update, caused in part by another Google library being installed (protobuf...). Still not sure if the fix was rolled into a release yet...

The web interface frequently breaks and requires manually refreshing, and it's generally slow and unresponsive on the best of days. It also loves to switch me to my personal account and throw errors because I don't have access to the project I was trying to access...

The "scopes" for launching a compute instance aren't documented to the extent that we know which ones provide what privileges. Really the whole privilege system on GCP is a mess and pales in comparison to AWS. I recall some obvious permissions were just outright missing a few weeks ago.

We have some Go code that uses the API to launch a compute instance. When specifying the scopes on the command line for launching an instance they seemed to require being accompanied by the service account "email" address. So in the Go code we specify the service account email and the scopes. One day during development I forgot to set the service account, didn't notice, and everything worked as normal...

I was not able to find an obvious place where preemptible instances report being killed. Not in the activity logs or the serial console log (which is not saved/available when the instance shuts down). shrugs I didn't feel like looking deeper into it.

Startup scripts specified when launching a compute instance run every time the instance starts. Makes sense in retrospect given the name, but it's in contrast to AWS where the script runs once, and in contrast to the example startup script given in the documentation (which installs things ... not something a script that runs every time the machine boots up should do). And it's not very helpful. A script that runs once ever is more practical than a script that runs every boot.

Figuring out exactly how to cook up my own compute images in a format that GCP likes required finding a random video on YouTube from a Google developer.

Some of the documentation (this was either for Datastore or some part of App Engine) is actually just a bunch of marketing copy with no technical meat to it, leaving me to just assume how various features work (because they aren't actually documented anywhere else).

New strange behavior from MySQL running on Cloud SQL that we still haven't nailed down (random lock contentions) that we never encountered on RDS.

Random networking failures on fresh compute instances.

Random upload failures to Cloud Storage.

Transferring objects from one bucket in Cloud Storage to another bucket using the transfer interface resulted in the ACLs being lost for all the objects.

Random things get deprecated every other week. Image aliases last week, something about the Cloud Storage metadata was weird the week before that, etc.

The CLI randomly failing to query for the list of compute instances for tab completion, instead just tab completing an instance that was deleted 10 minutes ago.

This was my source: http://www.recode.net/2015/10/22/11619964/google-has-its-hea...

The # is from Oct 2015, so it's entirely possible that my number is very out of date. Couldn't figure out how to amend my original comment, so adding this one as a substitute.

Google Apps for business are so bad though, I genuinely don't know why a company would pick it over 365. I could maybe see an SMB, but 365 is so robust in its offerings and just so much better all around.

My former employer was on 365, my new employer is on Google Apps. It's like I've been thrown back into the stone age. (Went from a large corporation to a start-up.)

I feel like an SMB is not likely to do volume purchases of Chromebooks, but a large corporation is...which Google just fails at in their offering in the office space, imo.

Off-premises cloud products in general are useless for any company in aviation, nuclear engineer, military, etc. Unless they’re in the US, then usually they can afford to do it, as the cloud services are in the same country.

Looking back at the snowden leaks, containing proof of the NSA serving NSLs to cloud providers and hacking Airbus servers to provide internal data and blueprints to Boeing, so Boeing would win a contract, shows that trusting US cloud providers is just as risky as trusting chinese ones.

But for your grandparents that have nothing worthy of espionage, a Chromebook is likely good enough.

There's practically zero administration involved.

I'm sure there are companies who could benefit from this; but they need to accept that they rely on a single provider and its uptime for all their software and data storage requirements.

This is a huge trade off, and must be considered carefully.

The foundation-type entity is correct though, she will still be overseeing how it's spent.

Disclosure: I work on Compute Engine.

The German laws on that are interesting, and I don’t think Google’s Cloud can every comply with them – because you may not give any foreign third party access to personally identifiable data, or move it to a country with lower data privacy laws, hosting it in a Google-provided system would be quite problematic.

Although the laws are a pain (including for me, even if you just host an IRC bouncer for a bunch of people they become quite interesting), I wouldn’t trade them away for anything, because they help ensure that all spying that happens can be democratically regulated by those who are spied upon.

cloud sql offers a single version of mysql

aws rds has multiple versions of postgres, mysql, oracle, mssql and aurora

The article is pretty clear on what's she's done so far. There's no denying that they have a lot of work to do but if you're actively using the platform then you'll notice that there has been a lot of change in just a few months with them, which should all help to increase that customer number.