De kans bestaat dat de meeste transactionele data in uw organisatie nog in relationele databases als SQL Server, Oracle en DB2 is opgeslagen. Bij het moderniseren van uw applicatielandschap zal dit echter in rap tempo veranderen. Waarom? En wat betekent dat dan?
Moderne softwareoplossingen zijn service-georiënteerd en zeer gedistribueerd, waarbij de systems of record nauwelijks nog van een user interface zijn voorzien maar alleen goede, mediated api’s hebben die de businesslogica ontsluiten. En maatwerk realiseer je door middel van low-code en integratie bovenop deze api’s.
De compositie van deze services ontsloten door api’s vindt dus plaats op een hoger niveau. En dat is waar je onderscheidende vermogen zit. Daar gebruik je kleine apps die precies doen wat jij nodig hebt, volledig geïntegreerd met je applicatielandschap. De achterliggende systems of record zullen ondertussen ook gemoderniseerd gaan worden door de leveranciers, waarbij deze ook weg bewegen van de silo en relationele databasegedachte. Mark my words.
Drie problemen
Er zijn drie enorme problemen met de relationele database:
- Relaties worden hardcoded gelegd, om de referentiële integriteit te waarborgen. Daar is geen plaats meer voor in een op microservices en apps gebaseerde software architectuur;
- Transacties worden uitgevoerd in de context van deze ene database. Dat kan niet werken in een gedistribueerd applicatielandschap. Commit en rollback zijn fenomenen van de jaren tachtig die niet meer houdbaar zijn;
- En niet te vergeten, de kosten van relationele databases zijn veel te hoog omdat ze vaak op eindgebruikerslicenties gebaseerd zijn.
In de praktijk zie je relationele databases misbruikt worden om niet relationele data op te slaan. Gewoon omdat zo’n ding er nu eenmaal al is en beheerd wordt. En omdat het dan makkelijk met de backup mee kan. Dit is een slechte strategie. Daar moet verandering in komen. Nu.
Afscheid
Nu is de tijd om al langzaam afscheid te gaan nemen van de relationele database in je maatwerkoplossingen. Ga voor elke behoefte aan dataopslag na wat precies het doel is en hoe de relatie met andere data is te leggen. Er zijn tegenwoordig talloze opslag methoden, zeker in de cloud.
Om er een paar te noemen:
- NoSQL of Document database: hierin kun je bijvoorbeeld JSON objecten opslaan en makkelijk en flexibel in zoeken. Deze databases kennen geen schema;
- Graph database: hierin sla je uiteenlopende informatie op en kun je dynamisch n-op-m-relaties leggen. Ideaal om profielen samen te stellen en data naar je toe te laten komen die voor jou interessant zijn;
- Data lake: hierin kun je allerlei variëteiten en volumes van data opslaan en vervolgens big-data-analyses op doen. Dit zal ook vaak machine-gegenereerde data zijn, zoals door iot.
In een (micro)service architectuur is het van belang om eventual consistency te regelen. De database regelt dat niet meer voor je, simpelweg omdat dat niet kan over meerdere databases heen. Hoe je je services en api’s organiseert, wordt steeds belangrijker, inclusief de bijbehorende data-architectuur.
Hoe zit het dan met business-intelligence en -analytics? Die oplossingen zullen in rap tempo moeten meebewegen. Meer en meer data die nodig zijn om dashboards te vullen of rapporten te sturen, zullen niet uit relationele databases komen. Traditionele ETL is niet meer toe te passen. Kubussen zijn niet zo makkelijk meer op te bouwen. Artificial intelligence als onderdeel van je analytics-oplossingen, zelfs als het traditioneel terugkijken betreft (wat is er gebeurd?), is onontkoombaar. Laat staan als je voorspellend (wat gaat er gebeuren?) en zelfs voorschrijvend (wat moet ik doen om dit te realiseren?) oplossingen nodig gaat hebben. Over dat soort dingen moet je nu al gaan nadenken en je architectuur er op aanpassen. Stil zitten en wachten tot de hype overwaait is geen optie. De relationele database is al klinisch dood. En de bijbehorende SQL-vaardigheden kunnen naar de afvalberg.
Een ding weet ik zeker, over 20y bestaan SQL en de RDBMS nog steeds. Ik deel je mening dat monolithic db design niet het meest geschikt is voor microservices architecture maar structured en non structured data, SQL en NoSQL staan los van microservices. Moderne lichte API`s zorgen er juist voor dat meerdere type databases gemakkelijk kunnen worden geintergreerd binnen een applicatie, juist de combinaties van SQL en NoSQL met de abstractie van een API is waar containers shinen.
Gijs,
Mijn eerste reactie ging over information governance, ik denk dat je ‘privacy-by-design’ alleen in kunt vullen vanuit een goede informatie architectuur. De focus moet liggen op het bedrijfsproces en niet op de mogelijkheden of onmogelijkheden van een bepaalde oplossing. Helaas gaan alle door applicatie geörienteerde SOA implementaties nog altijd van het omgekeerde uit, we hebben een hamer en daarom is alles een spijker zal in Next-Gen SOA niet veranderen. Ik stelde in mijn eerste reactie dat op termijn de Systems of Record het gaan winnen van Systems of Engagement omdat de hardcoded rules in een RDBMS het eenvoudig maken om de 8 privacy principes na te leven:
https://www.cs.ru.nl/~jhh/publications/pdp.pdf
Het in 8 pagina’s beschreven concept is de moeite waard om eens te lezen, een informatie architectuur zou hierop gebaseerd moeten zijn. Ondersteunende data architectuur laat zich dan grotendeels invullen met RDMS oplossingen omdat de hard-coded business rules het enforce principe invullen. Sommige regels zijn namelijk alleen bij wet te veranderen en het naleven van wet en regelgeving gaat om integriteit, een principe dat door het opportunisme van Gartner vaak onder druk staat.
Ewout,
Het document wat je aanhaalt is de voorloper van wat nu “het blauwe boekje” heet van Jaap-Henk Hoepman. Google erop, het is gratis verkrijgbaar en in gemeenteland erg populair. Ik kende dit document niet, maar het boekje is eigenlijk 1 op 1 gebaseerd op dit document.
However, dit heeft *geen* enkele relatie met SOA en vind ik bovendien behoorlijk off-topic.
Daarnaast met deze “privacy by design” aanpak verlies je ook iets. Bovendien weten maar zeer weinig mensen deze strategie tastbaar te maken en is er weinig wil om het toe te passen.
Dus Gijs, de winst van je artikel is de discussie die ontstaan is 🙂 Dus in die zin is je missie geslaagd!
Beste Gijs,
Als ik je artikel, en vervolgens de reacties erop, lees dan heb je een zeer prikkelend stukje geschreven. De titel die je hebt gekozen vond ik persoonlijk nogal “click-baity” aanvoelen, maar ik verwacht dan ook dat je deze hebt gekozen om deze reden of wellicht om een beetje te provoceren. Wat mij betreft beide prima argumenten. Het brengt de mensen naar je artikel en maakt, zoals de reacties wel bewijzen, aardig wat tongen los.
Ik ben het echter niet helemaal eens met een aantal van je argumenten of wellicht begrijp ik niet goed wat je bedoelt.
Als ik kijk naar micro services dan ben ik met je eens dat, over je services heen, je eventually consistent bent. Dit geldt echter niet voor een enkele service. Wanneer je bijvoorbeeld een DDD-stijl van ontwerpen gebruikt, dan zou je micro service een bounded context zijn en om dit te bepalen bekijk je meestal waar de transaction boundary ligt.
Het mooie van micro services is dan ook dat je voor iedere service de meest ideale opslagmethode kunt kiezen. Dit kan natuurlijk nog steeds een RDBMS zijn.
Referential integrity kun je inderdaad niet waarborgen over services heen en moet je ook niet willen. Wanneer je meerdere services op dezelfde opslag hebt, ben je in mijn mening sowieso een gedistribueerde monoliet aan het creëren.
Over de kosten van een RDBMS is in de andere reacties al genoeg gezegd, waar ik me volledig bij aansluit.
Kort gezegd ben ik het persoonlijk niet eens met de 3 problemen die je aangeeft bij een RDBMS.
Persoonlijk ben ik het wel met je een dat SQL voor analytics in een (micro) service architectuur wellicht geen plek meer is en het artikel zou, in mijn optiek, beter geweest zijn als het daarop had ingezoemd en die vraag had beantwoord.
Om een discussies los te maken is dit artikel zeker geslaagd en de discussie voeren is m.i. altijd goed. Zolang het bij de feiten blijft
Missie geslaagd. En dat met een waardering van 4.7 (m’n laagste ooit) 😉
Ja Louis, integriteit doet er niet toe.
Dat maakt het artikel “leuk en goed”.
Net als een uil van Minerva die zijn vleugels spreidt en dat de democratie gewonnen heeft enzo en “abstracties van apis waar containers shinen” met nocode 5GL SOA.
Doorgaan met abstractie tot fake news als resultaat wordt teruggegeven.
Ik heb er niets van geleerd.
Maar ik ben Dino dus vinden ze me te oud.
Volgend jaar probeer ik het weer 😛
Henri,
Als het kwaakt als een eend, waggelt als een eend en zwemt als een eend dan is het meestal een eend. Ik denk dat het SOA paradigma, waarvan MSA alleen maar een afgeleidde is, beter bij de genoemde data architecturen past dan traditionele connecties. Mocht je hierin een andere mening hebben dan hoor ik het graag maar het beestje bij de naam noemen lijkt me niet off-topic.
@Dino Ik was misschien iets te enthousiast met de kwalificatie ‘goed’. Ik ging er ook vanuit dat Gijs dit niet echt meende. Dat zou wel heel bar zijn. Er is in computerland vooral meer dat ik niet weet dan wel weet dus voor mij is al gauw leerzaam. Ik weet niet zoveel van databases al zie ik ook wel dat er meer type databases zijn en nieuwe situaties (heel erg veel data, weinig gestructureerd, gedistribueerd) om andere oplossingen vragen. Het leerzame zat voor mij in de antwoorden. Tenminste, vooral de allereerste reactie van CPT vond ik een hele goede reactie. Strak verhaal, en dacht oh ja.
Je vergelijking met de boreale uil, Pepe the Frog met de keppel op, is een goede. Charlatans met nieuwe waarheden, dat is zeker van toepassing op ICT land. Ik heb ze al veel langs zien komen, nieuwe termen, vaak oude wijn in nieuwe zakken en de nieuwlichters die de waarheid in pacht hebben. Maar ook, er zijn ook ontwikkelingen die natuurlijk wel zinnig zijn. Lastig om het onderscheid te maken en dan kan zo een artikel als dit helpen, met name door de reacties erop.
Maar kom, ik heb net een even een standup met mezelf gedaan ik ga weer verder met de computer. Het blijft een leuk apparaat, ook voor dino’s waar ik er ook een van ben.
Een toevoeging, was dit een tijdje geleden tegengekomen. Met technieken gebruikt door de grote jongens. Allemaal legacy! 🙂
https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites
Gijs !!!! wat maak je me nou !
Ik lees je bijdrages altijd met plezier maar nu breng je me echt even van de wap.
Dus beste Gijs een welgemeend advies:
Blijf weg uit de koffieschops ! Dat is gewoon geen plaats voor mensen van onze leeftijd !
@Pascal jah man 😉