Kun kolmannen osapuolen palvelut muuttuvat riskiksi

Jokainen kehittäjä tuntee tilanteen: löydät näppärän ulkoisen palvelun, integroit sen sovellukseesi, ja yhtäkkiä se on keskeinen osa käyttökokemusta. Sitten jossain vaiheessa palvelu vain katoaa.

Googlen hiljattainen ilmoitus Tenor API:n sulkemisesta on juuri tätä tilannetta suuressa mittakaavassa. Vuosien ajan Tenor toimi GIF-toiminnallisuuden selkärankana lukemattomissa viestisovelluksissa, sosiaalisissa alustoissa ja luovissa työkaluissa. Kehittäjät, jotka rakensivat GIF-valitsimia Tenorin infrastruktuurin päälle, kamppailevat nyt vaihtoehtojen löytämiseksi – tai pahimmillaan rakentavat kokonaisia toimintoja alusta alkaen uusiksi.

Mitä tämä tarkoittaa käytännössä

Vaikutukset ulottuvat paljon pidemmälle kuin yksittäisen ominaisuuden poistuminen. Kun rakennat jonkun toisen API:n varaan, teet käytännössä yhteistyötä, jossa hallitset vähemmän kuin luulet. Googlella on täysi oikeus lopettaa tuotteita, jotka eivät enää vastaa heidän liikestrategiaansa, mutta se ei tee jälkihoidosta yhtään helpompaa niille kehittäjille, jotka jäävät korjaamaan hajoavat palaset.

Näitä haasteita Tenoria käyttävät tiimit kohtaavat juuri nyt:

• Välitön siirtopaine — Käyttäjät odottavat GIF-toiminnallisuuden toimivan. Vaihtoehdon löytäminen ei ole vaihtoehto.
• Mahdolliset lisenssiongelmat — Vaihtoehtoiset palvelut kuten Giphy tuovat mukanaan omat ehdot, hinnoittelurakenteet ja API-rajoitukset.
• Kehitysajan tiukkuus — Mikä vaikutti yksinkertaiselta integroinnilta, on nyt kokonainen uudelleenrakennusprojekti.
• Käyttökokemuksen häiriöt — Ominaisuudet, joihin käyttäjät luottivat, voivat kadota tai käyttäytyä eri tavalla siirtymävaiheen aikana.

Laajempi opetus: riippuvuusriskin hallinta

Tämä tilanne korostaa periaatetta, jonka jokaisen kehitystiimin tulisi omaksua: kolmannen osapuolen API:t ovat käteviä siihen saakka, kunnes ne eivät enää ole.

Ennen kuin integroit minkä tahansa ulkoisen palvelun sovellukseesi, harkitse näitä kysymyksiä:

1. Kuinka vakaa tämä palvelu on? Onko palveluntarjoaja tehnyt yritysostoja, muuttanut suuntaa tai osoittanut merkkejä tuotteiden lopettamisesta?
2. Mikä on poistumisstrategia? Jos tämä palvelu katoaisi huomenna, kuinka nopeasti pystyisit siirtymään toiseen?
3. Onko tämä ydintoiminto vai lisäominaisuus? Mitä keskeisempi toiminnallisuus on, sitä enemmän sinun täytyy omistaa se tai olla varasuunnitelma valmiina.
4. Mikä on liiketoimintamalli? Palvelut, jotka luottavat epävarmoihin tulovirtoihin, eivät välttämättä ole enää olemassa silloin, kun tarvitset niitä eniten.

Kestävyyden rakentaminen

NameOceanilla puhumme paljon vankkojen perusteiden merkityksestä – oli kyse sitten domain-nimien rekisteröinnistä, DNS-asetusten konfiguroinnista tai hosting-infrastruktuurin pystyttämisestä. Sama periaate pätee tässäkin: palvelut, joiden varaan rakennat, tulisi antaa luottamusta, ei huolta.

Jos olet parhaillaan arvioimassa API-palveluja seuraavaan projektiisi, ota Tenor-tilanne case-esimerkiksi riippuvuusriskistä. Valitse palvelut, joiden takana on vakaita yhtiöitä selkeillä pitkän aikavälin sitoumuksilla. Rakenna abstraktiotasoja aina kun mahdollista, jotta et ole tiukasti kytketty yhteen palveluntarjoajaan. Ja aina, aina kannattaa olla varasuunnitelma.

Sovelluksen GIF-valitsin voi vaikuttaa pieneltä yksityiskohdalta, mutta kun se lakkaa toimimasta, käyttäjät huomaavat sen. Vielä tärkeämpää on, että luottamus, jonka olet rakentanut näiden käyttäjien kanssa, kärsii joka kerta kun ominaisuus, johon he luottavat, katoaa yllättäen.

Google jatkaa tuotevalikoimansa karsimista. Muut yhtiöt seuraavat perässä omilla lopetetuilla API-rajapinnoillaan. Kehittäjät, jotka selviävät näistä myrskyistä parhaiten, ovat niitä, jotka näkivät tulevan – ja suunnittelivat sen mukaisesti.

Onko Tenorin sulkeminen vaikuttanut projekteihisi? Jaa kokemuksesi kommenteissa. Ja jos etsit hostingia ja infrastruktuuria, joka asettaa vakauden etusijalle, NameOcean on sinua varten.