Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deactivating an API, one step at a time

apichangelog.substack.com

Post reply on HN
Print view View original

11–20 of 60 posts

Re: Deactivating an API, one step at a time

#11

Post by croemer »

athenot wrote: post #10

Other strategies that could come in handy before completely shutting down the API: - Rate-limit the API, with increasing aggressiveness until you're down to 0 requests per unit of time; - Introduce latency in serving the requests (assuming your edge can handle the increased volume of open connections). Both of these introduce gradual degradation of the old API, without outright killing the business functionality that…

I think GitHub actions cause errors for a few minutes to alert, one could do that also with an API.

Re: Deactivating an API, one step at a time

#12

Post by its_ethan »

It would be really cool to see a graph of the API usage over time with markers showing when each "stage" was occurring. I'm wondering if there were significant dips shortly after each stage, or if it was more of a gradual decline?

It would also be interesting to know if the API was still being used up until the final stage? Were there any ramifications/ angry customers at the door after that?

Re: Deactivating an API, one step at a time

#13

Post by bogdan-lab »

Joel_Mckay wrote: post #6
pocketarc wrote: post #2

Something that can be extremely useful as well in situations like this, is doing API brownouts, toward the later stages of the process. Disable the API for short stretches of time, on the way to disabling it entirely, to give consumers who might not be keeping up with changes a way to be alerted (they'll notice the downtime).

Or instead of losing paying customers: 1. design API accounts to include a preferred server and default server (handy to explicitly load balance, or dynamically bounce users to specified servers.) 2. design clients to have a timed service lifecycle (expiry 2 weeks prior to cert expiry). Then enter a semi-dormant mode until valid signed updates succeed. 3. add a random timed daily update check, and begin reassigning t…

Yes, I completely agree. The story sounds like fairytale: migration was announced to happen in 3 months and in 4 months it was done by removing old API.

Where are all those clients, who are happy with current API performance and do not want to spend their money on making API owners life better? What happened to them? Did the company just decide to let those clients go?

Re: Deactivating an API, one step at a time

#14

Post by Suppafly »

athenot wrote: post #10

Other strategies that could come in handy before completely shutting down the API: - Rate-limit the API, with increasing aggressiveness until you're down to 0 requests per unit of time; - Introduce latency in serving the requests (assuming your edge can handle the increased volume of open connections). Both of these introduce gradual degradation of the old API, without outright killing the business functionality that…

Man I really hate the idea of "Let's make a thing that works shittier so that people switch to the new thing". If you're in a situation where you have customer's just be honest about the changes coming and give them enough runway to get the changes made.

Re: Deactivating an API, one step at a time

#15

Post by Joel_Mckay »

bogdan-lab wrote: post #13
Joel_Mckay wrote: post #6

Earlier quoted context omitted.

Or instead of losing paying customers: 1. design API accounts to include a preferred server and default server (handy to explicitly load balance, or dynamically bounce users to specified servers.) 2. design clients to have a timed service lifecycle (expiry 2 weeks prior to cert expiry). Then enter a semi-dormant mode until valid signed updates succeed. 3. add a random timed daily update check, and begin reassigning t…

Yes, I completely agree. The story sounds like fairytale: migration was announced to happen in 3 months and in 4 months it was done by removing old API. Where are all those clients, who are happy with current API performance and do not want to spend their money on making API owners life better? What happened to them? Did the company just decide to let those clients go?

Collecting clients other people hosed is an easy business. Except, entrenched incompetence may still pine for the convenience of a quick sometimes-broken kludge (some folks expect everything to be glitched half the time).

I definitely understand why some techs just stop caring about customer opinions. You'll know when you are in a senior role when one starts to fantasize about being a Plumber. =3

Re: Deactivating an API, one step at a time

#16

Post by beachy »

Suppafly wrote: post #14
athenot wrote: post #10

Other strategies that could come in handy before completely shutting down the API: - Rate-limit the API, with increasing aggressiveness until you're down to 0 requests per unit of time; - Introduce latency in serving the requests (assuming your edge can handle the increased volume of open connections). Both of these introduce gradual degradation of the old API, without outright killing the business functionality that…

Man I really hate the idea of "Let's make a thing that works shittier so that people switch to the new thing". If you're in a situation where you have customer's just be honest about the changes coming and give them enough runway to get the changes made.

Yep. If you gradually degrade performance, and word of your intentions fails to make it to the right people, the victim may well have to devote significant effort to trying to work out what's going on. Boy will they be pissed when they find out.

Re: Deactivating an API, one step at a time

#17

Post by bongodongobob »

beachy wrote: post #16
Suppafly wrote: post #14

Earlier quoted context omitted.

Man I really hate the idea of "Let's make a thing that works shittier so that people switch to the new thing". If you're in a situation where you have customer's just be honest about the changes coming and give them enough runway to get the changes made.

Yep. If you gradually degrade performance, and word of your intentions fails to make it to the right people, the victim may well have to devote significant effort to trying to work out what's going on. Boy will they be pissed when they find out.

This is standard practice though. You can only communicate it so much. If your customers ignore it, that's on them. You either have a hard cutoff date or you introduce failures or throttling. The latter is friendlier.

Re: Deactivating an API, one step at a time

#18

Post by n4r9 »

michaelt wrote: post #3

> It might be that you want to replace it with a new, more capable version If you're truly replacing your API with a new, more capable version there's a much better option, in my experience. Roll out your new API, and replace your old API's implementation with a proxy that calls through to the new API. The proxy will need very little maintenance, as all it's doing is connecting one fixed, stable API (your old one) to…

What if the new API is more capable precisely because the parameters have been completely redesigned?

Re: Deactivating an API, one step at a time

#19

Post by bongodongobob »

Suppafly wrote: post #14
athenot wrote: post #10

Other strategies that could come in handy before completely shutting down the API: - Rate-limit the API, with increasing aggressiveness until you're down to 0 requests per unit of time; - Introduce latency in serving the requests (assuming your edge can handle the increased volume of open connections). Both of these introduce gradual degradation of the old API, without outright killing the business functionality that…

Man I really hate the idea of "Let's make a thing that works shittier so that people switch to the new thing". If you're in a situation where you have customer's just be honest about the changes coming and give them enough runway to get the changes made.

Yeah you do that and you'll still have customers that ignore it. That's why you have to slowly degrade it at a communicated point in time. You're not being sneaky about it, it's planned. It's that or you dedicate a ton of manpower to hold everyone's hand for a hard cutoff which will always be painful.

Re: Deactivating an API, one step at a time

#20

Post by cinntaile »

n4r9 wrote: post #18
michaelt wrote: post #3

> It might be that you want to replace it with a new, more capable version If you're truly replacing your API with a new, more capable version there's a much better option, in my experience. Roll out your new API, and replace your old API's implementation with a proxy that calls through to the new API. The proxy will need very little maintenance, as all it's doing is connecting one fixed, stable API (your old one) to…

What if the new API is more capable precisely because the parameters have been completely redesigned?

Surely you can keep it backwards compatible AND give people access to the new good stuff?
Post reply on HN