This was one heck of a rundown of different GCP options and problems. I haven't used as many services as the OP, but definitely most things that did overlap pretty much echoed my own experience. Specifically, support and billing. We've used Gold support for a while, and our experience wasn't great. Pretty much the same as the OP described with Silver. Perhaps response times were slightly faster I imagine, but I would…
I am in a process of choosing between AWS and GC, and the reason I'm leaning towards AWS is that this is Amazon's primary business. They care about it and they know how to deal with customers. Google on the other hand... They could decide tomorrow that GAE is no longer something they want to deal with, and shut it down. Not likely, I agree, but their incentives and mine are not aligned.
I've spent a good bit of time with both now. GCP has some real potential but AWS support is nothing short of fantastic. I leaned on them multiple times and had people actively working with me on the phone to get problems solved, following up with me, etc.
I was impressed.
Just got on the Silver plan with Google and only had one support ticket so far, but they got it resolved. Haven't really needed to push it yet, but we will see what happens.
Can you elaborate on what is wrong with Cloud SQL? I have next to no experience with it GCP Cloud SQL, but use AWS RDS a lot.
Cloud SQL itself is fine...it's just hosted SQL. That said, there is a lot of google-bespoke code for interfacing various parts of their cloud with it. Cloud SQL Proxy has a lot of gotchas and hard to debug. For example, the per-instance connection limit between app engine and cloudsql is 5, and it's impossible to know how you're bumping against that. Tuning is a frustrating process, and google support hasn't been to…
The limit was never 5. It used to be 12 and now it's 60.
One thing I didn't see mentioned in this article is Firebase. It feels like a hidden gem lurking within the overall GCP offering, and may be overlooked by devs who're not doing mobile-specific work. For me, Firebase was the gateway drug that got me into GCP. I successfully built and hosted the backends for a couple of iOS apps using Firebase. The best parts were cloud functions and built-in sync (including offline/oc…
> One thing I didn't see mentioned in this article is Firebase. Can confirm, I'm also building my startup off of Firebase. Super easy to get up and running with. I was talking to a friend at Amazon about how I create serverless HTTP entpoints and he was impressed that getting started with it was a 10 minute affair from "never done backend programming" to "REST endpoint setup." Another half an hour got me full end to…
> I can'd do encrypted endpoints on localhost, which means 90% of my API can't be tested locally. Having to deploy to the actual service seriously adds to my code-deploy-debug loop!
Try using ngrok (https://ngrok.com/). It can forward public HTTPS to localhost HTTP.
Interesting take. In my job, the idea that cross project connections would be rare or that it’s good for all resources in a project to have access to all others seem a little crazy. I agree it’s a far safer default that AWS’s, but it’s not _good_.
The biggest wall for me in setting up GCP is that the resources and accounts are all so tightly tied to personal Google identities. This is unworkable for me, but I don’t see any clear way around it. We’ve set up our billing account on a shared account but it becomes hard to work with around personal Google accounts (even moreso when they are corporate Google Apps accounts). The AWS IAM identity model makes much more sense to me, but perhaps I just need a new paradigm for thinking about it. Are there any good resources for relearning how to think about resource ownership in the GCP model for AWS heads?
I've been jumping between AWS and Google Cloud ( with a bit of Digital Ocean sprinkled in ) for the last several years. I chose Google as our cloud platform when we founded our company last August. I could War and Peace a bunch of things but that article does a very nice job in the details. Instead, I'll give a one liner: AWS is to Linux as Google Cloud is to FreeBSD. "Rock solid performance and everything is exactly…
Your analogy is confusing me. On GCP, none of the tools have all the features you expect?
Although the author mentions they haven't had experience with AppEngine, it's the reason why I love Google Cloud SO much over anything else. If you're a startup running something on Elixir (or even Rails), AppEngine's experience is hard to beat. Not many people do know: * You can run multiple microservices on AppEngine under one application. * Each of these can have many versions serving different percentages of traf…
The generous free tier in App Engine is also very nice - lets you run a lot of personal / experimental stuff for free.
This was one heck of a rundown of different GCP options and problems. I haven't used as many services as the OP, but definitely most things that did overlap pretty much echoed my own experience. Specifically, support and billing. We've used Gold support for a while, and our experience wasn't great. Pretty much the same as the OP described with Silver. Perhaps response times were slightly faster I imagine, but I would…
I am in a process of choosing between AWS and GC, and the reason I'm leaning towards AWS is that this is Amazon's primary business. They care about it and they know how to deal with customers. Google on the other hand... They could decide tomorrow that GAE is no longer something they want to deal with, and shut it down. Not likely, I agree, but their incentives and mine are not aligned.
Interesting idea about being Amazon's primary business. Would you happen to have pointers about AWS's size relative to Amazon's other business?
One thing I didn't see mentioned in this article is Firebase. It feels like a hidden gem lurking within the overall GCP offering, and may be overlooked by devs who're not doing mobile-specific work. For me, Firebase was the gateway drug that got me into GCP. I successfully built and hosted the backends for a couple of iOS apps using Firebase. The best parts were cloud functions and built-in sync (including offline/oc…
Since you were already at Amazon, I assume you compared Firebase to AWS Lambda? Could you tell us why did you end up prefering Firebase?
Firebase is very much easy to get started for mobile apps. You have nice console to create project, and as developer you deal with just its SDK, one CLI and simple API. For something similar to Firebase in AWS, you need to make use of Lambda, API Gateway, DynamoDB, Cognito separate products, which has steep learning curve. And then you need to know the AIM security to get started. AWS has a Mobile Hub product which is trying to make things easy to create mobile apps by automate some of these AWS products for you. So now you have to learn awsmobile CLI tool on top of the core awscli tool. And if you develop for the web, they have this AWS Amplify Javascript library on top of basic JS SDK library which has a higher abstraction thus to make things simple (or worst). If you're new to AWS, you often struggle with which library should one learn and use. And if you use AWS Ampify and read the documents, it is as if the library is build for React. I'm not sure why AWS can be so married to one web stack. So much emphasis and priority is given to React and React Native in this library. They will give the excuse that React is what their customer wants. They now have mature React/React Native Amplify library thus giving the impression that to use AWS its better to use React/React Native. So they spend resource on AWS-Amplify, even move one of JS cognate-identity-js SDK under this umbrella, hoping the world will standardised on JavaScript and React Native for iOS, Android and web. So what happen if you're developing a mobile app using Unity, Xamarin and Flutter? No luck as they only have SDK for iOS, Android and web. Compare this with Firebase that has SDK for iOS, Android, web, Xamarin, Unity, Flutter and C++. AWS has an opportunity in AppSync to make a product as easy to get started as Firebase. What is required is native mobile SDK for iOS, Android, web, Flutter, Unity, Xamarin that is not just specific to AppSync and GraphQL, but also add in authentication, analytics etc APIs. Something like Firebase SDK API. AWS is still stronger for enterprise usage. And you can’t use Firebase in China due to its use of Google Play services. But Firebase is definitely a weapon used by Google to draw customers into other Google Clouds offering.
Although the author mentions they haven't had experience with AppEngine, it's the reason why I love Google Cloud SO much over anything else. If you're a startup running something on Elixir (or even Rails), AppEngine's experience is hard to beat. Not many people do know: * You can run multiple microservices on AppEngine under one application. * Each of these can have many versions serving different percentages of traf…
I’ve been using AppEngine for years and really like it. Had an interesting billing issue recently. I enabled a task queue to run a longer running task in the background but I didn’t realize there’s a default to retry failed tasks indefinitely. This started slowly increasing my front end instance hours (and my bill). A few hundred bucks later I figured it out and specified a retry attempts limit.
I had a similar issue and contacted them for a refund. It worked out fine and they refunded the full amount. It might be worth giving it a shot!
One thing I didn't see mentioned in this article is Firebase. It feels like a hidden gem lurking within the overall GCP offering, and may be overlooked by devs who're not doing mobile-specific work. For me, Firebase was the gateway drug that got me into GCP. I successfully built and hosted the backends for a couple of iOS apps using Firebase. The best parts were cloud functions and built-in sync (including offline/oc…
> One thing I didn't see mentioned in this article is Firebase. Can confirm, I'm also building my startup off of Firebase. Super easy to get up and running with. I was talking to a friend at Amazon about how I create serverless HTTP entpoints and he was impressed that getting started with it was a 10 minute affair from "never done backend programming" to "REST endpoint setup." Another half an hour got me full end to…
I run a service that fixes this problem. https://serveo.net/ It uses SSH port forwarding to proxy public HTTPS traffic to your local server.