interview lindy hutz2021-09-20T17:04:03+02:00
women in tech interviews

lindy hutz

‘Wat als ik wil wisselen van cloud provider, maar alle applicaties provider-gebonden zijn?’ Het is een vraag die Lindy Hutz vaker krijgt, want je bent heus niet de enige die zich dit afvraagt. Gelukkig zijn er oplossingen voor een vendor lock-in, zoals dit probleem ook wel wordt genoemd. Lindy deelt ze graag met je.

meer over women in tech
Lindy Hutz
women in tech interview

Hoe “Ports and Adapters”-architectuur Cloud (en andere) vendor lock-in kan verminderen

Het is een veel gehoord bezwaar in de cloud migratie: “wat nou als ik dadelijk wil overstappen naar een andere cloudprovider?” Ongeacht of dat nou Azure, AWS of Google Cloud Platform (GCP) is, het kan best beangstigend zijn als je applicaties vastzitten aan een aanbieder terwijl je daar eigenlijk niet meer tevreden over bent en je over wilt stappen naar een andere. Dit wordt ook wel vendor lock-in genoemd. Gelukkig zijn er manieren om dit te voorkomen.

Wanneer je de cloud in gaat, ga je altijd wel enige verbintenis aan met je cloud provider. Zeker als je serverless gaat en veel verantwoordelijkheden bij de aanbieder zelf hebt gelegd. Deze verbintenis is niet het einde van de wereld want met het verplaatsen van die verantwoordelijkheden bespaar je jezelf ook een hoop tijd en moeite.

Ook in bovengenoemde situatie is het in een later stadium mogelijk om van de ene aanbieder te veranderen naar de andere. Ik heb gehoord van bedrijven die zo’n groot financieel voordeel kregen dat het meer dan rendabel werd om over te stappen. Als je er dan ook nog voor gezorgd hebt dat je vendor lock-in sowieso al minimaal was, dan is je winst alleen maar groter.

Er zijn meerdere manieren om deze commitment laag te houden. Zo zijn er verschillende tools beschikbaar die je hierbij kunnen helpen zoals Docker of Serverless Framework. In dit artikel wil ik inzoomen op hoe je dit tijdens het ontwerpen van de architectuur van je service kunt bereiken

“Ports and adapters”-architectuur

Waarschijnlijk heb je wel eens gehoord van het Dependency Inversion-principe (DIP). Bij veel implementaties betekent DIP zoveel als “zorg ervoor dat je classes afhankelijk zijn op abstracties in plaats van concrete details”. Ports and Adapters-architectuur (ook bekend onder de namen Hexagonal-architectuur of Onion-architectuur) tilt dit naar een hoger niveau. Letterlijk. Want waar mensen die DIP toeppassen dit vooral doen op klasse-niveau, past Ports and Adapters dit toe op de architectuur van een service.

Concreet betekent Ports and Adapters dat de kern van je service, waar de bedrijfslogica zich bevindt autonoom werkt, en enkel via poorten aangeroepen worden door aansturende adapters (ook wel: driving of primary adapters genoemd). Zelf communiceert deze bedrijfslogica ook alleen maar naar buiten via “poorten” naar aangestuurde adapters (ook wel: driven of secondary adapters). Dat betekent dat de bedrijfslogica van je applicatie compleet onwetend is over hoe het aangeroepen wordt of wat het aanroept. De bedrijfslogica weet alleen dat het aangeroepen wordt door “iets”, of dat nu een Android app is, of een console commando.

Bron: https://herbertograca.com/2017/09/14/ports-adapters-architecture/

Oké, maar hoe werkt dit dan in de praktijk? Stel, je wilt notificaties sturen vanuit je applicatie zoals in bovenstaand diagram. Vanuit de Ports and Adapters architectuur schrijf je dan een interface als port die je bijvoorbeeld INotificationService noemt. Vervolgens kun je hier dan een SmsNotifcationService voor schrijven als adapter en daarnaast zou je ook een EmailNotificationService als adapter kunnen schrijven die beide INotificationService implementeren. In de adapter maak je bijvoorbeeld de integratie met AWS Simple Email Service (SES). Als je later toch liever een tool als Sendgrid wilt gebruiken, dan hoef je in de code enkel een SendGridEmailNotificationService-adapter te schrijven maar van je bedrijfslogica blijf je af. Dit maakt het tevens mogelijk om via configuratie van de ene naar de andere te schakelen.

Dit is Ports and Adapters uitgelegd in een notendop. Als je er meer over wilt weten, dan kan ik aanbevelen om de oorspronkelijke uitleg van Alistair Cockburn te lezen1. Daarnaast is de net iets pragmatischere uitleg van Herberto Graça ook erg sterk.

Dit artikel en meer in ons nieuwe magazine! Pre-order now

Hoe helpt Ports and Adapters tegen Vendor lock-in?

Met Ports and Adapters weet de bedrijfslogica dat het aangeroepen wordt door een functie, maar niet of dat dat een AWS Lambda, Azure Function of een GCP Cloud Function is. Daarnaast weet het alleen “wat” het wilt doen, zoals het opslaan van een object, maar niet “hoe”. Die “hoe” kan dus een MySQL database zijn in AWS, Azure óf GCP.

Kies je er later voor om te migreren van de ene naar de andere provider, dan hoef je alleen de relevante adapters opnieuw te implementeren. De bedrijfslogica van de services blijven intact en dat is waarschijnlijk waar de meest complexe logica zit.

Andere voordelen

Ports and Adapters is niet alleen handig bij het verminderen van vendor lock-in in de cloud, maar het helpt bij het verminderen van alle integraties. Denk hierbij bijvoorbeeld aan vendor lock-in met je Content Management Systeem (CMS), e-mailservice of je orderservice.

De Ports and Adapters architectuur helpt dus bij het verminderen van een lock-in met een cloud provider, maar het helpt ook bij het verminderen van lock-in binnen de cloud. Stel je hebt momenteel een NoSQL implementatie met bijvoorbeeld DynamoDB van AWS. De integratie is prima, maar je bedrijf groeit en krijgt de vereiste om volledige auditbaar te zijn. Je zou extra logging kunnen toevoegen om iedere actie die gedaan wordt op te vangen, maar je zou ook kunnen denken aan een andere oplossing van AWS zoals Quantum Ledger Database (QLDB). Het enige wat je in je codebase hoeft te doen, is een adapter te schrijven QLDB die voldoet aan de bestaande poorten en je applicatie zal hetzelfde blijven functioneren als voorheen.

nadelen

Helaas bestaat er in de IT niet zoiets als een gouden hamer dat een oplossing is voor ieder probleem. Ports and Adapters ter voorkoming van cloud vendor lock-in is dat dus ook niet. Neem nou een applicatie waarbij de afhankelijkheden allemaal cloud services zijn en de applicatie weinig meer doet dan het doorgeven van de informatie van de ene naar de andere cloud service. Als je dan gaat migreren naar een andere cloud provider, dan zal blijken dat het “alleen herschrijven van de adapters” betekent dat je eigenlijk de hele applicatie aan het herbouwen bent.

conclusie

Ontwikkelen in de cloud kan eng zijn maar gelukkig zijn er een paar best-practices die je kunt volgen om wat zekerheid in te bouwen. Ports and Adapters architectuur is daar eentje van. Als dit nou interessant klinkt, dan kan ik je echt van harte aanbevelen om de bijgevoegde links een keer door te nemen.

business

happy developers, happy customers

  • Rockstars tevredenheid 8.7
  • 87% wordt verlengd
  • Klantwaardering 8.5

Wil jij een vrouwelijke IT-Rockstar inhuren voor jouw project? Neem dan contact met ons op!
Onze IT-Rockstars scoren hoog op werkgeluk (gemiddeld cijfer 8.7) , 87% van de klanten willen IT-Rockstars langer op project houden, en klanten waarderen IT Rockstars enorm (gemiddeld cijfer 8.5).

Ga naar de bovenkant