5 ms·

I think one of the big issues that Google is facing with GCP is exactly the perception they have in the market with respect to product shutdowns. I could never

I think one of the big issues that Google is facing with GCP is exactly the perception they have in the market with respect to product shutdowns. I could never see myself making the decision to go with Google over Amazon or Azure, simply because I don't feel confident that the product won't be shutdown with minimal warning at any given time.

arbie 8y ago
Have you considered a cloud abstraction that let's you change providers with less effort?
- whorleater 8y ago
  Have you been using the same cloud abstraction tools I have? Terraform and Kubernetes all require more effort in dealing with cloud providers, not less.
  - gaius 8y ago
    Yes the myth of Terraform is that it abstracts sufficiently to be cross platform. You can use it on multiple platforms but that’s all.
- spookthesunset 8y ago
  This is like those database abstractions that get made under the premise that someday at some point you'll switch DB's. But yet, 10 years later you are still chugging along on the same database you started with. You would have been far better off to just completely "move in" with the DB you decided to use in the first place and leverage all it has to offer. The problem with these kinds of abstractions is in order to avoid "vendor lock in" they are forced into a "lowest common denominator" deal where you don't get to leverage any vendor-specific awesomeness. For example, in DB land you would avoid certain kinds of database fields (Postgres's structured datatypes like JSON, for example). Instead of leveraging the DB to do certain kinds of JSON queries you now have to write the infrastructure your self "just in case we switch DB's". The irony is, in my experience to avoid the dreaded vendor lock in "problem", teams and organizations wind up locking themselves into their own homebrew nightmare that does nothing but recreate (often poorly) what they could have gotten by allowing themselves to get locked in to a third party. It goes without saying that in almost all cases, this homebrew nightmare has zero to do with the actual value generating functions of the business. Storing and querying on structured JSON in a database has nothing to do with the core values of 99.999% of all organizations--these things should be locked into third parties. My point is, most teams should embrace all their cloud providers can offer. Settling for the lowest common denominator shared between cloud providers leaves money on the table and runs a very high risk of what is, in my experience, a worse form of vendor lock in--getting locked into your own stinking pile of rubble. I could go on and on about the "vendor lock in" boogyman--it is one of the biggest, most annoying anti-patterns I see. It creates huge political and technical hurdles as the business grows. I believe it stems from a poor understanding of actual business risks, not understanding the true lifetime costs of inhouse engineering projects, resume-driven design, and a very healthy dose of premature optimization. (also toss in some Stallmanesque mistrust of proprietary systems for good measure)
  - tracker1 8y ago
    +1 to the above... There's HUGE costs in trying to create abstraction... Generally layers of crap code that is all repetitive and adds no value, making it so much more costly to maintain even. You're often better off writing a second version and transition scripts than trying to maintain an abstracted code base or application platform. Though a lot of the docker tooling, k8s and other options do make it quite a bit easier as an option of you want to self-host. But that has other issues, advantages and disadvantages.
  - mnutt 8y ago
    I will say that the majority of Rails apps can just use the Rails abstractions and they sit reasonably well on top of whatever database you choose to use. Rails 5 maps just fine to most common database types and patterns. On the other hand, in the past I’ve used Fog to abstract our cloud provider and that was nothing but pain. SQL is well-specced with some vendor-specific extensions, while there really isn’t any actual common denominator for cloud services.
- ryrobes 8y ago
  ORMs all the way down? Please no.
wavegeek 8y ago
It is strange that smart people like this are shooting themselves in the foot in this way. Yes you can save money by killing a product, but I would argue the second order effects are more important. People lose the faith to bet on your products. Having had to scramble - twice - when google cut products under me, I would never make a big bet based on an assumption that they will keep faith after I commit to their products. Maybe they should read H Edwards Deming e.g. "maintain consistency of purpose".

arbie 8y ago

Have you considered a cloud abstraction that let's you change providers with less effort?

whorleater 8y ago
Have you been using the same cloud abstraction tools I have? Terraform and Kubernetes all require more effort in dealing with cloud providers, not less.
- gaius 8y ago
  Yes the myth of Terraform is that it abstracts sufficiently to be cross platform. You can use it on multiple platforms but that’s all.
spookthesunset 8y ago
This is like those database abstractions that get made under the premise that someday at some point you'll switch DB's. But yet, 10 years later you are still chugging along on the same database you started with. You would have been far better off to just completely "move in" with the DB you decided to use in the first place and leverage all it has to offer. The problem with these kinds of abstractions is in order to avoid "vendor lock in" they are forced into a "lowest common denominator" deal where you don't get to leverage any vendor-specific awesomeness. For example, in DB land you would avoid certain kinds of database fields (Postgres's structured datatypes like JSON, for example). Instead of leveraging the DB to do certain kinds of JSON queries you now have to write the infrastructure your self "just in case we switch DB's". The irony is, in my experience to avoid the dreaded vendor lock in "problem", teams and organizations wind up locking themselves into their own homebrew nightmare that does nothing but recreate (often poorly) what they could have gotten by allowing themselves to get locked in to a third party. It goes without saying that in almost all cases, this homebrew nightmare has zero to do with the actual value generating functions of the business. Storing and querying on structured JSON in a database has nothing to do with the core values of 99.999% of all organizations--these things should be locked into third parties. My point is, most teams should embrace all their cloud providers can offer. Settling for the lowest common denominator shared between cloud providers leaves money on the table and runs a very high risk of what is, in my experience, a worse form of vendor lock in--getting locked into your own stinking pile of rubble. I could go on and on about the "vendor lock in" boogyman--it is one of the biggest, most annoying anti-patterns I see. It creates huge political and technical hurdles as the business grows. I believe it stems from a poor understanding of actual business risks, not understanding the true lifetime costs of inhouse engineering projects, resume-driven design, and a very healthy dose of premature optimization. (also toss in some Stallmanesque mistrust of proprietary systems for good measure)
- tracker1 8y ago
  +1 to the above... There's HUGE costs in trying to create abstraction... Generally layers of crap code that is all repetitive and adds no value, making it so much more costly to maintain even. You're often better off writing a second version and transition scripts than trying to maintain an abstracted code base or application platform. Though a lot of the docker tooling, k8s and other options do make it quite a bit easier as an option of you want to self-host. But that has other issues, advantages and disadvantages.
- mnutt 8y ago
  I will say that the majority of Rails apps can just use the Rails abstractions and they sit reasonably well on top of whatever database you choose to use. Rails 5 maps just fine to most common database types and patterns. On the other hand, in the past I’ve used Fog to abstract our cloud provider and that was nothing but pain. SQL is well-specced with some vendor-specific extensions, while there really isn’t any actual common denominator for cloud services.
ryrobes 8y ago
ORMs all the way down? Please no.

wavegeek 8y ago

It is strange that smart people like this are shooting themselves in the foot in this way. Yes you can save money by killing a product, but I would argue the second order effects are more important. People lose the faith to bet on your products. Having had to scramble - twice - when google cut products under me, I would never make a big bet based on an assumption that they will keep faith after I commit to their products. Maybe they should read H Edwards Deming e.g. "maintain consistency of purpose".