I'm only a small user of cloud providers, but find Google cloud engine much more user friendly than aws, so why is amazon still capturing the market? I don't see the downsides of GCE.
* AWS has the momentum and reputation. They've been in the game a while.
* Google has earned a reputation for shuttering products with little warning. CTOs really dislike an ad-hoc forced migration.
That said, I've been hearing good things about GCE. If they can polish their image WRT stability, they'll be grabbing marketshare in a couple years.
Exactly why we smiled and said "thanks but no thanks" when their salesfolk hit us up; I can't trust that any given Google platform will still be there in three to five years.
Google App Engine soured me to anything cloud related from Google. It's the worst product ever launched.
There's a million things wrong with GAE besides performance, but if we just focus on that, where to even start? When I first took my last job using GAE, I was able to improve the performance of one of our apps in my 2nd week on the job from requests taking anywhere from 3-14 seconds to sub 1 second. That sounds good, but actually the original authors of the app didn't really do anything too bad, it was just they tried to write a standard web CRUD app in Django.
The answer to improving performance was mainly to never query their data store if you could help it. Solid advice for most apps, only the queries were completely unpredictable. Pretty much the standard Google answer for all App Engine is to do everything in memcached. OK, again, fine, but then memcached started being unpredictable. Google Answer - we'll develop private memcached to let you tweak it more. OK, fine, but it's still not as fast as when we run memcached on AWS.
Even when we ran our site with 99.9% cache hit ratio, we still had erratic performance. We next switched things to do more on the client and ran an Angular SPA app. Again we saw benefits of course, but still things sometimes were slower than we wanted. Simply Google's billing API requests and their slow servers serving requests tended to be the problem, which was often something we had no control over. And that was basically the theme of other problems we had. We figured out the requests problems at the beginning FYI and told Google, and they simply said they would work on it, but actually over time things often got slower.
App Engine is a terrible platform and most of the benefits can be replicated by various libraries out there for deployment, versioning, caching, etc. or through admin panels in other services like AWS. If you want to lock yourself into terrible APIs that do things like intercept your POST and re-issue it as a GET, go for it. If you want to start building your apps around billing patterns rather than proper architecture, go for it (how can I do y instead of x to avoid being billed?). I could go on, but yeah App Engine is pretty bad. It gets you going from dev to production somewhat quickly, but don't many frameworks + cloud providers do that now? The only real benefit I found which you could argue is that you alleviate some of the security challenges, but that's assuming you trust Google's environment and configuration (which you have essentially no control).
See, there I go.
Reading your rant (and the extended version below) definitely gave me a misery-loves-company sort of smile though, so thanks.
That and the slightly weird authentication/setup process (rough memory of that, really) were the obvious downsides for me.
Obvious upsides to GCE would be fractional hourly billing and allegedly no-need to prewarm loadbalancers. And probably there aren't mystery settings that require you to email someone to ask them to be set, and there probably aren't features that you can only access through the GUI with API support coming later -- though that is just a guess :)
A downside to GCE would be if you wanted any of the various other services that AWS provides, since they provide a ton more. AWS also has really good service -- Google may also, but I haven't had direct experience.
Yeah, the authentication/setup process is weird. OK for individuals but very confusing for team permissions and the permissions are very basic
But despite this I still prefer GCE over AWS.
* GCE documentation is much better. Understanding things from AWS docs can be an exercise in frustration.
* The console is easier to understand and more responsive. Command line tools have good UX.
* Instances boot up faster and seems to perform better and have more predictable performance
* Automatic discounts without reserving instances. (It's awesome!)
* Documentation - On the surface, GCE docs always looked better to me until I realized how many mistakes there were and things out-of-date. Not to mention there was too much of the obvious documentation and not anything regarding subjects where I'd actually want detailed docs. Although Amazon's docs are trash, they have the benefit of everyone and their mother writing about how to do x, y, or z. Whether that's a benefit or not, it depends on the author.
* Console - The console was sometimes more responsive depending on the action, but for some things was worse. Overall I'd give this one to GCE as well, but I think the GUI was a mess in places. Perhaps that's more based on my total usage of Google Services, which are a superset of GCE. Regarding command line tools though, I felt these were awful, slow, poorly documented, and buggy. Again, maybe an update fixed some of this. Google has a really bad history with consoles. Amazon's GUI is 90sish at times, but it's been pretty good to me and the API just works.
* The answer to this one is really it depends on the machines, location, etc. GCE has some advantages here that are well documented, but performance of a running machine was never really a problem I faced on Amazon provided you select a good instance type.
* Can't argue here. Amazon does like to give out its share of freebies though if you are a big enough customer or paying attention to the community.
* I mainly use the GCE console and I found it fantastic. Showing all VMs from across regions is itself a big improvement from AWS console. The project dashboard was a mess. The new beta console is better. I found Google's command line tools much more intuitive and very easy to keep up to date. They have consolidated some previously separate tools into a single gcloud utility.
When using the python bindings, you could not simply request N instances using image ID X. You had to come up with an (account) unique name for each one, like webserver-01 and webserver-02.
It is somewhat fundamentally anti "cattles not pets", which led to some weird code in libraries to try to pick IDs that were not used.
My experience here is approximately 1 year old.
Which services are you comparing? We (sadly) make our pricing table for Compute Engine (GCE) look a lot like EC2. Just looking at rates misses the advantage of per-minute billing for certain workloads (e.g. Batch compute or autoscaled anything) and our "sustained use discount" which gives you roughly the same discount as EC2 reserved instances but without having to do anything. As I said to someone recently, our model isn't super simple to "understand" but it's way easier: we always give you the best price.
The same thing goes for GCS vs S3, general network pricing, etc.
Have you tried our pricing calculator (https://cloud.google.com/products/calculator/)?
Also any idea if your folks are ever going to let people set RDNS records for their IPs? It has been requested but no one at GCE seems to communicate.
If Google doesn't have configurable RDNS, they're not a "one-stop shop" for all hosting needs. For example, a customer wouldn't send transactional e-mails from a server at Google because the lack of RDNS would affect deliverability.
Moreover, (sadly) your example doesn't hold anyway: sending email is actually something all cloud providers try to avoid (SoftLayer in Brazil lately is the notable exception). So getting anyone to whitelist your smtp and other ports is usually an unpleasant experience.
Last year Microsoft also announced Azure support for reverse DNS entries. So I would anticipate Google getting on this "bandwagon" fairly soon too. Just my guess though!
We've got Persistent Disks aka PD (logically similar to EBS / network storage) that come in both a "hard drive" variety and an "ssd" variety, as well as local SSD.
I assume you're talking about one of the PD products, most likely PD-SSD and comparing to one of the EBS offerings (either the new one or a piops one)?
If so, unlike traditional EBS, PD scales throughput according to disk size [1]. You get 30 IOPS/GB up to 15k or so. As far as latency goes, what instance were you testing on? Your VM's I/O competes for cycles with your vCPU (this is true of all KVM-based virtualization), so if you spike up your CPU you can easily "starve" your I/O threads or vice versa.
As to your DNS question, I'll have to look into that. But where are you trying to communicate? (I mean clearly you found me, but I mean where else)
--- /dev/sda1 (device 20.0 GiB) ioping statistics --- 13 requests completed in 12.5 s, 161 iops, 647.9 KiB/s min/avg/max/mdev = 213 us / 6.2 ms / 18.2 ms / 6.0 ms
This is pretty bad, everything on AWS is under a millisecond.
I submit feedback through the feedback links in the panel and on the product forums. Since you folks don't offer any other way of communicating.
Why did we want to leave? Honestly, it was a combination of things starting with the hateful and broken App Engine platform (API, admin, everything) to the usual Google nonsense of cancellations, adding useless features, bad prioritization of bugs, lack of fulfilling SLAs, etc whether it was GCE or another service. After working with 2 startups that were based heavily on Google's cloud, I can't recommend them unless something dramatic has changed. I can go into more details in private and a few publicly but it would be a huge post so I'll mention only a few things here.
Suffice to say, I found GCE to be anything but friendly compared to Amazon at all levels. While Amazon has a confusing and sometimes horrible admin panel, it's been my experience as an AWS customer for a long long time that it just works most of the time. Most of the time sounds bad, but it is better than "rarely" or "never" we experienced with Google (more later). When something is broken, Amazon generally fixes it or even a primitive retry will suffice. If something was really broken, Amazon gave us free credit, while Google either lied or hardly budged on bills (even funnier since Google was one of our investors).
A related and huge problem we had was that Google tended to make platforms, libraries, features, and services very 1/2 baked. Google is perhaps good at ideas and maybe even better than Amazon at building a solid core, but there is absolutely no follow-through. Too many times we encountered libraries and services that were terminated or overhauled because something was fundamentally broken. Worse, we pointed out big problems months or years in advance along with other customers and the community but saw no action. Google's dev team would continue to pretend nothing is wrong until either terminating or going back to the drawing board. I've never experienced a large company burying its head in the sand as much as Google. I love Google search, but I refuse to use any of their cloud products with the attitude that I've seen top to bottom, from sales to dev.
Another very important point I think a lot of inexperience people neglect - AWS has great support when it comes to libraries and integrations. Pick x language and generally you can find at least a working version of a library for whatever service you are using, including new features. Google's cloud services in my experience are filled with broken, slow, horrible libraries, including the official ones. As an example, there was a really bad (probably still open) form encoding bug in App Engine with multi-part forms that's been broken since almost the start of App Engine (basically, anything non-Ascii got corrupted). It's never really been fixed despite multiple people giving Google tons of data, patches, and workaround. We even got on the phone with them about it several times. GCE has honestly not been as bad as App Engine in terms of fixing things, but it also lacks features and library integrations.
As an example of a more specific GCE problem, anything that has issues with multi-cast had to have tons of patches. There was a special adapter for ElasticSearch when we deployed it on GCE that constantly had to be updated, and if you read about it, you'll see it's mainly a GCE thing. Pretty much every service, tech, or library we used that was more serious had similar issues - there was always a workaround or feature you had to manually implement that you didn't realize you took for granted on Amazon. The deployment story just given the tools was always far better on Amazon for example, but that may have changed.
Then there's installing and developing against GCE. Most of GCE for the past few years was command line only. That's fine if your command line is well written and well-documented, but GCE is most certainly not. The command line didn't even really work on Windows and not even really with something like cygwin. You can laugh, but at my other company we did a lot of DirectX and Xbox development, and developing on other platforms didn't make that much sense. Unfortunately some people in our company decided not using AWS would be cool. Developing against GCE once you got things working was no treat and we felt we often had to write tons of new libraries to do basic things that existed somewhere in the Amazon stack.
As far as the documentation, Google's services are usually out-of-date and full of mistakes. You could argue the docs are better than what Amazon has, however Amazon has the benefit of the community at this point that generally can answer your questions quickly. Moreover, Google in its own documentation often brags how good their docs are, while simple things like broken links or deprecated features are usually all over the place. How hard is it to run a broken link checker at least? The community is a huge topic, but I'll add that support was so bad at some points that the official line was to ask on StackOverflow instead (fine, but you're a huge company with a tiny install base at the time, wtf).
GCE did (does) have an admin console in addition to the command line, but the early versions were very limited. The last GCE console I worked with was in-step with most Google admin consoles looks like an ASP 2.0 app. Most things in the admin console are far inferior to the command line and full of bugs. Even finding the right settings in the admin console are a complete nightmare and sometimes require you to open other Google Services that you would think have no impact on GCE, App Engine, or anything else, and yet do. They often re-arrange how all of this works, but then leave parts of the old sites still running, so you end up with crazy nesting, conflicting options and navigation, and randomness. Mostly you feel like some dev somewhere kept saying, "I don't feel like doing this, so I'll put this all here because I can." It all looks like a bad assignment done last minute in a computer lab for a comp-sci class.
I know I seem a bit harsh, but I really wanted to try something new besides AWS the last few years. I joined 2 companies that did exactly that (independent of me), and that ended up terrible for both. There really was not much I couldn't do on AWS that GCE could do, while AWS could do plenty of things that GCE could not do at the time. AWS was far more reliable, stable, and well-supported for us as well, along with my own startup, and my past companies. Given I was a customer of Google's for a long, long time along with Amazon's and little changed with Google, I doubt it is much different now. Maybe someone can correct me, but usually when we get into these kinds of debates, the person with high opinions about GCE and the Google Cloud in general has not been on it long and certainly has not hosted a serious environment on it. I find Amazon as a company somewhat repulsive like Google in various ways, but AWS for all its faults is definitely more popular for a reason still. I hope Google can push Amazon to make their platform better, but from what I have seen the last few years, GCE is half-baked and only suitable if you're throwing a few small or personal servers in the cloud without significant interactions between them.
Sorry about your experience. It sounds like you were mostly burned by App Engine, and the unfortunate situation of a migration from old to new consoles (we have a multi year deprecation policy in some cases). The old admin console was truly awful, however within just the last few months the final nail has been driven into its coffin: you can manage your App Engine custom domain settings and SSL from inside the Developers Console rather than go through Apps.
As someone on a side thread mentioned, we even have a refresh of the new console in Beta for the next month or so (want to make sure we didn't suddenly break some user flow). The integration between products is vastly better than it was 12 months ago and with gcloud (the CLI) and the Developer Console gaining maturity and scope, even three months ago the experience wasn't as good.
tl;dr: Your comment is fair, but things are changing (and have changed) quickly. Take another look with a free trial account?
I'm not OP, but I tried that in a bake-off a few months back. Setup went well, I got some free trial credit-- and immediately found my account turned suspended due to fraud concerns. Note that this was the same payment details I was using (and continue to use) for Google Apps for Domains.
If GCE can't get the simple things like billing handled, I've got little faith in their ability to solve the harder problems.
Curiously, a few months later (this week in fact) I got a message out of the blue telling me that my account was unsuspended. Rather obviously, I had already gone with AWS around mid-summer...
I think my comment above still stands though: everything has improved a lot (particularly technically).
I'm an early GAE adopter, still running a system in it to this day. I've seen your kind come and go many times. Sometimes it's a well-placed engineer, sometimes a technically capable and empowered support rep, an evangelist, something. These people show up in the community, they're empathetic, responsive and openly talk about what goes on behind the scenes. Sometimes they blog (http://ikaisays.com) and go much deeper than the docs ever would. They make you think "google really is different."
And then they disappear. And then there's crickets for a while, maybe some corporate types putting out fires and helpfully pointing everyone at the issue tracker. And then it repeats. Consistency in communication matters a lot, especially when your users are putting their livelihoods in your hands.
1. Why are Credentials under API manager?
2. For API keys, OAuth 2.0 client IDs, Service accounts etc, you should add a "Last Used Date"
3. I have no idea what the service account email address listed in the Credential page is used for
4. How do I do more fine grained permissions? i.e I want a team member to have access to GCE but not Big Query. To view Storage but not delete it etc?
2. Good point. I'll see why that isn't the case (I agree strongly, it'd be nice to know if this hasn't been used so you can revoke it).
3. A lot of systems require a user/email to identify the "person" taking the action. So this one is a crazy auto generated one for you. You didn't say it, but I'd love to be able to name them (like "Default GCE Service Account" or "Service Account for that Binary I built for deploying stuff").
4. This is something Google Cloud is behind on and we're working on it. For Storage (and PubSub) there actually are much finer grained ACLs (and you could add them as just a VIEWER role, etc.). I don't recall if we yet support the "Bob can use GCE but not BigQuery". Expect updates here soon.
Edit: more blank lines
2. Ok.
3. Yeah. Naming is a start. I also want to know what does it have access to.
4. Yeah. It's quite messy. Also there are Service Accounts in "Credentials" and also in "Permissions". There are multiple "Google APIs service account" in Permissions. I have no idea what they are for and what does it have access to