I’m certainly overlooking something but the risk seems small since it uses an open standard. You should be able to fallback to another acme provider right?

More like: first they become the dominant acme provider, then the other ones go away so they are the only one left, and then they have you where they want you.

They have you where they want, you are willing to pay, ... but the close down the service anyway with a three months notice.

> first they become the dominant acme provider

The traditional way a big tech company becomes the dominant provider is to embrace an open interoperable protocol to minimize the friction of switching from another provider. Later, when they have captured enough of the market, they extend the protocol to gradually reduce the de facto interoperability with other providers to increase the friction of switching to any other provider.

https://en.wikipedia.org/wiki/Embrace%2C_extend%2C_and_extin...

Yeah, but... given there are other ACME providers, why would I choose one from the a company with googles reputation for sunsetting products?

As a Let’s Encrypt user and fan, I can answer this.

LE is great, but their SLO is significantly below our customers’ expectations. For us, Google wouldn’t replace LE, it would supplement LE for higher reliability.

Seeing more providers conforming to ACME at a price point of “free” is great for the ecosystem.

Is this with provisioning many new certs?

The recommended renewal cycle gives you a 30 day lead on failure becoming a problem, plenty of time for multiple retries or recovery processes to use an alternate.

The only issues I've ran into, have stemmed from DNS for wildcard certs, where a client's DNS provider is... pretty crap about updating records despite low ttls being set.

It’s a web hosting business. New customers want effortless free TLS asap. We get customers who routinely create new sites who come to expect fast provisioning.

Some people on the cloud like to issue a certificate per machine, so no ACME = no new VMs.

Does Google Cloud also have that reputation? I've seen renames and well-motivated deprecations, but not the Google Graveyard kind of events.

"This API you use has changed, you have 6 months to update your code" is not unheard of.

On AWS, the equivalent is "We no longer recommend this, and it's not visible in the AWS console unless you are already using it or have asked support to enable it, but it will keep working indefinitely".

Its probably already worked into the hosting bill somehow anyway... There are numerous places to hide the cost in any CSP bill.

Even traditional host providers are raising their costs for the same mysterious reasons, although hardware costs are historically trending lower over time.

> hide the cost ...

That's one way to put it.

Solving your customer's problems and making it more likely they will keep using your main offering is another way to put it.