Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Innoveer met één api per keer

Computable Expert

Jack Niesen
Pre Sales Consultant, F5 NETWORKS. Expert van Computable voor de topics Infrastructuur en Beheer.

Hoewel ze niet nieuw zijn, ontwikkelen api’s zich meer en meer als de lijm die alle componenten van hedendaagse applicatieontwikkeling bij elkaar houdt. Meer, api's hebben de manier waarop we naar softwareontwikkeling kijken veranderd.

Een modulaire bouw van een applicaties wordt mogelijk dankzij microservices die aan elkaar verbonden zijn middels application programming interfaces (api’s). Kleinere componenten die in harmonie samenwerken om een geweldige gebruikerservaring te leveren. Microservices kunnen hierbij progressie boeken op hun eigen snelheid als gevolg van de roadmap en feedback van gebruikers. Deze vrijheid is ongekend voor softwareontwikkelaars. Dankzij api’s kunnen ze ook ontwikkelen in de omgeving, in een taal en met de tools die ze willen. Volledig afgestemd op hun wensen of de beoogde doelen.

Aan de slag gaan met softwareontwikkeling op basis van microservices betekent dat de applicatiestrategie vooraf moet worden bepaald. Een duidelijk plan voorkomt dat er tijdens de ontwikkelingsfase allerlei extra features worden bedacht en uitgewerkt. De inzet van api’s maakt het mogelijk snel in te spelen op behoeften van gebruikers. De mogelijkheid om updates uit te rollen naar losse services betekent dat de innovatiekracht toeneemt, terwijl de risico’s worden verkleind.

Api-management

"Een applicaties kan wel honderden api’s gebruiken, en dus is management een belangrijk aandachtspunt"

Een applicaties kan wel honderden api’s gebruiken, dus management is een belangrijk aandachtspunt. Hoewel sommige microservices worden geleverd als onderdeel van de applicatie, groeit de vraag naar cloud-gebaseerde services hard. Dit kan het aspect ‘betrouwbaarheid’ onder druk zetten; we moeten ons verzekeren dat applicatie-updates geen impact hebben op de stabiliteit. Api-gateways spelen een cruciale rol hierin. Ze bieden een centraal integratiepunt en zorgen voor monitoring en security. 

Applicaties gemaakt via een ‘shared-by-design’-principe hebben een positieve bijvangst: ontwikkelaars plaatsen meer commentaar naast hun code. Het is duidelijk hoe belangrijk het is om te laten weten aan anderen wat het doel is van bepaalde code-elementen. Deze transparantie en samenwerking zien we niet in de traditionele monolithische ontwikkelingsomgevingen.

Uitdagingen

Uiteraard zijn er ook uitdagingen en wordt er een nieuwe mindset gevraagd van de ontwikkelaar. In eerste instantie gaat het erom dat er vertrouwen moet zijn dat gebruikte api’s een stabiele interface bieden en een verwacht resultaat leveren, en dat binnen korte tijd. Het is bijvoorbeeld slim om authenticatie en toegangscontrole te offloaden naar een gateway in plaats van het te hardcoden in elke api. Dit heeft ook schaalvoordelen. Als er iets verandert in de authenticatie-logica hoeft dat dan niet in de honderden api’s worden doorgevoerd. 

Het risico zit vooral in de inzet van externe systemen. In een monolithische applicatie ligt de snelheid en security vast in het geheugen van een stuk hardware. Api calls zijn netwerk-calls naar (meestal) externe systemen. Daarom moet de manier waarop intern (!) naar de applicatiebeveiliging wordt gekeken, worden geëvalueerd. Daarnaast is het cruciaal om de gateway zo snel als mogelijk te maken. Zelfs een kleine latency zal een exponentieel gevolg hebben op de app-performance.

Api’s hebben softwareontwikkeling een boost gegeven, zowel op consumenten- als op enterpriseniveau. Teams die zich richten op het verbeteren van losse microservices, die zijn te gebruiken in verschillende applicaties, stimuleren creativiteit en innovatie. Het wordt aantrekkelijk om op zoek te gaan naar nieuwe use-cases en betere performance-niveaus. We moeten hiertoe niet alleen verandering omarmen, omdat het nu eenmaal moet, maar ons laten leiden door de mogelijkheden en doeleinden. En dat doe je stap voor stap, api voor api.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

'Kleinere componenten die in harmonie samenwerken om een geweldige gebruikerservaring te leveren.' :-P
presales in actie.
Laten we tientallen microservices ontwerpen die elkaar allemaal over een onbetrouwbaar netwerk aanroepen en als er eentje niet werkt of performt, dan de hele app ook niet.
'Het wordt aantrekkelijk om op zoek te gaan naar nieuwe use-cases en betere performance-niveaus'. Ja laat maar, genoeg gehoord.

Dino,
Als ik even voorbij je ad hominem van presales kijk naar je mening over de API-architectuur dan zeg je eigenlijk dat het idee van SOA met een doorgeslagen microsegmentatie niet werkt. Nu heb ik als architect zelf daar een wat andere mening over hoewel ik ook mijn bedenkingen heb over de ketenproblematiek hierin. Ik struikel zelf dan ook meer over de opmerking dat we veranderingen moeten omarmen want uiteindelijk is de winnaar degene die met verbeteringen komt. De vraag van monolitisch of modulair wordt uiteindelijk dan ook niet beantwoord door de techniek maar door de organisatie.

Presales vs architect, niet zo adhomimem.
'in harmonie samen werken om een geweldige gebruikerservaring te leveren' is net zo'n gekleurde definitie als 'SOA met een doorgeslagen microsegmentatie'.
Als architect vind je applicaties opdelen in heel veel los gekoppelde componenten top, alleen heb je bedenkingen over de ketenproblematiek :-P
Misschien dat Mr SOA dat kan duiden met een of andere vage filosoof uit Rijnland.

Dino,
Je kunt je blind blijven staren op de boodschapper of eens luisteren naar de boodschap want de auteur heeft een heel verhaal over API's en authenticatie wat gezien de organisatorische processen best interessant is. Ik onderschrijf als architect de noodzaak om de authenticatie logica onafhankelijk te maken van de API's want hard-coded security van monolitische applicaties zijn eigenlijk een backdoor.

Betreffende het selectief winkelen in zinssnedes zou je kunnen kijken naar het probleem met de positieve bijvangst van applicaties die gemaakt zijn via een shared-by-design principe omdat dit wringt met architectuur principe van privacy-by-design. De vraag of gateways de ophaalbrug van een Rijnlands kasteel zijn met het RBAC principe van hiërarchische verhoudingen of gateway naar een vliegtuig met principe van claim-based authenticatie op basis van individuele identificatie geeft inhoudelijk naar mijn mening meer waarde aan de discussie.

Betreffende het performance aspect, breedte van de ophaalbrug bepaalt je latency als je kijkt naar de schaalbaarheid van de monolitische applicaties. De ketenregie bij parallellisatie van de workload gaat dan ook vaak om hollen en stilstaan als we kijken naar het fenomeen wachttijd. Het lezen van vage filosofen uit het Rijnland van trage kabbelende rivieren is nu eenmaal vaak makkelijker te parallelliseren dan het schrijven van een boek.

he gadverdamme, moet het weer inhoudelijk met argumenten enzo.
Maar goed.
Verdeel een monoliet in vele componenten die je over een onbetrouwbaar netwerk aanroept .. ja dan is veilige IAM een punt.
Als ik je goed begrijp ben je voorstander van een design waarbij je honderden (auteur) aanvalspunten introduceert en dan je bedenkingen krijgen over security. Net zoals dat je met honderden microservices honderden afhankelijkheden introduceert en je je dan daarover zorgen maakt.
Wonderlijk.
Roepen dat shared-by-design wringt met privacy-by-design zonder toelichting, bijv wat er shared wordt (data of code trouwens ?) geeft niet meer waarde aan de discussie. Code sharing lijkt me altijd goed idee en het data sharing probleem bij microservices los je met IAM op (Hashicorp vault bijvoorbeeld)
De ESB is wellicht wat robuster dan het Internet en een ander verschil is dat je met zo'n SOA brug controle hebt wanneer je
die ophaalt. Namelijk als je bewust wilt dat er tijdelijk geen toegang is ipv ongewild door een Internet storing.
Zonder contect roepen dat hardcoded security een backdoor is. Geen meerwaarde.
Moeilijke metaforen, gedachtensprongen die onbegrijpelijk dan wel voor meerdere interpretatie vatbaar zijn. Geen meerwaarde.
Zelf bedachte tegenstellingen. Bijv het mbt "veranderingen omarmen". Geen meerwaarde. Er is geen tegenstelling want zowel jij als de auteur willen zich laten "leiden door de mogelijkheden en doeleinden".
Ik begrijp dat een belangrijk architectuur designprincipe het reduceren van complexiteit is. Doe daar eens iets mee :-)
Ik wil er nog eentje aan toevoegen. Bedenk oplossingen voor problemen die er zijn ipv nieuwe problemen te verzinnen.
Welke legacy oplossing zit nou te wachten op CBAC ?
Al die poespas gaat uiteindelijk over security, availability, identity, access en authorisation en waar de data staat. Precies die zaken bij een monoliet en on prem SOA al opgelost zijn.

Dino,
Je laatste zin raakt de kern van het probleem want naast waar BEPAALDE data staat is er ook nog zoiets als governance, best grappig dat ze bij de politie zich nu pas druk maken over de algoritmen die meekijken naar bepaalde zoekopdrachten. Want het architectuur principe van een privacy-by-design gaat dus om meer dan gegevensbescherming en de monoliet van één merk leverde hierin een architectuur van schoorstenen op waar het idee van de ESB bedoeld was om middels een functionele standaard de technische verschillen te overbruggen.

Nu ben ik meer van de achterdeur want ik kan namelijk data ook gewoon aftappen op een lager niveau, SQL was - net als COBOL - ooit bedoeld als 'brug' naar de busines want naast het schrijven en lezen en hebben we nog wat ander I/O operators. De on-prem van Rijnlandse kasteel is door 'blitzkrieg' van moderne oorlogsvoering als de Hollandse waterlinie, deze metafoor zal misschien te moeilijk voor je zijn want ik lees wat ander boeken dan Jack waardoor ik weet dat de on-prem SOA nogal incesteus is.

Ik dacht al dat deze herhaling van zetten familiair voorkwam:
https://www.computable.nl/artikel/opinie/cloud-computing/6892091/1509029/microservices-is-stap-in-software-ontwikkeling.html

Nomaals:

Data consistency problemen met microservices (als data decentraal wordt opgeslagen in een varieteit van database architecturen), de 2 phase commit, network latencies, service overschrijdende processen als audit logging, etc. etc.

Maar op een hoger niveau heb je ook de volgende problemen:
- wie is de eigenaar van een proces dat bestaat uit x microservices
- wie is er aansprakelijk voor het niet optimaal functioneren / falen van een microservice en de daaruit resulterende schade
- hoe kan je wijzigingen coordineren in een keten van microservices
- hoe krijg je een common code base voor gedeelde functies van microservices
- hoe garandeer je de software kwaliteit van microservices
- en natuurlijk security, security ..

Maar hee, laat mij vooral de achteruitgang niet afremmen ..

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden
Nieuwsbrief

Wil je dagelijks op de hoogte gehouden worden van het laatste ict-nieuws, trends en ontwikkelingen? Abonneer je dan op onze gratis nieuwsbrief.

Vul een geldig e-mailadres in

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2020-12-03T14:42:00.000Z Jack Niesen
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.