GCP wins hands down when you need to ssh into your server via mobile on the go. It has a mobile app. I'm not aware of an AWS mobile app!
Google Cloud Platform – The Good, Bad, and Ugly
131–140 of 202 posts
Re: Google Cloud Platform – The Good, Bad, and Ugly
#132The article mentions Terraform workspaces and their limitations (Not Google Cloud related at all). The way we get around this is to have separate variable files for each environment. The master file contains sensible defaults and then those get overridden by the environment specific files. This is the only sane way to manage variables in terraform right now IMO. It does require that you specify a file when you run it…
Why should one not run Terraform locally?
Not the parent, but I share the same opinion.
You totally can run locally, provided you are a single developer in your project. Once you start collaborating, you need this to be in a CI server or similar. Make it in such a way that the code is guaranteed to be properly versioned, taking the latest from your 'production' branch, as you can run into a situation where you are running terraform based on local changes which are not in version control, by accident or on purpose. Which now means that the state no longer conforms to the latest TF scripts, and this will come back to bite you. This also forces you to provide any settings as part of your CI job, not a one-off command in the CLI. It also give you auditing, and many other benefits.
But the most important piece of advice I can give is: no matter what your particular circumstances are, what your project size is, your Terraform skill, or whatever other variable, always use a Terraform remote state, with whatever backend you are most comfortable with. No exceptions. Even if you are running locally, I don't care. Unless you are doing testing while developing the scripts (and I'd argue even then), there is no reason to use a local state, ever.
Re: Google Cloud Platform – The Good, Bad, and Ugly
#133One thing I would love to see is root domain CNAME support (or ALIAS, or ANAME, or whatever) so I can host a static website on a root domain. It seems like there's a workaround using CloudFlare, but it would be really nice if GCP itself supported this.
Re: Google Cloud Platform – The Good, Bad, and Ugly
#134One 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…
Firebase is great, but covered under a separate agreement with Google, and its terms aren't as friendly to corporate users. For example, they still aren't encrypting tenant data at REST. Nothing is COPPA compliant.
I'm pretty sure that's wrong.
Also: https://cloud.google.com/firestore/docs/server-side-encrypti...
"Each Cloud Firestore object's data and metadata is encrypted under the 256-bit Advanced Encryption Standard, and each encryption key is itself encrypted with a regularly rotated set of master keys."
So... yup.
Re: Google Cloud Platform – The Good, Bad, and Ugly
#135I see lots of evaluation of GCP, or comparison between GCP vs AWS recently. But I don't see as many for the Azure platform, although Azure being the 2nd in the cloud provider market, and even closing on AWS in market share. Anybody has any insights on this?
You don’t shop Azure.
Microsoft is repeating what they did with NT — owning identity. They reel you in with Office 365 and when you need controls convert you to Azure AD. Once that happens, Azure is a no-brainer.
Also, every company with an EA has a contract vehicle for Azure... just add water!
Re: Google Cloud Platform – The Good, Bad, and Ugly
#136Earlier quoted context omitted.
Was reading that page. What it specifically says is: > The size of the blob or None if the blob’s resource has not been loaded from the server. That's pretty vague imho, because there is no high level overview or tutorial to tell you that you need to explicitly cause the load from the server. Point in fact, the function you need to use is "reload()", and the documentation of this func is "Reload properties from Cloud…
To conclude that: > Google couldn't care less if their customers can figure out how to use their products. That feels like a pretty strong leap to make from your complaint about using the term "reload" when "load" is better. I can understand you are providing an example, and perhaps you feel the documentation has many such examples. From personal experience reading extensive documentation, I think you are being sligh…
> I can understand you are providing an example, and perhaps you feel the documentation has many such examples. From personal experience reading extensive documentation, I think you are being slightly unfair in this instance.
I kind of agree with the other poster. Getting up and running with .NET on flexible instances has been challenging to say the least. The datastore documentation does not give a good overview or introduction to how interact with this system.
Re: Google Cloud Platform – The Good, Bad, and Ugly
#137One thing I would love to see is root domain CNAME support (or ALIAS, or ANAME, or whatever) so I can host a static website on a root domain. It seems like there's a workaround using CloudFlare, but it would be really nice if GCP itself supported this.
I'm not sure I understand what you mean, but does this help: https://cloud.google.com/storage/docs/hosting-static-website
Re: Google Cloud Platform – The Good, Bad, and Ugly
#138I've been running a production project in Google App Engine for three years with six figure active users and can mostly agree with this. A few comments: 1. Stackdriver gets a bad rap. Maybe there are better solutions out there, but it hasn't been our weakest link. It's gotten very expensive, though. 2. Google recently deployed a new HTTP load balancer that is way better than the old one. 3. Instance usage on app engi…
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.
GCP is 2 years behind in versions and the funky setup around connections is a hassle to deal with. The number of connections is limited and not configurable, and the default way to connecting is to use the Cloud SQL Proxy which is a separate binary/service you have to run to connect.
Public IP access is available but that means going through the public internet, and also means you have to whitelist each individual IP accessing it, which is hard or impossible when trying to use ephemeral or private-ip-only instances.
Re: Google Cloud Platform – The Good, Bad, and Ugly
#139This is a good perspective from a smaller user. As said before, the core platform is technically fantastic with the fastest and easiest compute, storage, and networking around. Some downsides mentioned already have options in alpha/beta (like more updated UIs, products like memorystore, filestore).
Re: Google Cloud Platform – The Good, Bad, and Ugly
#140Earlier quoted context omitted.
I apologize for bringing up something that is offtopic here but I am really glad to have read your comment. Last I read in the docs, Memorystore was not accessible through the AppEngine Standard Environment, which was rather disappointing to me. I was wondering if just providing the App Engine Standard Environment with the Redis instances address and credentials, along with a service account or IP whitelist for acces…
Unfortunately that is not possible at this moment. Without going into details: Flex is running on the same cloud infrastructure as Memorystore that it why it is possible to establish networking between them. This is not true for the regular AppEngine.
Thanks so much for the reply, it saved me a few hours of trying it out at the very least! Of course, I hope there is support for Memorystore on App Engine eventually. Thank you.