Als jeje bezig houdt met vraagstukken rond cloud computing en mobiele toegang, ben je vast al wel op de term 'api-management' gestuit. Zo niet, dan wordt het nu tijd om je er in te gaan verdiepen. Het vormt namelijk een cruciaal onderdeel van het hybride of mobiele platform.
Allereerst is het van belang om de term ‘api’ in deze context uit te leggen. Api, of application programming interface, is een oude term. En nu ik hem hier uitschrijf, ook een term die eigenlijk de lading niet meer dekt. Want wat is een applicatie eigenlijk nog tegenwoordig? Bestaat dat nog wel? In de moderne it betekent api dus eigenlijk ook niets meer dan de interface van een webservice. Deze webservice is meestal op SOAP, maar meer en meer op REST gebaseerd. En deze service biedt een stukje (black-box) functionaliteit. En die service kan, als hij volgens de juiste principes is ontwikkeld, op vele manieren en dus in vele contexten gebruikt worden.
Architectuurprincipes
De trend is dat leveranciers van standaard ‘applicaties’ deze geschikt hebben gemaakt om als dienst af te nemen in de vorm van SaaS-oplossingen. Vaak worden de belangrijkste functionaliteiten in die SaaS-oplossingen ontsloten als api’s. Dit zijn dan de zogenaamde publieke api’s en deze zijn eigenlijk altijd gebaseerd op webservices. En deze zijn meestal RESTful tegenwoordig, omdat dat lekker eenvoudig is en niet te veel last van overhead heeft. De SaaS-oplossingen zelf gebruiken deze interfaces intern meestal ook, want dan is alles lekker los gekoppeld. In het diepste geheim hebben de cloudleveranciers je kennelijk toch nog soa door je strot geduwd, alleen noemen ze het niet meer zo. Maar de architectuurprincipes worden wel degelijk gevolgd. En dat is maar goed ook.
Echter, in een soa of op api’s gebaseerde architectuur, waar een set van services in een bepaalde, configureerbare volgorde worden aangeroepen om op die manier een (deel van een) bedrijfsproces te automatiseren is governance onontbeerlijk. Anders noemen we het ‘jabows’ (just a bunch of web services). In de ’traditionele’ soa-omgevingen is run- en designtime soa-governance redelijk ingeburgerd. In de moderne, op api’s gebaseerde cloud- en mobiele wereld is dit echter nog niet echt het geval. Api’s worden lekker als spaghetti ontsloten en geconsumeerd. Daar is een groot slabbertje bij nodig. Tijd voor de volgende stap in volwassenheid dus.
Gartner heeft zowel soa-governance als api-management in de categorie Application Services Governance geplaatst. En hier is vanzelfsprekend ook een Magic Quadrant voor. Ik voorzie dan ook dat de leveranciers die of uit de soa-governance-hoek komen of uit de api-management-hoek in deze categorie naar elkaar toe zullen groeien en dat er uiteindelijk gewoon over ASG of iets dergelijks wordt gesproken waarin de functionaliteiten (die grotendeels overlappen) bij elkaar zijn gekomen.
Om even de focus op api-management te houden: het mooie is dat je hiermee jouw (legacy) on-premises api’s mooi kunt ontsluiten via de cloud richting mobiele apps en andere interne en externe consumenten. Maar dan wel met in achtneming van veiligheidsaspecten, monitorbaarheid en schaalbaarheid. Want api-management draait onder andere om de volgende zaken:
- Servicevirtualisatie – je kunt een virtuele service aanbieden met bijvoorbeeld functies als ‘geef lijst van artikelen’ en ‘plaats order’, die in je on-premises omgeving door totaal verschillende applicaties worden ingevuld.
- Protocolconversie – jouw op SOAP gebaseerde on-premises functies kunnen bijvoorbeeld als RESTful service worden ontsloten richting consumenten.
- Fijnmaziger security – je kunt deze virtuele services dus veel fijnmaziger beveiligen, door alleen die functies richting bepaalde apps of klanten te ontsluiten die alleen voor hen van belang zijn en waar men alleen met het juiste certificaat bij kan. De rest is afgesloten.
- Schaalbaarheid en performance – api-management kan ook voor jou cachen en de load afstemmen op de capaciteiten van de achterliggende services.
- Runtime monitoring en governance – de runtime-aanroep van de diensten wordt bijgehouden, zodat je precies weet welke service wanneer en hoe vaak is aangeroepen en door wie.
- Designtime governance – jouw api’s kunnen in de catalogus worden opgenomen, inclusief hun beschrijving, en dus voor hergebruik gemakkelijk gevonden worden.
Door api-management in te zetten kun je dus in één klap jouw on-premises of andere (maatwerk)systemen op een moderne, veilige, beheersbare en schaalbare manier ontsluiten richting de cloud en daarmee apps en andere moderne manieren van informatie consumeren en produceren mogelijk maken. Je eigen veilige facade in de cloud.
Ik kan me in je artikel vinden, relevant en actueel.
Mis wel een belangrijke en dat is standaardisatie. Hoe manage je dat calls consistent zijn en bijvoorbeeld goed intuïtief aansluiten bij ontwikkelaars door naamgeving en werking (request / response) voorspelbaar te houden. Vaak ontstaand webservices uit vanuit een simpel concept, maar hoe zorg je ervoor dat tijdens de lifecycle de consistentie toeneemt en naar elkaar toe groeit?
Ook deployment en changes zijn belangrijke aspecten van API management. Hoe ga je om met versies, verbeteringen en continy improvement. Juist deze tak van sport leent zich daar goed voor.
Daarnaast mis ik nog een belangrijke sleutelspeler in dit geheel: Identity en Access Management (IAM). Goede API’s sluiten aan bij reguliere IAM’s. Door dit goed in de klauw te houden krijgen je API’s vleugels door hoge adoptie graad.
Al met al is het niet alleen een technisch feestje, maar juist ook een organisatorische. Juist door het loosly coupled karakter van webservices ligt chaos op de loer, de voedingsbodem van legacy 🙂
Gijs,
Leuk artikel!
We hebben dankzij de mogelijkheden van internet en cloud, te maken met een berg van api`s. Wil je voor je business van de voordelen van API`s gebruik maken dan moet je aan nog meer andere zaken denken dan alleen api-management:
– Creëer een online-strategie en leg in je business case uit hoe en wat je met deze wilt bereiken,
– Zet een “online-team” op,
– Creëer een API ontwerpstrategie,
– Bedenk een API management/ API beheeroplossing,
– Denk aan beveiliging, eenvoud, verdere ontwikkeling en kwaliteit van je API`s (slecht gemaakte API`s worden niet geaccepteerd door ontwikkelaars)
Kortom, in deze tijd kun je best je product via online-kanalen verkopen. Daarvoor moet je eerst eea goed op papier zetten en er ook een organisatie voor opzetten.
Leuk artikel en na DWaaS was het natuurlijk wachten op de APIMaaS waarbij hergebruik van API’s een goed idee is. Alleen heb ik wel wat twijfels over de governance want voor je het weet heb je een herhaling van openSSL doordat ook makkelijk fouten op grote schaal gekopieerd kunnen worden.
Interessant en relevant artikel. Zeker nu software stacks het ontzettend eenvoudig maken een nieuwe RESTful interface (of WebAPI) te realiseren. Het risico op wildgroei is duidelijk aanwezig. Een beetje Rich Internet Application introduceert zo een aantal API’s. En het is maar de vraag of de organisatie zich dat beseft en of die services wel voldoen.
Maar hoe erg is dat nu precies? De behoefte aan informatie van gebruikende systemen is van nature divers. Van online bevragingen tot reguliere synchronisatie, er is een wereld van verschillende interacties denkbaar. Wil je die met een beperkte set aan API’s/services beantwoorden dan krijg je complexe services. In je SOA-landschap is dat voor je core services nog te verantwoorden, maar voor API’s, die vaak gericht zijn op specifiekere use cases en gebruikersgroepen (zoals jij ook benoemd) is dat eerder belemmerend dan dat het waarde toevoegt.
De onderwerpen van API Management die je noemt, zijn wel de dingen waar we ooit een ESB voor wilden. Krijgen we nu een CSB, een Cloud Service Bus? En is zo’n technische oplossing niet symptoombestrijding van een organisatorisch probleem?
Bedankt voor alle feedback tot nu toe. Ben blij dat het onderwerp een beetje leeft.
IAM is inderdaad een belangrijk onderwerp. Voorzien we dat dat een apart iets blijft? Speelt API management hier alleen een rol als “consument” van IAM diensten? Of is er ook een rol weggelegd om IAM juist te federeren? Ik overzie dat nog niet zo op dit moment.
ESB is ook een leuke discussie.
Je ziet nu al dat verschillende vendors wat grenzen “overschrijden” door bijvoorbeeld transformatie (berichtstructuur) en bijna zelfs orkestratie (service compositie als ultieme virtualisatie)toe te voegen.
Een middle man aanpak zal hoe dan ook onontbeerlijk zijn in een steeds complexer wordend IT landschap. In hoeverre dit allemaal door de cloud leveranciers in het platform (PaaS) wordt geduwd is afwachten geblazen.
Het eco systeem met de beste adoptie van IAM zal wellicht het grootst worden.
DE IAM die dominant wordt zal de wereld regeren.
Mooist zou zijn als er een IAM standaard zou komen, dan kan het lekker ge-open-sourced worden en kan ieder zijn eigen smaak gebruiken.
Reken maar dat de PaaS leveranciers IAM top-of-mind hebben.
MS Hoopt erop dat ze met AD-smaak leading worden, ik twijfel eraan. Architectuur van AD is te complex en bevat teveel legacy van voor het cloud tijdperk.
@Redactie – LOL, ik moest het toch even proberen, maar je kan dus je eigen artikel beoordelen. Heb het nog bescheiden gedaan, maar ik sta nu wel iets hoger in de ranking op de voorpagina 😉
Gijs, Sssst! En je hebt het bescheiden gedaan? Je hebt je artikel geen vijf sterren gegeven?
@Henri: tsja, ik heb m’n gemiddelde maar met .3 opgekrikt. Ik leg de lat erg hoog voor mezelf en ben te eerlijk 😉
Het kunnen beoordelen van je eigen artikelen is nu opgelost merkte ik. Mooi!