API’s zijn tegenwoordig de nieuwe grote ontwikkeling binnen IT-strategie en -architectuur. Ongeacht welke branche je bekijkt, digitaal zakendoen staat hoog op de agenda en API’s zijn een essentieel onderdeel van het digitale menu. Bij Yenlo genieten we van de positie die we hebben in de samenwerking met tal van bedrijven die API’s bouwen en API Management voor die API’s implementeren. Hoewel er genoeg verschillen zijn in de projecten waar we bij betrokken zijn, zijn er ook opvallende overeenkomsten. Overeenkomsten in het soort uitdagingen die bedrijven ervaren. En overeenkomsten in de groeiprocessen die deze bedrijven doormaken.
Uit al deze gevallen hebben we tot dusver vijf duidelijke fases van API adoption kunnen extraheren. Hoewel het kan verschillende hoever jij in het proces bent, willen we toch onze ervaring met je delen en hopelijk jouw API-initiatief de goede kant op sturen.
1e fase: Bewustwording van API’s
In de eerste fase van API-adoption worden API’s geïntroduceerd als een praktische methode om applicaties te integreren. Vaak zien we de noodzaak van integratie als eerste ontstaan met het oog op mobiele applicaties. In een mobile-first benadering worden API’s simpelweg opgesteld vanuit het User Experience Design, of het Human Interface Design zoals Apple heeft blijft noemen. In andere woorden: API’s zijn ontworpen om het leven van app ontwikkelaars makkelijker te maken. En omdat het webgecentreerde model van API’s goed lijkt te resoneren met het ontwikkelingsraamwerk voor mobiele apps is de drempel om API’s op te nemen relatief laag. In deze fase kun je verwachten dat jouw ontwikkelaars snel enthousiast worden: het nieuwe, simplistische programmeermodel voor procedures op afstand blijkt veel makkelijker dan de technologie waar ze aan gewend waren. Bovendien heeft de ontwikkelaar het gevoel de controle over de het hele integratietraject in handen te hebben, wat enorm ten goede komt aan de efficiëntie van de ontwikkeling. Het maakt het hele proces significant sneller, waar de eigenaren van het product op hun beurt blij mee zijn. En dus verspreid het virus zich snel, vooral onder teams die in de snel veranderende IT-wereld werken.
Fase 2: API Platformarchitectuur
Als de voordelen van API’s eenmaal goed bekend zijn, zullen waarschijnlijk de eerste bedenkingen de kop op steken, al was het maar omdat aanbieders hun API-technologieën aan je opdringen. De zorgen die in deze fase normaal gesproken de management agenda halen, gaan over de mogelijke risico’s van het gebruik van API’s, over kwaliteitscontrole voor API’s en hoe die API’s beheert kunnen worden op enterprise schaal.
API Managementproducten bieden door meerdere componenten antwoorden op deze bedenkingen. Een API-Gateway is de aanbevolen technologie om toegang tot API’s te beschermen. Het werkt als een proxy op applicatieniveau die een set beleidsregels oplegt. Dit beleid gaat over een aantal risico’s waar we mee te maken hebben, zoals toegangsbeperkingen en de bescherming tegen het overvragen van capaciteit. De eerste set aan beleidsregels geeft alleen toegang aan geïdentificeerde applicaties, die ontwikkeld zijn door vertrouwde ontwikkelaars en die hun eigen geldige abonnement aan jouw API kunnen tonen. Daarnaast kan er sprake zijn rechten voor gebruikers. Niet iedereen die de applicatie gebruikt zou hetzelfde ermee moeten kunnen. Rate limitation is een ander soort techniek die erop gericht is om client applicaties te beperken in het aantal keer dat ze de API aan kunnen roepen per tijdseenheid. Iedere volgende keer wordt uitgefilterd. Verder zijn er intelligentere beleidsregels die het aantal aanroepen van alle bronnen samen kunnen beperken. Uiteindelijk is dit de meest eenduidige aanpak in de bescherming van je back-endsystemen tegen een overflow van API-aanroepen.
Om dit allemaal te laten werken hoort beleid opgesteld (in een Policy Administration Point) en gepubliceerd te worden, en zullen API-abonnementen beheerd moeten worden. Daar zijn het API Publishing Portal en de API Developer Store voor bedoeld. Het is erg zinvol om een enkele Store te hebben voor alle API’s die aangeboden worden. Developers die API’s verslinden zullen dankbaar zijn als ze slechts een enkel punt hebben waar ze jouw API’s kunnen ontdekken, testen en zich erop kunnen abonneren.
Het opzetten van een systeem van gateways en portals kan heel vanzelfsprekend zijn. Maar vaak zal er echter aan allerlei soorten randvoorwaarden moeten worden voldaan. Denk aan vereisten op het gebied van prestatie, (wereldwijde) schaalbaarheid, beschikbaarheid, beheersbaarheid en veiligheid om er maar een paar te noemen. De API Management componenten moeten passen binnen een bestaande enterprise architectuur, inclusief onderdelen als een identity provider, een RDBMS, een analytics engine, een log aggregator en een health monitor. En als je meer dan één datacentrum hebt, in de cloud of op locatie, groeit de keuzevrijheid proportioneel. Het idee lijkt me duidelijk. Dus het is waarschijnlijk tijd om een aantal design workshops in te plannen met jouw architecten.
Het centraliseren is de eerste stap in API Management, met naamgevingsconventies en beleid voor life-cycle management als belangrijkste onderdelen. Hoe belangrijk het is om als bedrijf goed gemanaged en georganiseerd over te komen verschilt per bedrijf, maar zonder de rijkdom van goede standaarden en de handhaving ervan kan slechts een enkeling.
Fase 3: Kernprocessen van API Management
Een benadering waar we meestal mee te maken krijgen is, dat er een snelle start wordt gemaakt met adopteren van alleen de ‘out-of-the-box‘ API Management functionaliteiten, een minimaal levensvatbare API Management configuratie, en pas later gedacht wordt aan opschaling, maatwerk en fine-tuning. Deze veranderingen hebben niet direct invloed op je algehele architectuur, maar het zou de ‘look’ en ‘feel’ of zelfs de functionaliteit van je portalen kunnen beïnvloeden.
Developer engagement begint meer en meer aandacht te krijgen. Bijvoorbeeld door samenwerking tussen API-aanbieders en consumenten te promoten door het over grenzen en taalbarrières heen te tillen. Wat zijn de beste methodes voor documentatie? Hoe kunnen API’s geclassificeerd worden? Hoe bouwen en onderhouden we consistentie tussen API’s? Het vinden van de juiste antwoorden op die vragen is vaak een gecompliceerde puzzel.
Een ander interessegebied is het managementproces dat ontwikkelaars in jouw Store ondersteund. Out-of-the-box worden dit soort processen eenvoudig door de manager zelf beheerd. In bepaalde gevallen zou dit afdoende kunnen zijn. Maar veelal merken we dat bedrijven of bedrijfsunits die hun API’s aanbieden toch wat controle willen houden over de ontwikkelaars die ze implementeren. Dit kan variëren van het verifiëren van een e-mailadres, waar wellicht alle adressen van buiten het bedrijf uitgefilterd worden, tot een uitgebreide screening van ontwikkelaars en hun organisaties, tot zelfs een grondig onderzoek van de applicaties die zij ontwikkelen.
WSO2 API Manager geeft je de vrijheid om jouw eigen processen volledig zelf te bepalen in de voor jou gewenste workflow, of systeem voor zakelijk proces- of casusbeheer. En als je niet over zo’n systeem beschikt, of je wil er niet meer in wilt investeren, wees dan gerust, want de WSO2 Business Process Server is een geweldige keus en klaart de klus voor u.
Fase 4: Praktijken van gevorderd API Management
Het aantal API’s, het aantal ontwikkelaars waar je contact mee hebt en het aantal aanroepen dat je verwerkt zullen na verloop van tijd groeien. Dat is goed, want je zaak loopt op rolletjes.
Om je groeiende business bij te blijven, word je meer en meer afhankelijk van je API Analytics dashboard. Je wilt bottlenecks vroegtijdig ontdekken en ze het liefst oplossen op het moment dat ze ontstaan. Instant op- en afschalen van je API-gateways is een steeds gebruikelijkere benadering. Het goede nieuws is dat jouw geavanceerde API-Analytics het ideale systeem is om de gezondheid van je system te checken en het op- en afschalen kan initiëren. Bovendien kan het ook, intentioneel of niet, ongewenst gebruik van je API’s monitoren en daar adequaat op reageren door rates per ontwikkelaar, applicatie of IP-adres dynamisch te beperken. Of je kunt een API-abonnementen intrekken of een IP-adres voor goed op de zwarte lijst zetten. Jij hebt de controle over jouw platform. En het fijne is dat je niet persoonlijk in hoeft te grijpen als jouw beleid overtreden wordt.
Eerlijk gezegd is het grootste deel van dit geavanceerde contra-beleid ontstaan als reactie op een of ander incident. Dat weerspiegelt mooi de door ons aanbevolen gang van zaken: verspil niet te veel tijd aan het verzinnen van verschrikkelijke scenario’s, maar monitor liever je systemen nauwkeurig, evalueer ieder incident strijdlustig en reageer adequaat, zodat er geen mogelijkheid op herhaling bestaat. In andere woorden, reageer snel en repareer wat kapotgaat onderweg. En laat geen enkele kans liggen om te leren en te verbeteren.
Verdienmodellen is een ander thema wat bij de meer ervaren API-enterprises speelt. Met verdienmodellen voor je API’s wordt de nauwe betrokkenheid van ontwikkelaars steeds belangrijker. Jouw API Developer Store is nu een portaal geworden om meer klanten in te verleiden en ze continu tevreden te houden. Daarom wil je statistieken in kunnen zien over hun gebruik van API’s en over je eigen serviceniveaus. Maar het allerbelangrijkste is het meten van gebruikersgegevens in overeenstemming met je prijsschema’s. WSO2 API Manager Analytics is gemaakt om je daarbij te helpen.
Fase 5: API-first-strategie
In de vijfde, en momenteel laatste fase, wordt het voor enterprises duidelijk dat de realisatie die zo goed werkt voor front-endintegratie net zo goed zou kunnen werken voor de back-endintegratie. De traditionele SOA-integratie inspanningen worden afgedaan als onnodig omslachtig, teleurstellend inefficiënt en onvoldoende afgestemd op de flexibele praktijken van de hedendaagse ontwikkelingen. API’s worden langzaamaan de voertaal voor enterprise integratie.
Om een API-first-strategie te kunnen gebruiken, dienen er een aantal dingen geregeld zijn. Als eerste moet je API Gateway het enige point-of-entry voor je diensten worden. Alleen dan kun je vertrouwen dat je beleidshandhaving op dat punt daadwerkelijk je diensten beschermd tegen alle gevallen waarin beleidsovertredingen voorkomen. Geen excuses meer, maar alle servicecalls via jouw API Gateway. En alle aanroepen van diensten moeten actief gemonitord worden en onderhevig zijn aan gemanaged beleid. Zonder uitzondering.
Ten tweede zal je benadering van integratie op z’n kop moeten. Jouw service consumer teams hoeven niet langer te wachten op de integratiegroep om hun magische truc te doen en dan achteraf te denken dat de service interface nog veel beter had gekund. In een API-first-benadering begin je bij het vooraf definiëren van jouw API en ga je eenvoudigweg jouw stubs en clients genereren, zodat jouw teams direct kunnen gaan experimenteren en verbeteren. En alleen als je zeker weet dat een API goed gedefinieerd is, dan pas ga je bouwen aan je service providers en je klanten bedienen. Je kunt dat parallel doen, omdat de integratie al gevalideerd en geverifieerd is. In termen van efficiëntiewinst is dit waarschijnlijk de grootste boost die je van een API Managementinitiatief kunt verwachten.
Laatste opmerkingen
Het API-tijdperk is nog jong en ontwikkelt zich snel. Als gevolg daarvan is het nog volledig onzeker of deze vijfde fase echt de laatste fase zal zijn. Als de voorspellingen kloppen dan blijft het voorlopig nog spannend in de integratiewereld. In ieder geval kun je van ons verwachten dat wij je op de hoogte houden van alle ontdekkingen.
Waar zit jij op dit moment in jouw API-adoption? Nog in de eerste fases, of loop je voorop? Misschien ben je de vijfde fase al voorbij? We horen graag van je in het commentaar hieronder. Als je met vragen zit over hoe je iets slimmer met API’s kunt omgaan? Aarzel dan niet om direct contact met ons op te nemen. Als je ons toestaat begeleiden we je graag op jouw reis door de API adoption.
