Deactivating an API, one step at a time
apichangelog.substack.com
Deactivating an API, one step at a time
1–10 of 60 posts
Re: Deactivating an API, one step at a time
#2Something 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).
Re: Deactivating an API, one step at a time
#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 another fixed, stable API (your new one). Lock it down to only your old customers, if you want.
The support costs will be basically zero, and your existing paying customers will thank you for respecting their time with a dependable, low-churn API.
Re: Deactivating an API, one step at a time
#4Something 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).
I really like the API brownouts trick. GitHub have been doing this for years, a few examples:
- https://developer.github.com/changes/2018-11-05-github-servi...
- https://github.blog/changelog/2021-08-10-brownout-notice-api...
Re: Deactivating an API, one step at a time
#5Something 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).
I was thinking about this kind of thing. Another idea might be to introduce artificial latency and gradually increase it over time? Maybe dial up rate-limiting? I'm not really sure if this is a better or worse idea, though.
Re: Deactivating an API, one step at a time
#6Something 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 the users to the new API after updates install properly. Also, warn users the migration will happen 2 months before it is set to launch (do a few random A/B tests the first day).
4. Never rely on people to act, or not act for keeping infrastructure running. You are not going to be able to manually update 30000 legacy hosts with a single team. Worst case scenario you must auto-reconfigure the clients for a standalone offline mode... so the next user of the IP doesn't get hammered by failed connection retry attempts.
Brownouts won't work for cached-edge systems designed to reconcile month long intermittent outages. i.e. systems that were designed to handle DDoS, worms, and acts of clod...
Have a nice day, =3
Re: Deactivating an API, one step at a time
#7Something 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).
I was thinking about this kind of thing. Another idea might be to introduce artificial latency and gradually increase it over time? Maybe dial up rate-limiting? I'm not really sure if this is a better or worse idea, though.
That is a good idea, but I don't think it does enough to serve the purpose - the point of brownouts is to trigger their error/alert system. If the API is just being slower than usual, it won't trigger anything. Even if a human was reviewing it manually (which is quite unlikely), they would only think "oh, their API's really getting slower these days, sad".
There'd be nothing that indicates "The API is going to get shut down in a month and I need to move off of it ASAP!". Random, intermittent API failures would lead you to go check the API status out, and in the process you'd find out "oh, this API is going away".
Edit: On the point of rate limiting, I think the problem with it is that it'll affect everyone using the API all the time, not just during the brownout period. It effectively shuts the API down for everyone still using it (if the rate limit is too low, and if it isn't, then it won't be noticed by low-use consumers).
Re: Deactivating an API, one step at a time
#8Earlier quoted context omitted.
I was thinking about this kind of thing. Another idea might be to introduce artificial latency and gradually increase it over time? Maybe dial up rate-limiting? I'm not really sure if this is a better or worse idea, though.
That is a good idea, but I don't think it does enough to serve the purpose - the point of brownouts is to trigger their error/alert system. If the API is just being slower than usual, it won't trigger anything. Even if a human was reviewing it manually (which is quite unlikely), they would only think "oh, their API's really getting slower these days, sad". There'd be nothing that indicates "The API is going to get sh…
Hey, some of us look at P95 latency.
Re: Deactivating an API, one step at a time
#9> In addition to offering human-understandable communication, I asked the API producer to add the Deprecation HTTP header field to all responses
Cute, but, I question the value
Re: Deactivating an API, one step at a time
#10Other 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 recalcitrant customers are nevertheless reliant upon. It helps spur a bit of urgency to switch to the new API, while remaining nice. Many (enterprise) customers will wait until the last minute to switch: essentially they are having to put in work without any tangible feature gain—at least from their perspective.
Regardless of the strategy, one other point I'd add is to monitor actual use of the API; if important customers are still actively using the old API, it would be unwise to shut it off.