5 ms·

> if anything I had a bit of geek pride in my voice :-) Cool. It is impressive to beat AWS at a game that everyone assumes they are the best at. > Things you'

by stephen 11y ago

> if anything I had a bit of geek pride in my voice :-) Cool. It is impressive to beat AWS at a game that everyone assumes they are the best at. > Things you'd want to know? This is kind of weird...but no, not really...for my team, I think we're zealously happy with AWS and it's their game to loose. And "only" 40% cheaper/x% faster isn't enough, given the switching costs of moving everything over. As long as AWS remains good enough. So, basically my "it doesn't really matter that you're cheaper" attitude is what made the connection to "a great business/adoption rate doesn't come solely from technical excellence". Which, as a programmer/technologist, is frustrating. If I knew what it did come from, I'd be off doing that, instead of kibitzing on HN. :-)

milesward 11y ago
First off, I'm super happy that you're having a great experience in the cloud: given where we are in the overall adoption cycle for public cloud tech any win for cloud is a win for all of us. >"given the switching costs" Perhaps that's the crux of the question right there; what if it was trivially easy? What if you couldn't tell beyond a different (lower) bill? Wouldn't it be awesome to run on several providers, load balance between them, and up your availability game to be redundant across providers? This is an area of real focus for my team, let me know if it's something of interest!
- stephen 11y ago
  > what if it was trivially easy? Yes, in theory that would be awesome...I think in practice, the limitations would be: - Cross-provider latency for micro-services that are interdependent (e.g. right now we assume everything is in the same AWS region) - API compatibility/codebase coupling, as our code is littered with "new AmazonXxxClient" - Feature parity would have to be near-100%...e.g. we use the regular things like EC2, S3, Dynamo, RDS, but also IAM and Kinesis (...and, and...). Not to say "oh you just need IAM & Kinesis", but that for any feature, current or future, that doesn't have a direct comparison across all providers, makes cross-provider harder to do. - Increased devops complexity; different ways to get into machines, different places to look for logs, different places to look for metrics (CW), different logins, different admin UIs... If you're team is focusing on this, these are likely things you've thought of... I would not be surprised if "cross-provider" becomes like "cross-platform", technically possible but rarely done. E.g. in the 90s cross-platform Microsoft/Apple/Linux (or today cross-iOS/Android/web) applications existed, if the programmers were very diligent, smart, and worked behind API abstractions that hid any platform-specific, platform-differentiating features. ...but in reality, 95% of programmers didn't, and were coupled to one platform or the other. And that was basically fine/just the way things were.
- stephen 11y ago
  GCP would probably have been better off if the "AWS marketplace" had worked out... E.g. instead of "GCP runs machines + offers PaaS databases/caches/etc." and "AWS runs machines + offers PaaS databases/caches/etc.", then now both the "run machines" + "PaaS offerings" must be identical, it'd be much easier if cloud providers got out of the PaaS business. That way both GCP and AWS just "run machines", and instead there is some sort of vendor / marketplace API where database vendor X can run in both AWS and GCP, and caching vendor Y can run in both AWS and GCP. And so you use the db APIs and the cache APIs, with some sort of service discovery within each cloud, and ideally the management UIs for the db and cache are both hooked in the GCP/AWS consoles. So, it's not "use Dynamo in AWS" vs. "use Bigtable in GCP" and they're kinda/sorta the same, it'd be "use (say) Voldemort in both" and they really are the same, and managed by the same vendor. (And not "you start vendor X's AMIs/images in your account and then play sysadmin", but "you use vendor Xs already-running/multi-tenant APIs from your app".) That said, it's not in AWS's interest to let others provide the PaaS part of the machine in a generic way. And, realistically, I don't think other (non-cloud) vendors could have successfully provided the PaaS offerings that AWS has, at the same multi-tenant scale. E.g. pre-AWS, all of the vendors (like a DB startup) were focused on "scale single-tenant solutions", and not "scale multi-tenant solutions", which is likely an order of magnitude or more harder. So it made sense for AWS to do it instead (plus the obvious benefit to them of more AWS lock in).

by stephen 11y ago

milesward 11y ago

First off, I'm super happy that you're having a great experience in the cloud: given where we are in the overall adoption cycle for public cloud tech any win for cloud is a win for all of us. >"given the switching costs" Perhaps that's the crux of the question right there; what if it was trivially easy? What if you couldn't tell beyond a different (lower) bill? Wouldn't it be awesome to run on several providers, load balance between them, and up your availability game to be redundant across providers? This is an area of real focus for my team, let me know if it's something of interest!

stephen 11y ago
> what if it was trivially easy? Yes, in theory that would be awesome...I think in practice, the limitations would be: - Cross-provider latency for micro-services that are interdependent (e.g. right now we assume everything is in the same AWS region) - API compatibility/codebase coupling, as our code is littered with "new AmazonXxxClient" - Feature parity would have to be near-100%...e.g. we use the regular things like EC2, S3, Dynamo, RDS, but also IAM and Kinesis (...and, and...). Not to say "oh you just need IAM & Kinesis", but that for any feature, current or future, that doesn't have a direct comparison across all providers, makes cross-provider harder to do. - Increased devops complexity; different ways to get into machines, different places to look for logs, different places to look for metrics (CW), different logins, different admin UIs... If you're team is focusing on this, these are likely things you've thought of... I would not be surprised if "cross-provider" becomes like "cross-platform", technically possible but rarely done. E.g. in the 90s cross-platform Microsoft/Apple/Linux (or today cross-iOS/Android/web) applications existed, if the programmers were very diligent, smart, and worked behind API abstractions that hid any platform-specific, platform-differentiating features. ...but in reality, 95% of programmers didn't, and were coupled to one platform or the other. And that was basically fine/just the way things were.
stephen 11y ago
GCP would probably have been better off if the "AWS marketplace" had worked out... E.g. instead of "GCP runs machines + offers PaaS databases/caches/etc." and "AWS runs machines + offers PaaS databases/caches/etc.", then now both the "run machines" + "PaaS offerings" must be identical, it'd be much easier if cloud providers got out of the PaaS business. That way both GCP and AWS just "run machines", and instead there is some sort of vendor / marketplace API where database vendor X can run in both AWS and GCP, and caching vendor Y can run in both AWS and GCP. And so you use the db APIs and the cache APIs, with some sort of service discovery within each cloud, and ideally the management UIs for the db and cache are both hooked in the GCP/AWS consoles. So, it's not "use Dynamo in AWS" vs. "use Bigtable in GCP" and they're kinda/sorta the same, it'd be "use (say) Voldemort in both" and they really are the same, and managed by the same vendor. (And not "you start vendor X's AMIs/images in your account and then play sysadmin", but "you use vendor Xs already-running/multi-tenant APIs from your app".) That said, it's not in AWS's interest to let others provide the PaaS part of the machine in a generic way. And, realistically, I don't think other (non-cloud) vendors could have successfully provided the PaaS offerings that AWS has, at the same multi-tenant scale. E.g. pre-AWS, all of the vendors (like a DB startup) were focused on "scale single-tenant solutions", and not "scale multi-tenant solutions", which is likely an order of magnitude or more harder. So it made sense for AWS to do it instead (plus the obvious benefit to them of more AWS lock in).