33 ms·

Well, it might be a bit more difficult to get started. The cool thing is that you only have to install the google-api-python once, and you can communicate with

by TeeWEE 11y ago

Well, it might be a bit more difficult to get started. The cool thing is that you only have to install the google-api-python once, and you can communicate with lots of services, by creating the service object. CloudPubSub, BigQuery etc etc. Also, google comes with very good monitoring tools (they bought stackdriver and integrated it). We are running a big appengine app, with quite some compute engine instances. Together with cloud-storage and biguery its a full blown solution, without having to setup every instance yourselve. I think AWS cant compete with that, you almost need a system-engineer when you work with AWS. All in all: you are used to AWS. Making it cumbersome to get started with Google Cloud. I do agree tough that the documention is lacking often.

piva00 11y ago
There's also the point about vendor lock-in, in AWS you do need a systems engineer to setup and automate infrastructure, but pretty much everything (aside from a few products like Redshift, Dynamo and EMR is what I recall from my mind) you can port out of AWS pretty easily if and when the time comes to have your own data center and cut some costs. Google Cloud is a much bigger vendor lock-in, you could not setup the same environment outside of it.
- vgt 11y ago
  I'm genuinely curious why you hold that opinion, especially in context of a thread that discusses a service that's available through the standard hbase api
  - rodionos 11y ago
    Without support for co-processors in BigTable I would hardly call it 'standard' API. Also the implementation of buffered mutation, a key attraction in HBase 1+ for fast non-blocking writes, is different enough in bigtable that you might have to change application code to work it consistently. It's nice though that bigtable API have references to HBase bugs :) > HBase 1.0.0 has a bug in it. It returns maxSize instead of the buffer size for > getWriteBufferSize. https://issues.apache.org/jira/browse/HBASE-13113 https://issues.apache.org/jira/browse/HBASE-13113
- megaman821 11y ago
  I think of the three AWS services you named, only Dynamo can't easily be ported out. Redshift use Postgres drivers. EMR uses the HBase API.
  - eropple 11y ago
    Redshift uses Postgres drivers, but does not use Postgres semantics. Important to consider if you're using any nontrivial amount of data, because porting it even to other cstore databases will require a lot of thinking and probably some munging-at-scale.
- 23david 11y ago
  Ever try porting a customer using cloudformation templates and autoscaling groups over to another cloud service? Or reimplementing s3 or EBS semantics? It can be done, but definitely non-trivial... lockin++
mataug 11y ago
I don't think anyone cares about having to install one or any number of client libraries for services being used. Whats more important the ease, simplicity and clarity when using a service. The reason I like boto is because its easy to find out what is possible and what is not.

by TeeWEE 11y ago

piva00 11y ago

There's also the point about vendor lock-in, in AWS you do need a systems engineer to setup and automate infrastructure, but pretty much everything (aside from a few products like Redshift, Dynamo and EMR is what I recall from my mind) you can port out of AWS pretty easily if and when the time comes to have your own data center and cut some costs. Google Cloud is a much bigger vendor lock-in, you could not setup the same environment outside of it.

vgt 11y ago
I'm genuinely curious why you hold that opinion, especially in context of a thread that discusses a service that's available through the standard hbase api
- rodionos 11y ago
  Without support for co-processors in BigTable I would hardly call it 'standard' API. Also the implementation of buffered mutation, a key attraction in HBase 1+ for fast non-blocking writes, is different enough in bigtable that you might have to change application code to work it consistently. It's nice though that bigtable API have references to HBase bugs :) > HBase 1.0.0 has a bug in it. It returns maxSize instead of the buffer size for > getWriteBufferSize. https://issues.apache.org/jira/browse/HBASE-13113 https://issues.apache.org/jira/browse/HBASE-13113
megaman821 11y ago
I think of the three AWS services you named, only Dynamo can't easily be ported out. Redshift use Postgres drivers. EMR uses the HBase API.
- eropple 11y ago
  Redshift uses Postgres drivers, but does not use Postgres semantics. Important to consider if you're using any nontrivial amount of data, because porting it even to other cstore databases will require a lot of thinking and probably some munging-at-scale.
23david 11y ago
Ever try porting a customer using cloudformation templates and autoscaling groups over to another cloud service? Or reimplementing s3 or EBS semantics? It can be done, but definitely non-trivial... lockin++

mataug 11y ago

I don't think anyone cares about having to install one or any number of client libraries for services being used. Whats more important the ease, simplicity and clarity when using a service. The reason I like boto is because its easy to find out what is possible and what is not.