We staan op het punt om een tijdperk in te gaan waarin computing massaal gedistribueerd gaat worden. Ja, het is waar dat we al aan het aftasten waren toen we begonnen met CORBA en Client Server. Maar alles lijkt in een stroomversnelling te komen. Miljarden mobiele apparaten staan in verbinding met het internet en dat blijft groeien. Een stijgend percentage auto’s en vrachtwagens heeft een continue verbinding. Dingen raken steeds meer verbonden. Maar, en dat is het belangrijkste, organisaties worden slimmer in het onderling verbindingen leggen. Business integratie begint van de grond te komen.
Diepgaande samenwerking binnen een web aan waarden opent een wereld aan mogelijkheden om samen zaken te doen. Van co-marketing tot co-creatie en co-productie tot co-service. Geïntegreerde zorg is wellicht ook mogelijk. Of gezamenlijke operaties. Onderling verbonden systemen zijn de belangrijkste drijfveer in deze veranderingen. Maar hoe kan jouw IT-ontwerp dit volledig ondersteunen? Hoe kun jij slimmere manieren van werken stimuleren? En hoe kun jij de voordelen plukken van de massaal gedistribueerde computertechnologie?
Design begint bij de API
Wie houdt er niet van API’s? Conceptueel gezien zijn ze erg eenvoudig. Dankzij de Open API Specification, die alom geaccepteerd wordt, is het super makkelijk geworden om applicatie interfaces op een precieze, consistente en duidelijke manier te definiëren en te documenteren. En er zijn geweldige tools te krijgen om API’s te publiceren, ontdekken en te testen. Aan de eerste voorwaarde voor een succesvolle implementatie van massaal gedistribueerde systemen is daarmee ruimschoots voldaan. Daarnaast zijn er tools die de toegang tot API’s veilig managen – een andere voorwaarde waaraan de WSO2 API Manager keurig voldoet.
Dat was al een mooie introductie, maar waar leidt dit toe? Denk even mee. Als het begrip van een ontwikkelaar over gedistribueerde systemen begint op het niveau van API’s, zoals het hoort, zou API-design dan niet direct ook het startpunt moeten zijn voor de architect? Maar natuurlijk zou het zo moeten zijn! Er bestaat geen betere manier om een gedistribueerd systeem te ontwerpen dan vanuit de interfaces. Als je de interfaces goed doordacht aanpakt, heb je alle componenten en de manier waarop zij informatie uitwisselen goed op een rijtje. Welke input wordt er waar verwacht en welke output ontstaat er? Welke foutvoorwaarden zouden er nodig zijn? Impliciet kun je de verantwoordelijkheden afbakenen en de benodigde middelen identificeren. Dat is architectuur op zijn best.
In veel gevallen heb je al je gegevensbronnen en diensten beschikbaar om mee te beginnen. Met de juiste technologie kun je jouw API’s tot leven laten komen vanaf de allereerste ontwerpfases. Dat is een krachtige aanpak. Als alternatief zou je jouw API’s met een simpel inline script als prototype kunnen testen. Het vroeg testen kan beginnen.
Ontwerpen met veiligheid op de eerste plaats
Maar wacht eens, er is nog meer. In de hedendaagse wereld zul je altijd moeten ontwerpen met veiligheid in het achterhoofd. Het is fijn als jouw diensten informatie gemakkelijk kunnen uitwisselen, maar dat is niet altijd nodig. Informatie zou gevoelig of zelfs vertrouwelijk kunnen zijn, of misschien alleen geschikt voor bepaald gebruik. Er zouden mogelijk privacybeperkingen in het spel kunnen zijn. Of intellectuele eigendomsrechten. Handelsgeheimen wellicht.
Nogmaals, API’s zijn je beste vrienden. Het is een goede gewoonte om toegang tot API’s te beperken tot aangewezen ontwikkelaars. In de lijn van de veiligheid is toegang altijd ontzegd, tenzij expliciet gegeven. Dus aan wie geef jij toegang tot jouw API? Er is geen beter moment om jouw publiek vast te leggen dan op het moment dat je jouw API bedenkt. Om dat nog een stap verder te trekken, zul je over toegang moeten nadenken op method-niveau. Misschien hoeven bepaalde methoden alleen beschikbaar te zijn voor bepaalde ontwikkelaars. Of misschien kun toegang tot bepaalde groepen runtime users beperken. Het is hoe dan ook een goede gewoonte om altijd de scope voor een methode vast te leggen. Nogmaals, zelfs als de scope ‘iedereen’ is, hoort dit een expliciet besluit te zijn. Voor een diepere duik in API-security, kun je onze blog over intrinsiek veilige API’s lezen of hier uitgebreidere informatie vinden over een API Security Platform.
Op bepaalde momenten komt het met autorisatielogica net iets preciezer. Dat is wanneer toegang tot een bepaalde methode op voorwaarden berust. Het zou kunnen dat verschillende typen voorwaarden verplicht moeten worden gesteld. Bijvoorbeeld: Je hebt toestemming om een transactie uit te voeren, gegeven dat je aan strikte voorwaarden voldoet. Of gegeven dat je toegang vraagt vanuit een specifieke locatie. Dit zijn gevallen waarin adaptieve authenticatie benodigd is. Er zou ook sprake kunnen zijn van een bepaalde zakelijke logica. Je hebt alleen het recht om alcoholische dranken te bestellen alleen als je ouder bent dan 18. Je hebt alleen het recht een medisch dossier in te zien als het om jouw patiënt gaat. Gelukkig geeft de WSO2 API Manager je de mogelijkheid om zulke slimme beleidsmaatregelen al op interfaceniveau in te stellen.
Een sterk design komt met hoge mate van veiligheid en API’s maken dat gemakkelijker.
Van theorie naar praktijk
Je zou ondertussen niet alleen overtuigd, maar zelfs super gemotiveerd moeten zijn om je design vanuit API’s te ontwikkelen. Maar dan moet je wel de technologie hebben om ermee te kunnen spelen. Omdat je waarschijnlijk niet zit te ontwerpen in een ivoren toren, is het waarschijnlijk zo dat je samenwerkt met mensen binnen en buiten je team. Dat vraagt om nog meer technologie. En als je geluk hebt dat jij wel toegang hebt tot gepaste technologie, dan is dat misschien nog niet het geval voor iedereen in jouw team en daaromheen.
Een van de grootste voordelen van Yenlo Connext is dat het een rijke integratie- en samenwerkingstechnologie biedt voor alle betrokkenen. We begrijpen dat technologie ondersteunend moet zijn en kansen moeten genereren, maar daarbij geen beperkingen mag opleveren. Met Connext heb je een platform om API’s te ontwerpen, inclusief het bijbehorende beleid, en kun je ze vanaf dag één testen. Dat allemaal dankzij de geweldige WSO2 API Manager. Identiteits- en Rechtenbeheer wordt volledig gedekt met de WSO2 Identity Server. Je kunt jouw API’s met een paar muisklikken tot leven laten komen in de WSO2 Developer Studio met hulp van de WSO2 ESB. Er is zo ongelofelijk veel om uit te kiezen. We hebben zelfs een wiki en projecttracking ingebouwd om flexibele werkwijzen te ondersteunen.
Wist je dat je SDK’s voor je API’s kunt genereren met slecht één druk op de knop? Yenlo Connext ondersteunt tal van talen en raamwerken, zoals Android, Angular, Go, Python, Perl, en Swift. U kont zelfs een server stub aanmaken in o.a. ASP.Net, Java, Spring, NodeJS en Ruby.
Dat is hoe wij jouw integratieprocessen een boost geven, ongeacht hoe massaal jij jouw systemen distribueert. En ongeacht de schaal waarop je wilt opereren. Probeer ons maar eens uit. Neem contact met ons op voor meer informatie.
