Implementatie Azure webservices – waar loop je tegenaan?

Enige tijd geleden hebben wij als Insight een Digital Innovation-project uitgevoerd bij een omgevingsdienst in Zuid-Holland. De kern is dat deze omgevingsdienst meer informatie wilde halen uit de ruwe data die zij al bezaten. Anders geschreven; het optimaliseren van datastromen en koppelen van applicaties voor effectieve(re) output en efficiënter werken. Dit alles lijkt met de komst van cloudoplossingen eenvoudig, maar is het niet. Ik geef graag enkele tips waarmee je bij een dergelijk project rekening mee dient te houden.

Applicatie-integratie

Of je het nu applicatie-integratie of data-uitwisseling noemt, in basis gaat het erom dat verschillende applicaties gegevens met elkaar moeten uitwisselen. Zo wil je bijvoorbeeld informatie uit een HRM- systeem overzetten naar uw ERP-applicatie, of omgekeerd. Of zoals bij de omgevingsdienst, via een webformulier persoons-, locatie- en andere relevante gegevens bij een melding van stankoverlast overzetten naar een intern registratiesysteem voor opvolging. En bijvoorbeeld aansluitend naar PowerBI voor data-analyse. Helaas gaat dat niet zomaar.

Middleware
In de tijd dat IT-infrastructuren voornamelijk op servers van klanten draaiden was Microsoft BizTalk de ‘go-to-oplossing’ voor data-uitwisseling. Nu steeds meer applicaties naar de cloud gaan, is de route via BizTalk niet altijd handig. Gelukkig biedt Microsoft via Azure Services – waaronder Integration, LogicApps en Functions – diverse bouwstenen met een eigen specifiek doel, die tezamen resultaten als BizTalk kunnen bereiken.

Feitelijk is het een blokkendoos met eenvoudig aan elkaar te koppelen deeloplossingen. Je kunt dus beginnen met hele kleine stapjes en kunt gedurende de uitvoer langzaam complexiteit toevoegen. Uiteindelijk blijft de oplossing een laag tussen de applicaties, bekend als middleware. Maar nu als PaaS-oplossing; Platform as a Service. Groot voordeel is dat je de blokken kunt kiezen die je nodig hebt en dat je zelf geen onderhoud aan de technische infrastructuur van het platform hoeft te doen.

Valkuilen
En dan lijkt het zo eenvoudig. Via de Azure-website kies je een aantal services, je geeft aan wat je waar wilt hebben en klaar. Maar zo eenvoudig als het lijkt is het dan toch weer niet. Vanuit projecten zoals bij de omgevingsdienst weten wij dat er valkuilen zijn. Ik zet er enkele van op een rij. 

1. Praten met leveranciers
Terug naar het voorbeeld van de HRM- en ERP-applicatie. Bij personeel kennen we verschillende mutaties, zoals in-dienst, uit-dienst, functiewijziging, overplaatsing, et cetera. Het kan goed zijn dat binnen de HRM-applicatie dit een invulveld bij een persoon is, maar dat de ERP-applicatie waar die gegevens naartoe moet verschillende webservices nodig heeft om die data te kunnen inlezen. Welke en hoeveel webservices nodig zijn om een bepaalde set aan data te im- of exporteren is niet altijd direct duidelijk. Veel applicaties kennen geen specifieke webservices-documentatie en dat betekent dat je bij de softwareontwikkelaars, de informatie moet ophalen. Als ik een tip mag geven: ruim hier voldoende tijd voor in. Ook de softwarefabrikant heeft die informatie vaak niet direct voorhanden, helemaal als de applicatie al enkele jaren bestaat.

2. Definities
Wanneer we data tussen applicaties uitwisselen moeten we tegelijk zeker weten dat we het over dezelfde data hebben. Eenduidigheid in notitie van data is essentieel. Daar waar de ene applicatie ‘praat’ over ‘datum medewerker uit dienst’ in een bepaalde datastring, kan een andere applicatie ‘medewerker: datum uit dienst’ als input nodig hebben. Naast eenduidigheid in notitie is de plek van de data minstens zo belangrijk. Want wanneer een applicatie de verwachte data niet aantreft op de gespecificeerde locatie, kunnen allerlei fouten optreden.

3. Welke blokken
Hoe bouw je de totale oplossing binnen Azure met gebruik van services? Er zijn meerdere wegen die naar Rome leiden. Het venijn zit hem vaak in de details; hoe verschillende services gelijke resultaten kunnen leveren via verschillende routes. Denk bijvoorbeeld aan bijbehorende kosten.

4. Kosten
Kosten van de oplossing is vaak een ondergeschoven kindje en dat kan achteraf vervelende verassingen opleveren. Kiezen voor Azure-diensten of -services heeft direct impact op de kosten. Een voorbeeld. Logic Apps reken je binnen Azure af per actie die aangeroepen wordt. Wanneer je voor de oplossing gaat werken met bulkdata zoals ETL, kan de prijs dus aardig oplopen. Hetzelfde gewenste resultaat bereiken met gebruik van bijvoorbeeld Data Factory en Functions kan dan slimmer zijn. Belangrijk te weten is dat je bewuste keuzes kunt maken. Uiteindelijk zijn de kosten van de oplossing een wezenlijk onderdeel van het architectonisch ontwerp.

Tip: laat je daarbij niet uitsluitend leiden door de Azure-calculator, er zijn meerdere slimme oplossingen mogelijk waar specialisten je graag bij helpen.

5. Verrassing
Hoe goed je ook nadenkt over de oplossing of hoe goed je deze bouwt, tijdens de implementatie loop je altijd tegen ‘verrassingen’ aan. Zo kan een webservice ‘crashen’ omdat de hoeveelheid aangeroepen data onverwacht veel groter is dan de webservice aankan. Het is belangrijk om tijdens de implementatie voldoende bronnen (resources) beschikbaar te hebben om deze verrassingen het hoofd te bieden. Het betekent tegelijk dat het vooraf soms moeilijk in te schatten is hoelang een project voor het koppelen van applicaties gaat duren.

API
Wellicht denk je nu: waarom geen API? Dat maakt alles toch een stuk eenvoudiger? Het antwoord daarop is: niet altijd! Niet alleen zijn er nog vele applicaties met verouderde technologie waar geen API’s voor beschikbaar zijn. De dagelijkse praktijk leert dat webservices ook voor moderne applicaties een prima oplossing zijn voor keuzevrijheid en flexibiliteit bij het koppelen van applicaties of uitwisselen van data.

Tomasso Groenendijk, Solutions Architect bij Insight & Microsoft Azure MVP