Effect of ToS violations
Google-wide disabled account
In some cases a Google-wide account (which covers access to a variety of Google products like Google Photos, Google Play, Google Drive, and GCP) will be disabled for violations of a Google ToS, egregious policy violations, or as required by law. Owners of disabled Google accounts will not be able to access their Google Cloud resources until the account is reinstated. If an account is disabled, a notification is sent to the secondary email address provided during the signup process, if available. If a phone number is available, the user is notified via text message. The notification includes a link for appeal and recovery, where applicable.
In order to regain access to their GCP resources, owners of disabled Google accounts will need to contact Google support and have their account re-enabled.
To minimize the effect of an account being disabled on Google Cloud resources, we recommend that you add more than one owner to all resources. As long as there is at least one active owner, GCP resources will not be suspended due to the one of the owners being disabled.
[0]: https://cloud.google.com/resource-manager/docs/project-suspe...
A few years back, our business credit card was somehow stolen and used to buy Google Adwords. We disputed the charge with our bank. A day or two later, at 4am local time, our GCP account was suspended for fraud (presumably because the same, stolen, card was attached to that account). All instances were stopped and our service was brought to a halt.
We couldn’t contact Google Cloud support because our account was suspended. We had to go through our network to get our account re-instated. Pretty awful way to start our morning, to say the least.
Hold on while I go mine myself a ton of crypto coins.
The idea that someone could use a stolen credit card associated with an account, buy something on some Google service, have a chargeback processed as fraud and that would trigger Google's suspension of services on GCP is absurd.
You can fairly easily swap billing accounts a project is using if you still have an organisation admin account that isn't suspended. I saw this risk coming at a previous company and tried to get them to treat billing accounts like any other important resource and go for redundancy, but the director could not see the value and our Google account manager denied the risk existed, luckily they have been more fortunate and this has not happened to them yet, although it did come close once with some issues with the payments.
We actually created a portal where you can report unknown charges to Google directly; https://payments.google.com/payments/unauthorizedtransaction...
Credit card companies tell you to work with a company before issuing a chargeback, as chargebacks are a last resort. The above form helps you keep you account active without being swept up in the chargeback process.
It's something we all want to keep improving. I'm hoping as SCA (strong customer authentication) rolls out across europe and maybe other countries pick it up, it should cut down on issues like this.
The only logical thing to do in the case of a stolen or copied card is to contact the bank directly, so that the card can be canceled and fraudulent charges reversed.
When even Google themselves is recommending gaming their system since they can't guarantee it won't screw you over, that should be a warning sign.
The support isn't perfect, nor is the product -- but I would say the level of customer service for GCP can't be compared to other Google products.
1) AWS was extremely expensive
2) Our GCP bill is about 1/3 of what AWS was
3) The Kubernetes offering is top notch
4) Google giving us credits and offering us consulting were the triggers that started us talking.Always like to see why people make these big changes though, thanks!
1) Costs per customer are lower because you can fit more containers per VM due to kubernetes doing the scheduling for you. Customers also include developer environments.
2) The number of deploys is way up because there is a simple and established pattern that everyone follows.
3) The speed of creating new services has increased because of the established patterns with containers, kubernetes resources, and deploys. Thinks days vs weeks to get something running.
4) The number of Ops issues are lower because kubernetes handles so many things for you. For example, if a deploy is incorrect for some reason, the old service is sitting there running. No outage = no escalation = everyone sleeps at night.
Just don't use EKS. That is managed Kubernetes in the checkbox marketing sense only.
- Google has a lot of experience running containerized services because of Borg. Google Research says that they have been running these workloads since 2005.
- The above gives them insight into how to do this well. They would have the internal infrastructure, logging and monitoring already setup.
- They are the creator and still a major contributor to Kubernetes itself which means they can insert their influence on it.
Note: I am responsible for 5 clusters, 300+ nodes total and several thousand running services. Not huge by any means.
Amazon also has been running internally on containers for years before ECS. But workloads for massive FAANG companies designed by FAANG engineers turn out to be quite different than most AWS/GCP customers.
Just like EC2 wasn't Amazon selling its "spare capacity during off-peak" but always a purpose built service with completely isolated data centers and network fabric from day 1, the connection between Borg and Kubernetes is tenuous at best.
Honestly, I would encourage you to evaluate ECS and Fargate. Forget Kubernetes and direct instance management. Try a construct like https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws... and see how much simpler it is than all the K8S overhead.
Source: I'm at Amazon but I work on none of these services and opinions are my own. I played with K8S and am eternally confused how it's as popular as it is. I guess it gives you the illusion of not having lock in?
2. Does ECS have something similar to pods, i.e. colocated containers which can communicate over localhost, share filesystems, etc? A quick search didn't turn anything up.
I don't see K8S being about lock-in at all. Using a cloud provider gives you some sort of lock-in and you should be utilizing that providers strengths.
Using Kubernetes is all about the patterns that it provides and how it removes a certain class of problems for you. Deployments, scaling, logging, etc are some of the patterns it provides and the consistency matters. How many of us have worked at companies where deploying two services have been completely different? One team runs the jenkins pipeline while another ftps the files over. Now multiply that by several services and several tasks (logging, scaling, etc).
The benefit is in the patterns.
What were your pain points with ECS? Did you use ECS with or without fargate? What about EKS, since that sounds like a closer equivalent to GKE.
I've used ECS more than fargate. My biggest problem comes from reliability and having to manage things. We still run things on ECS and we get about 30x as many maintenance things we need to do, like retiring instances or instances just dying on us and we have to move things off of it manually.
I have a little bit of experience in Fargate from a previous job but not enough to make a real conclusion about it.
I've never used EKS but I do have friends that would rather roll their own version of Kubernetes on EC2 instance instead of using EKS.
This makes very little sense for Cloud Computing where each one your clients gives you large amounts of cash. Maybe they are too used to the first scenario.
edit: revenue GROWTH is declining
https://venturebeat.com/2020/07/31/probeat-slowing-aws-micro...