8 ms·

My Google Cloud was suspended too

87 points by splix 4y ago

onetokeoverthe 4y ago
dlahoda 4y ago
likely during migration author will use more of iac like terraform, nix, kustomize. so it will reduce their deps on specific cloud. so they can switch faster to any cloud and use tf modules which wraps same things from clouds.
- icedchai 4y ago
  Yeah, because switching clouds with terraform is trivial. /s In any code I've seen in the wild, all resources are coded to a particular cloud provider.
  - mixedCase 4y ago
    It's not about the specific resources for the most part, it's about knowing what needs replacing and why things are where they are, all while keeping your migration under version control. Also to be fair, with good enough module abstractions and generic enough problems you can completely replace their implementation with few changes to their call sites for things like: - A module that fully sets up a static site with DNS, CDN on an S3-compatible service - A module for setting up an OCI image repo, and spinning resources that runs an image from it as a daemon somewhere. - A module for setting up an OCI image repo, and sets up a "cron" job to run a binary off of it. Sure the migration is unlikely to be as clean as terra[grunt|form] down && terra[grunt|form] up but it can get close.
    - icedchai 4y ago
      This sounds good in theory. No terraform code I've seen has had that level of abstraction. It's basically copy-pasta everywhere! Maybe I've just had bad luck taking over poorly done, pre-existing projects. Could you point me to a well written example?
      - baobob 4y ago
        There is a lot to be said for just having 100% Terraform defs for everything, sure you rewrite the file from scratch to move to a different cloud, but you know what needs to be in the file
      - mixedCase 4y ago
        I've written code like that for clients (and specifically executed a transition from bare metal+shell scripts to EKS for a "generic backend" module once), but I can't publish any of it for unfortunate obvious reasons. But FWIW I think it's inherent to IaC to involve a lot of copy-pasta, sometimes your best abstraction will just lead to shifting the copy-pasta from code to call-sites, which tends to be more maintainable but still. What I can recommend is to treat your modules for what they are: Public library functions. Meaning common sense advice for those applies: - Approach writing modules by actually designing an API for it. Don't treat it as a folder to dump resources in. - Make your API as small as you can get away with. - Its variables and outputs should be, whenever possible, describe a generic black box that could have its internals swapped. - Make modules composable where you can. Being able to pass around entire module instances in variables because they have clean, stable APIs is very nice. - Accept some things will inevitably leak but put in the effort to minimize them. This blog post and the book from the authors (Terraform Up & Running) has some good ideas that got me started with the basics, but there's not much written with regards to more involved usecases: https://blog.gruntwork.io/how-to-create-reusable-infrastructure-with-terraform-modules-25526d65f73d https://blog.gruntwork.io/how-to-create-reusable-infrastruct...
        icedchai 4y ago
        thank you. That link looks interesting!
        shyn3 4y ago
        I like your advice but this misses the MOAT of the cloud which is being able to utilize the IaaS/Papas they provide. For example if you are building in azure today going with SQL doesn't make sense because Cosmos and service bus/event grids handle that. This locks you into the vendor bad makes it near impossible to leave.
- splix 4y ago
  Thank for kustomize, that looks interesting. As we tried to start the migration, we found out that's it not so trivial. I initially hoped that the Kubernetes part could be easily migrated. Not really. We learned that things like Load Balancers should be configured differently, but that's fine. The biggest problem is that we have to reconsider the build process because the Docker registry, CI, and everything related are on GCP too. Then comes the fact that we built internal db on Bigtable, which we couldn't just switch to DynamoDB. So I guess it will be a slow process of restructuring everything to be free from vendor lock-in.
  - deleted 4y ago
    [deleted]
Cameri 4y ago
Decentralization is the only way it's safe out here. Once you give this much power to a monopoly we just look like insects to them. I've moved most of my accounts outside of Google that if I were to lose them it'd be a shame but not a total loss for me. I could then rebuild. Support the little guy today and you will have immunity by decentralization.
- frognumber 4y ago
  Honestly, AWS and Microsoft both seem pretty safe right now. This is pretty unique to Google. I keep warning people never to use Google for B2B, and I keep seeing people get burned. Decentralization means there's a fire ever month, as some startup goes under or pivots. AWS, Azure, and Office 365 seem to take business continuity seriously.
  - paulryanrogers 4y ago
    > Decentralization means there's a fire ever month, as some startup goes under or pivots. Not sure that follows. Startups are often chasing the kind of hockey stick growth only seen where monopolizing markets (or at least their profits) is possible.
- sfe22 4y ago
  Upvoted. Love that you are not suggesting that another (worse?) monopoly (the government) has to come and save us poor devs. We have options and in reality Google is not a monopoly.
  - paulryanrogers 4y ago
    Without government enforcing a competitive market the inevitable consolidation will just continue to create and entrench monolpolists. Incentives tend towards one (or a few) winner takes all.
    - sfe22 4y ago
      that is very wrong though. Governments or other monopolies don't enforce free markets. People are free by default and act as such, unless someone forces them otherwise (a big government).
FerretFred 4y ago
All after being a loyal customer for ~14 years 14 years for Igor to realise that he was The Product. Loyalty counts for nothing if you're not paying, and even then, it's not guaranteed.
- wodenokoto 4y ago
  You pay for google cloud.
  - FerretFred 4y ago
    I realise that, so this event is even worse.
  - frognumber 4y ago
    Customer-as-product is in Google's DNA. You can pay them $5M per year, and you're still the product.

87 points by splix 4y ago

likely during migration author will use more of iac like terraform, nix, kustomize. so it will reduce their deps on specific cloud. so they can switch faster to any cloud and use tf modules which wraps same things from clouds.

icedchai 4y ago
Yeah, because switching clouds with terraform is trivial. /s In any code I've seen in the wild, all resources are coded to a particular cloud provider.
- mixedCase 4y ago
  It's not about the specific resources for the most part, it's about knowing what needs replacing and why things are where they are, all while keeping your migration under version control. Also to be fair, with good enough module abstractions and generic enough problems you can completely replace their implementation with few changes to their call sites for things like: - A module that fully sets up a static site with DNS, CDN on an S3-compatible service - A module for setting up an OCI image repo, and spinning resources that runs an image from it as a daemon somewhere. - A module for setting up an OCI image repo, and sets up a "cron" job to run a binary off of it. Sure the migration is unlikely to be as clean as terra[grunt|form] down && terra[grunt|form] up but it can get close.
  - icedchai 4y ago
    This sounds good in theory. No terraform code I've seen has had that level of abstraction. It's basically copy-pasta everywhere! Maybe I've just had bad luck taking over poorly done, pre-existing projects. Could you point me to a well written example?
    - baobob 4y ago
      There is a lot to be said for just having 100% Terraform defs for everything, sure you rewrite the file from scratch to move to a different cloud, but you know what needs to be in the file
    - mixedCase 4y ago
      I've written code like that for clients (and specifically executed a transition from bare metal+shell scripts to EKS for a "generic backend" module once), but I can't publish any of it for unfortunate obvious reasons. But FWIW I think it's inherent to IaC to involve a lot of copy-pasta, sometimes your best abstraction will just lead to shifting the copy-pasta from code to call-sites, which tends to be more maintainable but still. What I can recommend is to treat your modules for what they are: Public library functions. Meaning common sense advice for those applies: - Approach writing modules by actually designing an API for it. Don't treat it as a folder to dump resources in. - Make your API as small as you can get away with. - Its variables and outputs should be, whenever possible, describe a generic black box that could have its internals swapped. - Make modules composable where you can. Being able to pass around entire module instances in variables because they have clean, stable APIs is very nice. - Accept some things will inevitably leak but put in the effort to minimize them. This blog post and the book from the authors (Terraform Up & Running) has some good ideas that got me started with the basics, but there's not much written with regards to more involved usecases: https://blog.gruntwork.io/how-to-create-reusable-infrastructure-with-terraform-modules-25526d65f73d https://blog.gruntwork.io/how-to-create-reusable-infrastruct...
      - icedchai 4y ago
        thank you. That link looks interesting!
      - shyn3 4y ago
        I like your advice but this misses the MOAT of the cloud which is being able to utilize the IaaS/Papas they provide. For example if you are building in azure today going with SQL doesn't make sense because Cosmos and service bus/event grids handle that. This locks you into the vendor bad makes it near impossible to leave.
splix 4y ago
Thank for kustomize, that looks interesting. As we tried to start the migration, we found out that's it not so trivial. I initially hoped that the Kubernetes part could be easily migrated. Not really. We learned that things like Load Balancers should be configured differently, but that's fine. The biggest problem is that we have to reconsider the build process because the Docker registry, CI, and everything related are on GCP too. Then comes the fact that we built internal db on Bigtable, which we couldn't just switch to DynamoDB. So I guess it will be a slow process of restructuring everything to be free from vendor lock-in.
- deleted 4y ago
  [deleted]

Cameri 4y ago

Decentralization is the only way it's safe out here. Once you give this much power to a monopoly we just look like insects to them. I've moved most of my accounts outside of Google that if I were to lose them it'd be a shame but not a total loss for me. I could then rebuild. Support the little guy today and you will have immunity by decentralization.

frognumber 4y ago
Honestly, AWS and Microsoft both seem pretty safe right now. This is pretty unique to Google. I keep warning people never to use Google for B2B, and I keep seeing people get burned. Decentralization means there's a fire ever month, as some startup goes under or pivots. AWS, Azure, and Office 365 seem to take business continuity seriously.
- paulryanrogers 4y ago
  > Decentralization means there's a fire ever month, as some startup goes under or pivots. Not sure that follows. Startups are often chasing the kind of hockey stick growth only seen where monopolizing markets (or at least their profits) is possible.
sfe22 4y ago
Upvoted. Love that you are not suggesting that another (worse?) monopoly (the government) has to come and save us poor devs. We have options and in reality Google is not a monopoly.
- paulryanrogers 4y ago
  Without government enforcing a competitive market the inevitable consolidation will just continue to create and entrench monolpolists. Incentives tend towards one (or a few) winner takes all.
  - sfe22 4y ago
    that is very wrong though. Governments or other monopolies don't enforce free markets. People are free by default and act as such, unless someone forces them otherwise (a big government).

FerretFred 4y ago

All after being a loyal customer for ~14 years 14 years for Igor to realise that he was The Product. Loyalty counts for nothing if you're not paying, and even then, it's not guaranteed.

wodenokoto 4y ago
You pay for google cloud.
- FerretFred 4y ago
  I realise that, so this event is even worse.
- frognumber 4y ago
  Customer-as-product is in Google's DNA. You can pay them $5M per year, and you're still the product.