Hi

I am looking for an API Gateway to be implemented. The gateway will be handling around 1B API calls everyday and it contains all sort of API calls including B2B and B2C.

I was looking to use APIGEE X but would like to get an understanding

Can someone share any thought and also share the rough estimate around the cost?

How to become a google professional cloud devops engineer?

Please i need help

Hi Everyone

I’m planning to sit for the new GCP Professional Agentic Architect Beta exam soon and was wondering if anyone happens to have a spare or unassigned voucher code (from a challenge, partner event, or cohort) that they won’t be using before it expires?

I know beta exams come with the built-in 40% discount, but if someone has an extra voucher to share via DM or knows of an active community challenge giving out exam passes right now it would be a huge help.

Thanks in advance!

Running the obsolete Centos 8.5. Has a public webserver and has been working perfectly for 6+ years. If it ain't broke don't fix it. I wonder how long before Google forces me to update the OS?

I avoid rebooting it as then it will grab a new public IP and I have to update all my DNS records for it's domain name.

BQ has been super slow today for me. Is this happening to anyone else?

thought moving our phone infrastructure to GCP would be straightforward. compute instances, cloud sql, storage. spent weeks just getting the networking right. firewalls, VPCs, cloud armor. and then the SIP trunking. that was a whole other nightmare. carrier didn't want to work with our setup. had to go back and forth with their engineers for like 2 weeks.

the GCP side? I underestimated how much work it would be.

I know GCP well. I've built complex systems on it. but voice is different. latency matters. jitter matters. you can't just throw compute at it. anyway we're live now it works. but I'm not sure I'd do it again. or at least I'd budget more time for the networking setup.

anyone else running voice workloads on GCP. what was your biggest unexpected challenge

Hi everyone,

I’m sharing our experience with a recent Google Cloud / Gemini API unauthorized usage incident, mainly to understand whether others have faced a similar situation.

We are a small French tech company and we also manage Google Cloud environments for some of our clients.

In June, one of our own Google Cloud projects was affected by unauthorized Gemini API usage, resulting in approximately €16,600 in charges.

Our Cloud Audit Logs show unauthorized administrative operations, including:

• enabling Gemini-related services;
• creating a service account for a Gemini API key;
• creating a new Gemini API key;
• followed by significant unauthorized Gemini API consumption.

We detected the incident when the visible consumption was around €3,737 and immediately took action to secure the environment. Despite this, the final amount reached approximately €16,600.

Google Cloud Support investigated the case, but ultimately declined the billing adjustment.

Here is where things become difficult for us to understand.

We also manage another Google Cloud account for one of our clients, and that account was affected by an incident showing essentially the same technical pattern:

Client account

• Same date
• Same Gemini API service
• Same Google identity appearing in the unauthorized operations
• Same source IP
• Same type of Gemini API/service-account creation
• Approximately CAD 27,000 in unauthorized charges
• 100% billing adjustment granted by Google

Our own account

• Same date
• Same Gemini API service
• Same Google identity appearing in the unauthorized operations
• Same source IP
• Same type of unauthorized operations
• Approximately €16,600 in unauthorized charges
• Billing adjustment denied

We fully acknowledge our share of responsibility regarding cloud security and that additional safeguards could have been implemented.

However, what we are struggling to understand is the completely different outcome for two incidents presenting the same technical pattern.

One important difference is that the client account was handled directly with Google Cloud, while our own account is billed through a Google Cloud distribution/reseller channel.

If both cases had been denied, we could understand that this was simply Google's policy for this type of incident.

But having personally managed both cases, seeing approximately CAD 27,000 adjusted at 100% in one case while €16,600 is denied in the other is extremely difficult to understand.

For a small startup, €16,600 is not a minor unexpected cloud bill. It can have a very serious impact on cash flow and business continuity.

Has anyone experienced a similar situation?

In particular, I would be interested to know whether anyone has seen different exceptional billing adjustment outcomes between direct Google Cloud accounts and accounts billed through a reseller/distribution channel.

I’m not looking to blame anyone — I’m genuinely trying to understand what could justify such a different outcome for two cases with the same technical pattern.

Thanks for any feedback or similar experiences.

Am I doing something wrong or is there a severe shortage of resources in Belgium? n1 n2 and e2 are for sure unavailable most of the time, probably other machines too. Does anyone else experience the same problem?

https://downdetector.com/status/google-cloud/

Google Cloud multi-product customers are experiencing elevated packet loss and errors to/from us-central1-b.

Impacted products (12) and locations (1) Products

Impacted locations

AlloyDB for PostgreSQL us-central1-b

Cloud Filestore us-central1-b

Cloud Run us-central1-b

Cloud Spanner us-central1-b

Google App Engine us-central1-b

Google BigQuery us-central1-b

Google Cloud Bigtable us-central1-b

Google Cloud Dataflow us-central1-b

Google Cloud SQL us-central1-b

Google Compute Engine us-central1-b

Hybrid Connectivity us-central1-b

Virtual Private Cloud (VPC) us-central1-b

Most recent update – 3 minutes ago September 1, 2026 at 10:38:32 AM UTC-5

Google Cloud multi-product customers are experiencing elevated packet loss and errors to/from us-central1-b.

We are experiencing an issue with Hybrid Connectivity Tuesday, 2026-09-01 07:44 US/Pacific.

Our engineering team continues to investigate the issue.

We will provide more information by Tuesday, 2026-09-01 09:15 US/Pacific with current details.

We have 2000$ in GCP credits + 1000$ in GenAI app builder.

Wondering if we are eligible to use those credits within Google Antigravity. Basically I can't find the way to do so, choosing my GCP project as a sign up method states that the project can't be used ??

As promised - my comment on passing the PCA exam.

Used the official material from the google skills course plus Gcp Study Hub (thank you).

Noted tad heavier questions around resilience and network architecture blueprints.

Luckily I got my grounding in resilience elsewhere, so was able to get through.

Hand on experience with GCP also helps.

I've been struggling with a particularly strange issue.

My work uses GCP. I have a Google workspace account which is connected to a few GCP projects at work.

I do not log into my personal email on my work laptop, the only place where both reside is on my phone where I have both my work email and my personal Gmail on the same phone for Google apps.

Sometimes I am finding my personal Gmail as a user in my work GCP projects. Or course I don't want this.

Does anyone know what might be going on and how to prevent it?

I am trying to use the google_ml_integration extension in a Cloud SQL PostgreSQL instance to generate text embeddings via Vertex AI, but the query fails with an unavailable error.

What I Have Done:

1. Extensions Created: Enabled both vector and google_ml_integration in the database.
2. IAM Permissions: Granted the aiplatform.user role to the Cloud SQL service account associated with the instance.
3. Billing: The GCP project has billing enabled and the Vertex AI API is active.

The Error:

When running the following query:

SQL

SELECT google_ml.embedding('text-embedding-gecko', 'your_text_here');

It throws this error:

What could be the reason for this? Are there missing database flags, or a specific setup step required for Cloud SQL to communicate with Vertex AI?

Used gemini for formatting

Found a VM in one of our AWS accounts the other week, no EDR, no patching history, and a public IP for reasons nobody could explain. Its been running for about a year.

The name is WIN-DEV-05, which is where the fun starts. The cloud team never looked at it because it sounds like a desktop, clearly an endpoint thing. The endpoint team never saw it because it never came through procurement or Intune, clearly a cloud thing. Both tools in our stack see the VM perfectly fine, both teams have just been politely assuming the other one owns it. For a year.

So the machine sits in the one place nobody's job description covers, with nothing installed on it and a public IP, and the only reason we found it is a scanner alert nobody could route, because routing needs an owner and this thing has never had one.

How do you all decide who owns a cloud VM, the cloud team or the endpoint team, because the answer here was neither.

Noticed my monthly bill was $5-10 higher per month for past several months. Just chalked it up to inflation and maybe more usage of compute engine VMs. But based on the billing report it seems I am not getting the free credit for my E2 micro instance. I have had this same instance for 5+ years! I haven't even rebooted it in 4+ years. Billing glitch or some policy change I wasn't aware of?

Hi everyone,

I passed the GCP Professional Cloud Architect (PCA) exam 5 days ago. My Credly badge was issued right away, and my status in the CertMetrics portal is already marked as Active.

However, I haven't received any official welcome email or the merchandise/swag code email yet.

Do they still offer swag for PCA passes, and if so, how long does it usually take for the swag email to arrive after becoming Active in CertMetrics? Should I wait a bit longer or open a support ticket?

Thanks!

Been digging into this lately and figured I'd share, since it cleared up something I was fuzzy on: how BigQuery actually discovers Iceberg tables, and what's genuinely new here vs. what's just been repackaged.

The old ways of doing this:

1. Pointing BigQuery straight at a metadata file. Something like gs://bucket/orders/metadata/00003.metadata.json. It works, but it's fragile. Iceberg writes new metadata files instead of editing the old ones, so if any other engine commits a new snapshot, your pointer is instantly stale. You're stuck manually bumping it to 00004.metadata.json every time.
2. Catalog based access, like using AWS Glue as an external catalog. This actually fixes the staleness problem since the catalog tracks current state for you. But every engine still needed its own custom integration to talk to that catalog.

What's actually new: Google now has a managed Lakehouse Runtime Catalog (BigLake) that exposes a real Apache Iceberg REST Catalog endpoint, using the same open REST Catalog spec other engines already speak. So instead of building a one off integration per engine, anything that already understands Iceberg REST can just talk to BigLake directly. The data itself never moves, it stays in Cloud Storage. BigLake is really just a metadata and governance layer with IAM sitting on top of it.

There's also a version detail worth knowing: Iceberg 1.10 shipped a native BigQueryMetastoreCatalog and BigQueryMetastoreClient, plus a GoogleAuthManager that handles Google credential auth inside Iceberg's REST auth framework. It's easy to conflate these two things, but they're not the same. One's a catalog implementation built for BigQuery Metastore specifically, the other is the standardized REST interface. Google's steering people toward the REST endpoint for anything new where cross engine interoperability matters.

The post I read also gets into the practical setup side: creating a BigLake catalog (single bucket vs multi bucket), the IAM roles Google recommends (BigLake Admin, Editor, Viewer, plus Storage Object User), and shows an open source tool called OLake Go (full disclosure, I work on this) writing Iceberg tables directly into that catalog so BigQuery can see them right away, queryable through the usual four part PROJECT.CATALOG.NAMESPACE.TABLE identifier with no manual metadata pointer updates. There's a decent troubleshooting section too. Apparently if your connection test passes but the actual sync fails, it's almost always a missing storage level IAM role rather than bad credentials.

Full post here if you want the details: https://olake.io/blog/biglake-iceberg-rest-catalog-olake-go-setup/

Curious if anyone here has already moved existing Iceberg on BigQuery setups over to the REST catalog, or if you're all still doing the manual metadata file dance like I was.

I'm an indie developer running a production mobile app using Firebase / Google Cloud. My normal Firebase/GCP bill is around €50/month.

In June, my bill suddenly jumped to €5,000+.

Almost all of the unexpected usage was attributed to Vertex AI / Gemini image generation.

The problem is: my app wasn't using Vertex AI.

I use Firebase for the normal backend infrastructure of the app, but I wasn't intentionally running Gemini/Vertex AI image generation. I still have no idea what generated thousands of euros of AI usage on my account.

I don't know whether some credentials were compromised, there was a configuration issue, or something else happened.

What makes this particularly concerning is the scale: an account that normally costs me around €50/month suddenly generated a bill roughly 100x higher.

I contacted Google Cloud Billing Support on July 3 and opened case #72899288.

Google confirmed that around €5,500 of June usage was mostly related to Vertex AI and offered to submit an adjustment request for investigation.

They asked me for details about what happened, the affected dates and SKUs, screenshots of the charges, and other information related to the incident. I provided everything they requested.

Since then, the case has apparently been with Google's specialized/engineering team.

That was almost two months ago.

I've repeatedly been told some variation of:

"The specialized team is investigating. We'll update you within 2–5 business days."

Then 2–5 business days pass, I follow up again, and essentially receive the same answer.

Almost two months later, I still don't have a result from the investigation.

Google keeps blocking my production account while investigating the charges

Because the disputed €5,000+ remains on my account, Google's billing system keeps treating it as an unpaid balance.

Support knows the charge is under investigation and has repeatedly given me payment/grace-period extensions specifically so my production services can remain operational while the investigation continues.

Despite this, my account has been suspended at least 3 times during the investigation.

When this happens, my production backend stops working and actual users of my app are affected.

I then have to contact Billing Support, explain the situation again, wait while they contact another internal team, get another extension, and get the account reactivated.

One incident was particularly frustrating.

On August 14, a Google Support agent explicitly confirmed that my payment deadline had been extended until August 28 and told me:

"Your account and production applications will remain fully active while your case remains under investigation."

On August 16, the account was suspended anyway.

I contacted support again. Another agent checked the history and confirmed that the grace-period extension until August 28 had actually been successfully approved.

Eventually another support agent manually reactivated the account.

Then I received a debt collection warning

While Google's own team was still investigating the disputed charges, I received a message from Google warning that the unpaid balance could be sent to a debt collection agency.

So Google is still investigating whether/how these €5,000+ Vertex AI charges occurred, while at the same time its billing system has repeatedly suspended my production account and its collections process has warned me about debt collection for that same balance.

I contacted support about this as well. They told me they would contact the collections team and ask them to suspend the collection-related correspondence while the investigation remains open.

There's also no simple hard spending limit

Another frustrating part of this experience is how difficult it was to protect against this kind of situation.

I had billing monitoring, but at the time of the incident the normal Google Cloud budget functionality wasn't simply a hard account spending limit.

What I would have wanted was something very simple:

"My account normally costs €50/month. Don't allow it to spend more than €200."

Instead, an account with roughly €50/month of normal usage was able to accumulate more than €5,000 of AI usage.

And this wasn't a service I was knowingly using in the first place.

Almost two months later

Almost two months after opening the case, the investigation is still not complete.

I've provided Google with all the information they requested and have followed up repeatedly. At this point, I don't want another temporary payment extension or another promise that I'll receive an update in 2–5 business days.

I simply want Google to finish the investigation and make a decision.

Having to contact Billing Support every couple of weeks to prevent a production Firebase account from being suspended — while waiting for Google's own investigation — isn't a sustainable solution.

I'm posting this here because I've exhausted the normal support process and don't know where else to escalate it.

If anyone from Google Cloud is reading this and can help get case #72899288 in front of the right team and finally get the investigation completed, I would really appreciate it.

And if anyone here has dealt with a similarly stuck Google Cloud billing investigation, I'd be interested to hear how you eventually got it resolved.

Canadian medium sized enterprise private sector.

Executive team considering repatriating enterprise data from GCP to local hosting company.

I'm responsible for cloud in our company. What do I tell her?

Edit: Yes, I know about the US CLOUD act.

After dealing with countless signup issues, payment verification problems, anti-fraud blocks, billing confusion, and AI service limitations, I decided to write everything I know in one place.

Save this post. What you are reading is the result of two years of hands-on experience helping hundreds of small and medium-sized businesses activate Google Cloud Free Trial accounts and start using AI solutions in their companies.

1. What Is Google Cloud Free Trial?

Google Cloud offers new users:

• $300 USD in free credits
• Valid for 90 days
• No automatic charges during the trial period

When you sign up, Google requires:

• Personal information
• Tax information depending on your country
• A payment method

The payment verification process is handled by Google’s anti-fraud systems, and sometimes legitimate users are blocked because their account does not look trustworthy enough.

2. What Can You Use the $300 Credits For?

The credits can be used for many Google Cloud services:

• Compute Engine (VMs): Yes
• Cloud Storage: Yes
• Cloud Run: Yes
• Cloud Functions: Yes
• Kubernetes Engine (GKE): Yes
• Cloud SQL: Yes
• BigQuery: Yes
• Vertex AI / Gemini Agent Platform: Yes
• Google AI Studio API: No

Be extremely careful with this. Many people believe they are testing Gemini using their $300 credits, but they are actually consuming another billing method.

Before using any resource, always verify if it is eligible for Free Trial credits.

Full list: https://docs.cloud.google.com/free/docs/free-cloud-features#free-tier-usage-limits

IMPORTANT: Your Google Cloud Free Trial credits can be used for Gemini AI, but only through Google Cloud’s AI platform (formerly Vertex AI, now part of the Agent Platform ecosystem). They cannot be used for Google AI Studio.

3. Payment Verification Problems

Most signup failures are not technical errors. They are Google’s anti-fraud system refusing to trust the account.

The two errors I have seen the most are:

• OR_BACR2_44 — Payment Method / Account Trust Issue

This error usually means Google does not trust the combination of your account, network, location, and payment method.

Common causes:

- Virtual cards

- VPN or proxy

- Mobile network IP

- New Google account

- Browser privacy tools

What usually helps

- Use a physical credit card

- Use a traditional bank card

- Make sure your card name matches your account

- Use your home WiFi

- Disable VPN/proxy

There is no guaranteed fix. The goal is to make your account look as legitimate as possible.

• OR_BACR2_59 — Higher Risk Anti-Fraud Block

This is a more complicated issue.

It often happens when Google flags:

- Your IP address

- Your personal information

- Your account history

Some solutions that worked:

- Different Google account

- Different IP address

- Different network

4. The Prepayment Requirement

Some accounts are required to make a prepayment before receiving the free credits.

The amount varies by country and risk evaluation.

Typical range: $10-$50 USD

This payment is refundable.

5. How Prepayment Works

The prepayment creates a billing balance, and this is where many users get confused.

The prepayment is not completely separate from your Google Cloud usage.

Example:

You receive: $300 Free Trial credits and you make: $20 prepayment

If you use only eligible services, your Free Trial credits are consumed first.

However, if you use a service that is NOT eligible for Free Trial credits, Google can consume the prepaid balance.

Always verify if a service is eligible before using it. Check eligible services:

https://docs.cloud.google.com/free/docs/free-cloud-features#free-tier-usage-limits

6. Requesting a Prepayment Refund

I want to be transparent here: I have not personally tested every refund scenario. This information comes from reports from users I helped and people sharing their experiences.

The refund can be requested using the dedicated refund button.

Video showing the process: https://youtu.be/j2swZiMSKuY?si=Z-8iNyzxsAlxqL-W

The refund approval email usually arrives quickly. However, the money can take a week or more to appear back on your card.

If it takes longer than two weeks, contact Google Cloud support and specifically ask to speak with a human agent. Automated support often cannot solve billing cases.

One thing that is still unclear:

Some users reported that requesting the refund may remove their Free Trial credits.

I have not confirmed this personally.

7. The “Activate” button trap

This is one of the most important things new users need to understand.

During the Free Trial, Google may show a very visible button saying: “Activate”

Many people think this means activating their free credits. It does not!

This action converts your account into a full billing account, which allows Google to charge your payment method after the Free Trial period ends.

Your Free Trial credits and remaining trial period do not change:

• You still have the same $300 USD credits.
• You still have the same 90-day trial period.
• You do not lose your remaining credits.

The main difference is what happens after the trial ends.

With the Free Trial, Google does not automatically charge you after expiration.

With a full billing account, your services can continue running and Google can charge your payment method if you do not manually stop resources or disable billing.

One important benefit of activating the full account is that your quotas and service limits increase. The Free Trial account operates with more restrictive limits, and users working with AI services often hit those restrictions. After activating the full account, higher quotas become available.

But remember: If you forget to disable billing after the trial period, Google can charge your card. And a small mistake can become a huge bill. Be careful. Billing alerts only notify you. They do not stop spending.

PS: Do not panic if your billing page shows your Free Trial credits as expired after activating the full account. This does not mean you lost your credits. The credits are reactivated as credits from the full billing account, so they continue to be available.

If you experienced another issue, comment below and help make this guide more complete.

Claude Code, Gemini, Cloud Run

This is a warning post. If you are about to build something on Google — Cloud, Gemini, any of it — read this first and then decide.

I picked Google Cloud for my AI project because it looked like the serious choice. Gemini, Vertex AI, Cloud Run, all in one place. Solo dev, portrait retouching service, my own money, my own card, my own quota.

Step one of the famous convenience: learning that everything in GCP is denied by default until you find the one permission buried nine menus deep among a million parameters with nearly identical names, and switch it on. Then the next one. Then the next one. Fine — that's the tax for a serious platform. I paid it. I ended up with nine Cloud Run services in asia-south1 and a pipeline I'm genuinely proud of.

Then I went to work from the Himalayas, because I think better there. I was doing prompt research — controlled batches of 20-30 generations, reviewed by hand between batches, through Codex, Claude Code and Google's own Antigravity. Precisely the workflow Google advertises on stage.

Google's security system looked at all of that and decided, without asking me, that it knew how to protect MY account better than I do. The one I pay for, with my own money.

Banned. No reason. No warning. No policy cited. No email. Nothing.

Convenience highlight #1: the services kept running. I checked — orchestrator returns 200, all eight processors return 405 to a GET, which is correct because they only accept POST. A stopped or deleted Cloud Run service returns 404. So they are alive, serving traffic, and billing me. Google did not decide my workload was dangerous. It decided it didn't want me near it. The robots stayed. The human was removed. Very cyberpunk.

Convenience highlight #2: I was the sole Owner, and GCP never once suggested I add a backup. So there is now nobody on Earth who can administer this project, including Google's paying customer. Can't deploy, can't read logs, can't even shut it down to stop the charges.

Convenience highlight #3: I sign in to Claude with that Google account. About SGD 150 a month. Also gone, also still charging. Anthropic can't help me either, because their recovery flow emails a code to the inbox Google just made unreadable. Google's security has now successfully protected me from a company that isn't Google, using money that isn't Google's.

Now the part that made me write this.

Two days ago Google emailed me: "Appeal approved." They reviewed it, they agreed, the account is restored, please sign in as soon as possible.

I have not managed to sign in once since.

"Too many failed attempts. You can continue in a few hours." Come back in a few hours. Prove you're not a robot. Prove it again. And again. A new obstacle every time, never a step forward, never one word about what I am supposed to do differently. I am not failing a security check — I cannot get far enough to take one.

So I am solving captchas to prove I am human, for a system that flagged me for looking too automated, to reach an account that has officially already been given back to me. My appeal succeeded and nothing changed. An approved appeal that doesn't restore access isn't a resolution — it is written confirmation that they were wrong, followed by absolutely nothing.

And here is the actual warning, which is bigger than my situation.

Google has built the most user-hostile security system I have ever encountered, and I want to be precise about why, because "their security is annoying" doesn't capture it.

Every security system trades off keeping the wrong people out against letting the right person in. Google has resolved that trade-off, permanently and in every product I have touched, in favour of assuming the account holder is the threat. It does not ask you. It does not warn you. It does not tell you afterwards. It decides — and then it makes you prove, over and over, to an automated gate with no human behind it, that you are the person whose name is on the card that pays for it.

The part that should actually worry you: this is not the free consumer tier. This is the paid, professional, run-your-business-on-it tier. The same paternalism that locks somebody out of their family photos is sitting in front of production infrastructure with a credit card attached to it, and it is just as willing to fire. It knows better than you. It always knows better than you. In a photo app that's irritating. In front of your company's infrastructure it is a business risk that nobody puts on the pricing page.

And because Google made one account the key to everything — mail, Cloud, identity for third-party services — one automated misfire doesn't take one thing from you. It takes the infrastructure, the mailbox, the ability to receive the recovery codes for everything else, and your access to services you buy from other companies. There is no blast door anywhere in that design. One decision, made by nobody, removes all of it at once.

For the record, their own Terms of Service section 4.1 says that if Google believes you violated the AUP, Google will notify you and give you 24 hours to correct it before suspending. I received zero notifications and zero hours. Section 4.2 permits instant suspension to "protect the Services" — and the Services, as established above, are magnificently unprotected and still running.

What I would actually tell you to do:

• If you're on GCP as a solo dev, add a second Owner account to every project. Today. I can't anymore, and that is the whole lesson.
• Don't let one Google account be your identity for anything you can't afford to lose. Use a real email you control for third-party sign-ins.
• Keep your infrastructure somewhere you can still reach when Google decides, without telling you, that you are suspicious.

So here is where this has actually left me. Instead of moving my product forward — the thing I was doing, with my own money, on their platform, in the weeks I had set aside for it — I spend my days solving Google's captchas and writing Google letters. Not to build anything. Not even to get back into Google's own product. To regain access to a service that is not Google's, that I pay a different company for, and that Google is still, right now, blocking me from reaching.

That is what their security achieved. Not one bad actor stopped. One paying developer taken off his own work for days, doing unpaid administrative labour to undo an error nobody will explain, while the meter runs.

I am not saying the products are bad. Gemini is very good, and I built here on purpose. I am saying that the company running them will take them away from you without a word, hand you an appeal form, approve the appeal, and still leave you outside the door — and that you should price that in before you build a business on it.

Extremely convenient platform. Would get banned again.

^(This was written with the help of an AI so I don't shock anyone with my natural vocabulary. Peace and love to everybody — including, reluctantly, Google.)