Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Cloud Platform – The Good, Bad, and Ugly

deps.co

Post reply on HN
Print view View original

171–180 of 202 posts

Re: Google Cloud Platform – The Good, Bad, and Ugly

#171

Post by wichert »

scarface74 wrote: post #35
dantiberian wrote: post #31

Earlier quoted context omitted.

Terraform is great because it lets you treat infrastructure as code, but I don't think it makes any promises about cloud agnosticism. In fact it's the opposite, each provider is specific to the service that they are offering. Rather than Terraform offering a lowest common denominator set of resource definitions, each provider can be designed to work in a way that most naturally maps to their offerings and API. In the…

In that case, if you're on AWS, then why not just use CloudFormation? CloudFormation is a lot more powerful on AWS than TF.

While CloudFormation is lovely, it has a couple of real downsides:

- very often something new is introduced on AWS without any CloudFormation support, so you will either need to write custom resources with lambda functions, or be prepared to wait a long time. From the few times I checked TF is actually faster to support new services / features.

- CloudFormation has extensive documentation, but very often you end up having to also read AWS API documentation and going through a dozen trial & error attempts before you get something working.

- occasionally CloudFormation can get stuck and leave you in a state you can not recover from. Luckily AWS support tends to be very responsive and can help you here, and it hasn't been happening as much as 1-2 years ago

- CloudFormation has very little support for reusing things: no macro support, very limited include support, no support for YAML aliases (unless you use "aws cloudformation package" as a workaround)

- CloudFormation changesets are nice, but do not work if you use sub-stacks (which you should use)

Just like Zope there is a bit of a Z-shaped learning curve: there is a pretty steep learning curve to start, after which a lot of things become easy. But when you get to more complex things suddenly everything becomes frustratingly difficult again. That may come with the territory; I have not used other tools such as TF so I can't tell if that is a problem-space specific thing.

Re: Google Cloud Platform – The Good, Bad, and Ugly

#172

Post by briffle »

sethvargo wrote: post #28
scarface74 wrote: post #26

I keep hearing how great Terraform is because it allows you to treat infrastructure as code in a cloud agnostic manner. But every time I see a Terraform script, it's tied tightly to AWS's infrastructure -- including Hashicorp's own examples.

Hey there - Seth from Google here. We have a dedicated team of Google engineers who contribute to Terraform as their full time job. We are constantly looking for ways to improve. We added a lot of examples to our Google provider documentation, and we are working on a project that will enable us to add support for new GCP features in Terraform faster. I can’t speak for HashiCorp’s own examples (I mean, I could, I used…

We use terraform to create our new projects, but with them not supporting kubernetes deployments it would be very difficult for us to continue to use them after standup. (I then script kubectl commands to create our deployments, etc.)

Their own github repo issue list said they wouldn't support deployments when it was in beta (hashicorp won't do anything that is in beta, another problem with google cloud and its long, stable betas).. Kuberenetes deployments have been out of Beta for at least 6 months, and no movement on the kubernetes provider

Re: Google Cloud Platform – The Good, Bad, and Ugly

#173

Post by talonx »

sethvargo wrote: post #27

Hey there! Seth from Google here. Thank you for writing up this article and providing this valuable feedback - we really appreciate it. I’m personally taking this feedback and making sure it’s shared with the relevant teams (both positive and negative). On the DevRel team at Google, we often write friction logs (my colleague just authored a post about friction logs in detail: https://devrel.net/developer-experience/a…

From personal experience, the documentation for GCP and especially the client libraries is one of its weakest points. This does not seem to be getting fixed soon, so it might need more than just accepting feedback to fix it.

For example, see this 3 year old thread on the same topic that is still pertinent - https://news.ycombinator.com/item?id=9497576

Re: Google Cloud Platform – The Good, Bad, and Ugly

#174

Post by geggam »

KajMagnus wrote: post #164
scarface74 wrote: post #97

Earlier quoted context omitted.

It's yet another semi-json format that doesn't have widespread support by any other parsers. Even Hashicorp recommends JSON if you want something that is machine readable.

I think it looks lovely :- ) having used Puppet a bit in the past. Look how simple: `inline = ["sudo apt-get -y update", ... install nginx ...` Terraform seems to be. .... hmm, apparently one can use things like Chef & Puppet etc together with Terraform, I eventually noticed.

the nice way to do this is to pass the chef role to the user data template in the autoscale group

vars { ROLE = "bastion"

Then append this to the user_data.tpl file

chef-client --audit-mode enabled -R -E ${chef_environment} -r role[${ROLE}]

Allows you to use the same user_data.tpl file for multiple autoscale groups

Re: Google Cloud Platform – The Good, Bad, and Ugly

#175

Post by bus_error »

wikibob wrote: post #70
pow_pp_-1_v wrote: post #63

Reading the comments here a persistent theme seems to be that the documentation is lacking. Something that might help is creating a "dog-fooding" team mostly filled with interns. This team will be responsible for creating samples with the public APIs. Why Interns? Because they will move on to better things around the time when their brains learn the patterns required to navigate the Google cloud API efficiently.

Yes! The documentation problem is NOT complex to solve. I would love to use GCP on more projects but the docs are embarrassing. Are they trying to get engineers to write the docs rather than hiring professional technical writers? Truly baffling.

[I'm a technical writer at Google working on Cloud documentation]

Thank you for the constructive comments regarding GCP and in particular documentation; we are working on addressing the points raised.

GCP has a dedicated tech writing team which is growing (we're hiring!) and the documentation is written by tech writers. We work with our colleagues in developer relations (developer advocates, developer programs engineers), UX and the software engineers who created the product.

All that said, we know our documentation is not perfect and are constantly working to improve. To that end if you see something that is broken/incorrect, please file a bug (the "SEND FEEDBACK" link in the top right of the documentation page is a bug submission form). We love to hear from users and I can assure you docs bugs do not get routed to /dev/null (we have a bug SLO, just like our SWE colleagues).

As a more general tech writing comment, documenting large, fast growing distributed systems such as public clouds is tricky. There's a lot more to documentation than just writing up instructions, such as thoughtful information architecture. It's a challenge that we, and I'm sure our counterparts at AWS et al., are grappling with.

As tech writers, we wince when we see errors in our work and feel pain when users are not able to enjoy the product/service as intended due to issues in documentation. The whole developer relations team (DAs, DPEs and tech writers) proactively try and catch these mistakes but of course, we miss some. It is nice to see users feel so passionately about documentation, so please let us know where we have made mistakes and we will fix them and try harder next time.

Re: Google Cloud Platform – The Good, Bad, and Ugly

#176

Post by griffordson »

Drdrdrq wrote: post #96
gingerlime wrote: post #75

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 have a single dependency on Google for my business and I would never take on another one voluntarily. All the horror stories you've heard about Google support have been true for the 10+ years I've been dealing with the Google Maps team. Every year they find some new way to screw up their customer support.

And that's before you even get to your legitimate concern about Google's long-term commitment to any of their offerings.

Re: Google Cloud Platform – The Good, Bad, and Ugly

#177

Post by hitekker »

Drdrdrq wrote: post #96
gingerlime wrote: post #75

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 recall Google Cloud engineers trying to assuage concerns over their longevity “we’d give you s years notice before we’d shut down”.

Other commenters asked if they still had jobs after saying that.

Re: Google Cloud Platform – The Good, Bad, and Ugly

#178

Post by atombender »

magsafe wrote: post #38

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…

If you like Firebase, I'd like to give a shout-out to Sanity [1]. (Disclosure: I work part-time on the backend, but I'm not an employee and I don't work on the product itself; but call this a shameless plug if you will!)

Sanity is a headless CMS, but the API itself is like a souped-up Firebase and can be used on its own without adopting the Sanity UI. It's got many of the same features -- web API, change watching via WebSockets -- but adds support for joins, fine-grained patches (CRDT-like but not actually), transaction history APIs, fine-grained document-level permissions, and many other neat things. We are particularly proud of the query language, GROQ [2], which is a very powerful superset of JSON that allows you to express transformation pipelines over structured data.

Sanity is hosted on Google Cloud, too, so performance when used inside GCP should be great.

[1] https://sanity.io

[2] https://www.sanity.io/docs/data-store/how-queries-work

Re: Google Cloud Platform – The Good, Bad, and Ugly

#179

Post by [deleted] »

nunez wrote: post #148
halbritt wrote: post #98

Earlier quoted context omitted.

I've used Azure a bit and it's been pretty painful for the most part. There are three, maybe four identity management systems (Azure native, MS Live, Hosted AD, others?). Working with the SDKs and doing programmatic authentication was painful. I did a fair bit with AKS. It had a lot of shortcomings that would take a while to go into. They ended up suggesting I use ACS-engine. There are some products that are neat, th…

Could you go into it? I’ve kept hearing good things about AKS, but my experience with their VM service left me skeptical of those claims.

[deleted]

Re: Google Cloud Platform – The Good, Bad, and Ugly

#180

Post by halbritt »

nunez wrote: post #148
halbritt wrote: post #98

Earlier quoted context omitted.

I've used Azure a bit and it's been pretty painful for the most part. There are three, maybe four identity management systems (Azure native, MS Live, Hosted AD, others?). Working with the SDKs and doing programmatic authentication was painful. I did a fair bit with AKS. It had a lot of shortcomings that would take a while to go into. They ended up suggesting I use ACS-engine. There are some products that are neat, th…

Could you go into it? I’ve kept hearing good things about AKS, but my experience with their VM service left me skeptical of those claims.

Here's a list of things from January of this year:

  - when scaling nodes, didn't get the desired count
  - creating and deleting clusters takes a while (30 minutes)
  - cluster operations get stuck in a loop
  - disappearing node did not bring up a new node
  - external management setup was difficult (GKE assigns publicly reachable IP by default)
  - changing SSH user or key through azcli or GUI didn't work
  - default storage class wasn't set
  - admission control disallows deploying a registry in kube-system
  - nodes randomly go into notready state
  - no ability to add new node pools or modify pool without destroying cluster
This was all prior to GA.
Post reply on HN