At least until Q4 2021, Google also told large groups of employees not to bother applying for remote, as their request will automatically be denied due to a combination of role / team / organisation / tenure / office location / remote work location.
They may have reversed stance after I left, but I'm pretty sure the "15%" number cited is "15% of people that were considered eligible and had their manager support were declined."
Coming from Poland (theoretically a country with lower salaries than Portugal) this strikes me as super low - you can easily earn 2-3x that working remotely for English-speaking contracting companies, and way way more if you try to get a job at a remote first tech company.
The policy still exists (it is still encouraged, me & my coworkers used it in the last ~2 years).
The "120%" issue is up to individual / manager (like many things at Google), I just took Fridays off of my main project, other people have different approaches.
Whether doing 20% impacts performance / promotion - it again depends on the individual and their level, two data points:
- I used 20% to start a team / role transfer, ended up on a very interesting project & team which helped my career growth
- one of my coworkers used 20% to start & maintain an internal feature of a large product that directly helped his promotion case
so I think 20% is great for Google and its employees (when applied wisely).
GKE uses other GCP products, but ”k8's autoscaling for the nodes isn't any better than just simple GCP load balancers and instance groups (it literally is the same thing)” isn't entirely accurate - GKE and K8S have logic that manages node pools that you won't be able to use with just instance groups.
I owned a service running on EB that did 100QPS stable, 5K QPS weekly peak (with reasonably linear traffic increases) ~5 years ago. I'd still recommend it, but we hit some arbitrary limits / found leaky abstractions that took a lot of time to work around.
Overall, I'd much rather own a EB app (or any other PAAS, or Kubernetes) than a tangled nest of bash scripts, JIRA tickets and tribal knownledge.
Well as I alluded to in my previous comment, there are other IaC options on the table that offer better granularity for deploying cloud infrastructure (and no, I’m not talking about Bash scripts).
In fact theses days there are a lot of Infrastructure as Code solutions out there. If you deal mainly with lambdas then there’s Serverless[1] or CDK[2] (Cloud Developer Kit). EB is itself ostensibly “just” a frontend for CloudFormation[3] (as I hinted at in my earlier post). Personally I use HashiCorp Terraform[4] the most but every single one of the aforementioned bar CDK has been used in production by my team.
However if none of those float your boat then there are a whole plethora of other IaC tools out there I’ve not mentioned.
So if you’re hitting the limitations of EB then your time is well spent learning another tool. In fact I’d go further than that and say I think it is worth your while learning Terraform (or any other IaC tool) even if you aren’t hitting the limitations of EB —- but I’m biased because of having wasted so much time in the past fixing deployments that EB has completely mismanaged.
At this point I believe Google has a deep aversion to storing secrets in environment variables. The best way I have found so far is to use Cloud KMS to encrypt the credentials and have the deploy process be able to fetch and decrypt them on the fly. Some folks also store that and other config in Datastore, although I think that's really clunky. You can also use Google Cloud KMS-backed Hashicorp Vault: https://cloud.google.com/solutions/using-vault-for-secret-ma...
They may have reversed stance after I left, but I'm pretty sure the "15%" number cited is "15% of people that were considered eligible and had their manager support were declined."