Our expert opinion on cloud.

Ik communiceer alleen met APIes

Geschreven door Christian van Barneveld op 7-mrt-2016 14:14:20
Volg mij op:

aapje.jpgJa, je leest het goed! Ik communiceer alleen nog maar met APIes. Daarbij bedoel ik niet die schattige beestjes zoals hiernaast. Hij geeft overigens wel mijn blik weer als ik wederom van een software leverancier of cloud (applicatie) provider te horen krijg: “een API? Die hebben we nog niet, maar staat wel op de roadmap!”. Op zo’n moment neem je automatisering niet serieus, want hoe wil je diverse applicaties automatiseren zonder API’s (Application Programming Interface)?

Mijn collega Bart schreef al over het automatiseren van de automatisering en API’s sluiten daar naadloos op aan. Juist die Type B automatiseerders zoeken als eerste naar een API: de IT-ers waarbij automatieren in het DNA zit. Ik betrap mijzelf er ook steeds vaker op dat als ik privé een nieuw apparaat koop dat ik er met een boog omheen loop als het niet over een API beschikt. Ik moet het toch aan mijn home management system kunnen koppelen?! Geen legacy meer in huize Van Barneveld! :-)

In de zakelijke IT is deze trend ook zichtbaar en met name als je met cloud diensten werkt. Integratie is daarbij één van de belangrijkste succesfactoren en dat bereik je niet met enkel (web) GUI’s. Automatiseren doe je met API's.

API First Strategy

pre-SOA.jpgBij Amazon wordt iedere dienst vanaf het eerste ontwerp voorzien van een API. Voor moderne (internet) bedrijven is een dergelijke ‘API First Strategy’ niet meer dan normaal.  Mobiele app ontwikkelaars gebruiken vervolgens weer massaal deze API’s bij de ontwikkeling van hun applicatie. Als je op die manier je diensten ontwikkeld dan weet je dat alle functionaliteit in de API aanwezig is. De Web GUI ontwikkelaars en andere sub-diensten gebruiken dan ook weer diezelfde API als die je aan de klanten aanbiedt. 

Maar wat doe je nu als je 10, of misschien wel 100, applicaties hebt, allemaal netjes voorzien van een API? Die ga je niet één voor één aan elkaar koppelen zoals voor het SOA/ESB-tijdperk zoals hiernaast weer gegeven het geval was. Dan creëer je weer één brei aan afhankelijkheden. Ook hoe je je eigen dienst en API weer aan je (externe) gebruikers gaat aanbieden is daarin een vraagstuk, want hoe doe je dat op een veilige manier?

ESB

SOA.jpgNou dan pak je de Enterprise Service Bus (ESB) uit de kast?! Grapje natuurlijk, maar wel even belangrijk om te weten waar dit legacy-component in het hele API verhaal thuis hoort, want 10 jaar geleden waren ESB en SOA de heilige graal. Daarmee kon je services ontwikkelen en via een ESB aan andere applicaties aanbieden. Dit leek de oplossing om de integraties en data uitwisseling tussen applicaties eenvoudiger te maken. Alleen bleek de realiteit toch wat complexer te zijn, waardoor het niet echt een succes is geworden. Ook de grote organisaties die wel een ESB hebben geïmplementeerd kijken naar nieuwe integratie mogelijkheden.

Want het is leuk dat alles een API heeft, maar hoe hou je dat onder controle als je applicatie landschap 10-tallen API’s gaat gebruiken? En stel dat externen van jouw API’s gebruik willen maken, hoe biedt je dat veilig aan? Daar komt de API Gateway en API Management om de hoek kijken.

API Management

De verschillende API Stakeholders willen inzicht hebben in de API Gateway zodat er proactief verbeterd kan worden. Zij hebben vragen als:

Developers:

  • Wat zijn het gedrag en de performance van de API’s die mijn applicatie gebruikt?
  • Treden er fouten op? Zo ja: welke? En hoe kan ik deze zo snel mogelijk oplossen?

(Product) Managers:

  • Hoe worden onze API’s gebruikt?
  • Wat mist er nog en wat kan er verbeterd worden?

IT Operations:

  • Wat is de response-tijd per API Request?
  • Moet ik meer resources bijplaatsen zodat er op piekmomenten geen vertraging optreed?

Daarom zijn metrics zo belangrijk, deze worden door de API Management Portal aan de verschillende doelgroepen aangeboden. Ook lifecycle management van API’s komt hier om de hoek kijken maar ook over rechten en rollen, daarover in mijn volgende blog meer.

API Gateway

past-SOA.jpgEen API Gateway biedt een centraal toegangspunt voor het beheren, bewaken en beveiligen van de toegang tot de web services die je zowel intern als extern wilt aanbieden. Voor de API-gebruikers lijkt het daarom of zij te maken hebben met slechts één host in plaats van diverse endpoints. Zo hoeven zij geen rekening te houden met eventuele wijzigingen van een host of dienst, zij communiceren alleen maar met api.bedrijf.nl ipv api.web1.dienst.bedrijf.nl. Je zorgt dat de aanroep voor de API gebruiker hetzelfde blijft, zo maak je de IT ook een stuk flexibeler en is het een maatregel om vendor lock-in te voorkomen en lifecycle management van je applicaties te ver-eenvoudigen. De ontwikkelaars gebruiken de developer portal om de API's te koppelen en te beheren. Zo heeft iedere doelgroep, die hierboven zijn eigen vragen had, een eigen interface om zijn API zaken te regelen en realtime in te zien. Ik ga hier in de volgende blog dieper op in.

Voor grote organisaties is gaat het ook niet direct over de vervanging voor hun Enterprise Service Bus, maar wel als aanvulling hierop waardoor ze op termijn die transitie wel mogelijk kunnen maken. Voor nieuwe ontwikkelingen, zoals microservices, biedt het wel direct de koppeling naar andere applicaties.

Meetup!

Meer weten over dit onderwerp of vind je het interessant om vanuit jouw ervaring hierover mee te praten? Weolcan gaat meetups organiseren over API Management met interessante sprekers zodat we de discussie op gang kunnen brengen en jou te helpen de selectiecriteria voor dergelijke oplossingen scherp te krijgen. Schrijf je in: 

http://www.meetup.com/API-Management-NL/

Ook is dit de eerste blog in een serie over API Management, dus schrijf je ook in op onze blog (rechts bovenaan deze pagina) om niets te missen!

Onderwerpen: API Management