5 ms·

IMHO, you're gonna struggle if you move anywhere else from AWS. We're migrating to GCP and there are gaps all over the place.

borg16 2y ago
is it because there are features that AWS provides to you that are not available in GCP, or just the fact that setting up exact replicas of processes is hard for migrations like these?
esprehn 2y ago
Out of curiosity, what are the biggest gaps you've hit in GCP?
notpushkin 2y ago
This is the reason I try to avoid proprietary bullshit services. Use EC2, Postgres, and S3, and you’ll be fine in any cloud or even on bare metal.
- darknavi 2y ago
  > proprietary bullshit services > S3 Hasn't this recently been an issue where Amazon arbitrarily changes the S3 contract and all software following it as a spec has to play catch-up?
  - notpushkin 2y ago
    I think this happened a few times, but given there are many S3 clients, they can’t keep doing thiat or there will be a backlash. Although perhaps it’s about time we made a proper standard based on S3, yeah.
  - immibis 2y ago
    It has, but that's not exactly on S3 is it? The S3 system is proprietary to Amazon, and it's your fault if you're not using Amazon but you're relying on Amazon to not change it anyway, because they have no obligation to you. The concept of object storage is not proprietary. You should be able to change your code to use a different object storage provider.
    - darknavi 2y ago
      I didn't mean to throw any shade at S3. It certainly isn't their fault that people use their private protocol on other projects. I was trying to point out that S3's protocol is "proprietary" so if you're using it you're still (somewhat) using "proprietary bullshit" in your stack!
      - notpushkin 2y ago
        I mean yeah, it isn’t really open – but it’s the informal “standard” that everyone is using nowadays. You can’t really expect every cloud provider and every app to just switch to WebDAV or something (though we can push for a gradual change here somehow!)
- lucb1e 2y ago
  That sounds to my self-hoster ears as an expensive way to do self hosting. Isn't at least half the point of AWS to use their SaaS thingies that all integrate with each other, I think people now call it "cloud native software"? Not that most of our customers whose AWS environment we audit do much of this, at least not beyond some basics like creating a vlan ("virtual private cloud"), three layers of proxies to "load balance" a traffic volume that my old laptop could handle without moving the load average above 0.2, and some super complex authentication/IAM rules for a handful of roles and service accounts iirc (The other half of the point is infinite scale, so that you can get infinite customers signing up and using the system at once (which hopefully pay before your infinite AWS bill is due), but you can still do that with VPSes and managed databases/storage.)
  - tsimionescu 2y ago
    The point of moving to AWS is often to benefit from their data centers and reliability promises. So VPC, EC2, IAM, maybe S3 have a clear point. And one small note: apart from S3, virtually all AWS services are tied to a VPC, any kind of deployment starts with "ok, in what VPC do you want this resource?".
    - immibis 2y ago
      You can get 95% of the reliability for 10% of the price at any dedicated hoster. AWS just figured out the magic word "cloud" means they can charge you 10 times the price. At Azure or GCP you pay a similar price but you don't even get the reliability so literally why would you use them? The only reason I see is that "cloud" means you can start instances at any time without a setup fee or contract duration. But with the amount of cost difference, you could have three times your baseline "cloud" load running all the time at a non-cloud hoster, and still save money!
  - notpushkin 2y ago
    It is an expensive way to do self hosting, yeah! I guess one reason is, sometimes it’s easier to just use one of big N clouds – e.g. if you’re in a regulated industry and your auditors will raise brows if they see a random VPS provider instead. (Or maybe not? If you’re doing that kind of audits I’d love to hear your thoughts!) > Isn't at least half the point of AWS to use their SaaS thingies It is. (That’s how they lock you in!) I think it’s okay to use some AWS stuff once in a while, but I’d be wary of building your whole app architecture around AWS. I’m in the self-hosters camp myself :-) I’m building a Docker dashboard to make it easier to build, ship, and monitor applications on any server: https://lunni.dev/ https://lunni.dev/
- mastazi 2y ago
  > [...] and S3, and you’ll be fine in any cloud Except Azure - AFAIK it's pretty much the only cloud provider that doesn't support S3 API, see e.g. https://learn.microsoft.com/en-us/answers/questions/1183760/s3-api-support-over-azure-blob-storage https://learn.microsoft.com/en-us/answers/questions/1183760/...
  - notpushkin 2y ago
    Looks like one more reason for the list!
- amluto 2y ago
  I’m personally thoroughly unimpressed by the bare metal S3 implementations I’ve tried. And there’s also an issue with client libraries and their compatibility with various implementations. I recently discovered this issue: https://github.com/boto/botocore/issues/3394 https://github.com/boto/botocore/issues/3394 This is GCS implementing the S3 API incorrectly in a way that really ought not to break clients, but it’s still odd because the particular bug on GCS’s end seems like it took active effort to get wrong. But it’s also boto (the main library used in Python to access S3 and compatible services) doing something silly, tripping over GCS’s bug, and failing. And it’s AWS, who owns boto, freely admitting that they don’t intend to fix it, because boto isn’t actually intended to work with services that are merely compatible with S3. As icing on the cake, to report this bug to Google, I apparently need to pay $29 plus a 3% surcharge on my GCS usage. Thanks. Time to check out OpenDAL, I suppose.
  - ajross 2y ago
    > As icing on the cake, to report this bug to Google, I apparently need to pay $29 plus a 3% surcharge on my GCS usage. Thanks. That's the price of a support contract, not a "bug report". And it's not "plus", it's "or": support costs $29/month or 3% of your monthly billing, whichever is greater. It comes with SLA agreements for fixing or working around your reported problems. Though obviously in this case they'll probably just tell you to use their own python library and not boto.
    - amluto 2y ago
      Oh, thanks Google, if my cloud spend is more than $967/mo, then I don’t get dinged by the $29 minimum. But this is the price of a bug report, because I can’t file a bug report without paying it. And this situation is bad business. Google advertises that GCS has S3 interoperability support. And they have customers who use it in its interoperable mode. Presumably those customers could use GCS’s biggest competitor, too. Shouldn’t Google try to make the S3 interop work correctly?
      - ajross 2y ago
        GCS and AWS are commercial products for which you pay, not open source projects you can expect to support you for free. I don't know what to say here, if you have something "serious" to do on these platforms then a 3% overhead for support seems like an obvious choice. Honestly it seems to me like you're excited to have found a bug and want to report it for glory; we've all been there. But No One Cares about that stuff in the world of commercial software. They fix bugs for real customers, not internet rock stars. If you aren't losing even $29 (one mid-tier meal!) from this bug, well... does it even rise to the level of "yell about it on HN?".
- perching_aix 2y ago
  It is also the reason to use proprietary bullshit services. If there was not utility gap, then a reasonable evaluation would return that a migration to them is not worthwhile. Now of course, that's a very sizable if...
  - notpushkin 2y ago
    I think the main reason isn’t the utility gap – more like “nobody got fired for buying IBM^W AWS” kind of thing.
wink 2y ago
That highly depends on what services your're using. We migrated from AWS to GCP in 2016/2017 (mostly VMs and related stuff, CloudFront, etc - no lambdas) and it was pretty painless and everything worked smoothly until the end of that company.

borg16 2y ago

is it because there are features that AWS provides to you that are not available in GCP, or just the fact that setting up exact replicas of processes is hard for migrations like these?

esprehn 2y ago

Out of curiosity, what are the biggest gaps you've hit in GCP?

notpushkin 2y ago

This is the reason I try to avoid proprietary bullshit services. Use EC2, Postgres, and S3, and you’ll be fine in any cloud or even on bare metal.

darknavi 2y ago
> proprietary bullshit services > S3 Hasn't this recently been an issue where Amazon arbitrarily changes the S3 contract and all software following it as a spec has to play catch-up?
- notpushkin 2y ago
  I think this happened a few times, but given there are many S3 clients, they can’t keep doing thiat or there will be a backlash. Although perhaps it’s about time we made a proper standard based on S3, yeah.
- immibis 2y ago
  It has, but that's not exactly on S3 is it? The S3 system is proprietary to Amazon, and it's your fault if you're not using Amazon but you're relying on Amazon to not change it anyway, because they have no obligation to you. The concept of object storage is not proprietary. You should be able to change your code to use a different object storage provider.
  - darknavi 2y ago
    I didn't mean to throw any shade at S3. It certainly isn't their fault that people use their private protocol on other projects. I was trying to point out that S3's protocol is "proprietary" so if you're using it you're still (somewhat) using "proprietary bullshit" in your stack!
    - notpushkin 2y ago
      I mean yeah, it isn’t really open – but it’s the informal “standard” that everyone is using nowadays. You can’t really expect every cloud provider and every app to just switch to WebDAV or something (though we can push for a gradual change here somehow!)
lucb1e 2y ago
That sounds to my self-hoster ears as an expensive way to do self hosting. Isn't at least half the point of AWS to use their SaaS thingies that all integrate with each other, I think people now call it "cloud native software"? Not that most of our customers whose AWS environment we audit do much of this, at least not beyond some basics like creating a vlan ("virtual private cloud"), three layers of proxies to "load balance" a traffic volume that my old laptop could handle without moving the load average above 0.2, and some super complex authentication/IAM rules for a handful of roles and service accounts iirc (The other half of the point is infinite scale, so that you can get infinite customers signing up and using the system at once (which hopefully pay before your infinite AWS bill is due), but you can still do that with VPSes and managed databases/storage.)
- tsimionescu 2y ago
  The point of moving to AWS is often to benefit from their data centers and reliability promises. So VPC, EC2, IAM, maybe S3 have a clear point. And one small note: apart from S3, virtually all AWS services are tied to a VPC, any kind of deployment starts with "ok, in what VPC do you want this resource?".
  - immibis 2y ago
    You can get 95% of the reliability for 10% of the price at any dedicated hoster. AWS just figured out the magic word "cloud" means they can charge you 10 times the price. At Azure or GCP you pay a similar price but you don't even get the reliability so literally why would you use them? The only reason I see is that "cloud" means you can start instances at any time without a setup fee or contract duration. But with the amount of cost difference, you could have three times your baseline "cloud" load running all the time at a non-cloud hoster, and still save money!
- notpushkin 2y ago
  It is an expensive way to do self hosting, yeah! I guess one reason is, sometimes it’s easier to just use one of big N clouds – e.g. if you’re in a regulated industry and your auditors will raise brows if they see a random VPS provider instead. (Or maybe not? If you’re doing that kind of audits I’d love to hear your thoughts!) > Isn't at least half the point of AWS to use their SaaS thingies It is. (That’s how they lock you in!) I think it’s okay to use some AWS stuff once in a while, but I’d be wary of building your whole app architecture around AWS. I’m in the self-hosters camp myself :-) I’m building a Docker dashboard to make it easier to build, ship, and monitor applications on any server: https://lunni.dev/ https://lunni.dev/
mastazi 2y ago
> [...] and S3, and you’ll be fine in any cloud Except Azure - AFAIK it's pretty much the only cloud provider that doesn't support S3 API, see e.g. https://learn.microsoft.com/en-us/answers/questions/1183760/s3-api-support-over-azure-blob-storage https://learn.microsoft.com/en-us/answers/questions/1183760/...
- notpushkin 2y ago
  Looks like one more reason for the list!
amluto 2y ago
I’m personally thoroughly unimpressed by the bare metal S3 implementations I’ve tried. And there’s also an issue with client libraries and their compatibility with various implementations. I recently discovered this issue: https://github.com/boto/botocore/issues/3394 https://github.com/boto/botocore/issues/3394 This is GCS implementing the S3 API incorrectly in a way that really ought not to break clients, but it’s still odd because the particular bug on GCS’s end seems like it took active effort to get wrong. But it’s also boto (the main library used in Python to access S3 and compatible services) doing something silly, tripping over GCS’s bug, and failing. And it’s AWS, who owns boto, freely admitting that they don’t intend to fix it, because boto isn’t actually intended to work with services that are merely compatible with S3. As icing on the cake, to report this bug to Google, I apparently need to pay $29 plus a 3% surcharge on my GCS usage. Thanks. Time to check out OpenDAL, I suppose.
- ajross 2y ago
  > As icing on the cake, to report this bug to Google, I apparently need to pay $29 plus a 3% surcharge on my GCS usage. Thanks. That's the price of a support contract, not a "bug report". And it's not "plus", it's "or": support costs $29/month or 3% of your monthly billing, whichever is greater. It comes with SLA agreements for fixing or working around your reported problems. Though obviously in this case they'll probably just tell you to use their own python library and not boto.
  - amluto 2y ago
    Oh, thanks Google, if my cloud spend is more than $967/mo, then I don’t get dinged by the $29 minimum. But this is the price of a bug report, because I can’t file a bug report without paying it. And this situation is bad business. Google advertises that GCS has S3 interoperability support. And they have customers who use it in its interoperable mode. Presumably those customers could use GCS’s biggest competitor, too. Shouldn’t Google try to make the S3 interop work correctly?
    - ajross 2y ago
      GCS and AWS are commercial products for which you pay, not open source projects you can expect to support you for free. I don't know what to say here, if you have something "serious" to do on these platforms then a 3% overhead for support seems like an obvious choice. Honestly it seems to me like you're excited to have found a bug and want to report it for glory; we've all been there. But No One Cares about that stuff in the world of commercial software. They fix bugs for real customers, not internet rock stars. If you aren't losing even $29 (one mid-tier meal!) from this bug, well... does it even rise to the level of "yell about it on HN?".
perching_aix 2y ago
It is also the reason to use proprietary bullshit services. If there was not utility gap, then a reasonable evaluation would return that a migration to them is not worthwhile. Now of course, that's a very sizable if...
- notpushkin 2y ago
  I think the main reason isn’t the utility gap – more like “nobody got fired for buying IBM^W AWS” kind of thing.

wink 2y ago

That highly depends on what services your're using. We migrated from AWS to GCP in 2016/2017 (mostly VMs and related stuff, CloudFront, etc - no lambdas) and it was pretty painless and everything worked smoothly until the end of that company.