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

SQL-vaardigheden kunnen bij grofvuil

Computable Expert

Gijs in ‘t Veld
CTO, Motion10. Expert van Computable voor de topics Digital Transformation, Cloud Computing en Infrastructuur.

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

"In de praktijk zie je relationele databases misbruikt worden om niet relationele data op te slaan"

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.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Zo, die zit: Relationele databases zijn overbodig, ouderwets en eigenlijk volledig nutteloos, maar ook veel te duur.

Ik kan het argument voor argument gaan afpellen:
- In het kader van microservices en containerisatie overbodig. Dit is feitelijk onjuist. Binnen een microservice of container is het geoorloofd om relationele databases te gebruiken. Zeker als dit binnen de microservice of container heel goed werkt. Naar de buitenwereld toe blijft de gebruikte implementatie verborgen.
- Integriteitscontroles zijn overbodig in een gedistribueerde omgeving. Dat is niet juist, ze zijn alleen niet geimplementeerd met de reguliere database-level controles. Integriteitscontrolemechnismen zijn dusdanig geimplementeerd zodat de transactie 'eventually right' is. De controle is niet meteen, stante pede, maar wordt -en dat is het gevolg van de keuze van een gedistribueerde omgeving- met enige vertraging uitgevoerd. De controle /moet/ wel worden uitgevoerd omdat anders bijv. bankrekeningen zonder klanten ontstaan. Dat is niet vaak juist in de context van een bank-applicatie. Over de microservices heen moeten deze kruisverbanden wel degelijk worden gedaan. Sterker nog, dit vergt een additionele protocol om wijzigingen te adverteren zodat elke microservice die in die berichten is geinteresseerd zijn eigen database (en dat kan dus een relationele database zijn) kan bijwerken.
- Relaties worden hardcoded neergelegd. Ja, dat klopt en dat gaat met de andere database oplossingen niet anders worden. Je zult aan beide kanten van een relatie iets moeten vastleggen waardoor het verband tussen de twee entiteiten kan worden gelegd. Of dat een technische sleutel is (primary key) of een sleutel uit een ander argument, je zult iets moeten doen op dat gebied. Die relatie leg je het liefst vast middels een gegeven die niet of nauwelijks wijzigt. Binnen de grenzen van een database doe je dat met iets als een record id of een door een systeem uitgegeven volgnummer. Tussen twee microservices zal de eigenaar van het hoofdgegeven een sleutelwaarde moeten aangeven, maar een sleutel moet er zijn en een relatie moet worden gelegd. Daar verandert de Haarlemmer olie van NoSQL of Document database niets aan.
- Een relationele database is duur. Goh... je moet betalen voor iets wat je gebruikt en waar mensen aan werken die problemen voor je oplossen. Vreemd zeg... Je kunt als bedrijf ook zelf een DBMS in elkaar sleutelen of bewust kiezen voor een oplossing die gratis is. Daar zijn echt voldoende voorbeelden van, maar accepteer dan wel bewust dat risico. Nu is het niet zo dat als je maar licentie betaalt je altijd goede ondersteuning krijgt. Iedereen heeft wel een voorbeeld meegemaakt dat je dusdanig lang aan het lijntje wordt gehouden dat het probleem vanzelf overgaat (doordat je bedrijf onderuit gaat) of je moet eerst 5 versies 20 patches installeren en dan nog wat herconfigureren waardoor opeens je applicatie onderuit gaat.
Dat laatste is eerder het gevolg van verkeerde zuinigheid van het bedrijf, waarbij een manager heeft besloten dat upgraden teveel (tijd) gaat kosten en "wat krijg ik er extra voor terug?" als belangrijjkste argument aandraagt (zulke mensen worden gehinderd door korte termijnvisie, geen ongebruikelijk gedrag bij managers).

NoSQL en Document worden aangedragen als het Walhalla, alle problemen smelten als sneeuw voor de zon, je hoeft helemaal niets te doen. Dat is pertinent niet waar. Zaken waarbij je bij een relationele database niet hoeft na te denken omdat je dit 'gratis' meekrijgt moet je opeens vervangen. Ja, transactionaliteit werkt niet zo goed over gedistribueerde databases als deze databases niet direct te bereiken zijn (de facto bij microservices) maar dan moet je je applicatie wel ietsjes anders gaan vormgeven om hiermee om te kunnen gaan. En verrassing: zoiets, of hetzelfde moet je ook bij NoSQL en Document databases doen.
Het bedrijf moet mogelijk al haar processen en procedures omzetten omdat de omgang met 'eventually right' best wel lastig is als je direct antwoord wilt hebben op bepaalde zaken.

De auteur is naar mijn mening veel te lichtvaardig omgesprongen met de problemen die aanwezig zijn bij het gebruik van anderssoortige databases. Tevens gebruikt hij een aantal drogredenen om RDBMSsen in een slecht daglicht te plaatsen. Enigszins een tunnelvisie lijkt me.

Let wel: NoSQL, graph databases en Document databases kennen wel degelijk hun goede kanten en op een aantal punten zijn ze superieur aan RDMBSsen, maar om RDBMSsen weg te zetten met de argumenten die gebruikt worden is veel te snel door de bocht.

Erg kort de bocht en een hoog buzz word gehalte. Het is waar dat het it-landschap bij bedrijven veranderd, dat API's key zijn, dat er naar betere "fit for purpose" opslag oplossingen wordt gezocht en dat die worden geprobeerd. Maar relationele oplossingen blijven een sleutel rol spelen, zij het minder prominent. Als voor je bedrijfsvoering governance belangrijk is (en waar is dat niet met bijvoorbeeld GDPR) dan is een betrouwbare en stabiele data/informatie architectuur erg belangrijk. Je moet immers kunnen aantonen dat je in control bent. Flexibele or schema-less opslag klinkt leuk en makkelijk maar is soms onwerkbaar; het hangt dus van de use case af ("fit for purpose"). Probeer maar eens als bank een Basel rapportage naar de toezichthouder te sturen, inclusief provenance en lineage van de gerapporteerde data. Vijf jaar geleden had iedereen het over Hadoop en dat Hadoop alles zou vervangen, maar die rol blijkt nu beperkt en allang over de top.
In een landschap met diverse vormen van opslag kan een common SQL engine een uitkomst zijn. Bijvoorbeeld voor data virtualisatie.
Ergo, een data/informatie architectuur is van belang en "fit for purpose" zal uiteindelijk de doorslag moeten geven en daarbij is relationeel nog steeds een optie en dus is SQL nog steeds belangrijk.

Allemachies Gijs,

Je visie op blockchain vond ik niet sterk, maar hier sla je in mijn ogen behoorlijk de plank mis.

Te beginnen bij de titel. SQL als taal is gericht op functioneel programmeren: Je stelt welk resultaat je wilt. Dit is anders dan imperatief programmeren, waarbij je met instructies verteld wat een computer moet doen en daaruit komt dan een resultaat. Alleen al in deze manier van denken zit niet alleen schoonheid, als jij data wilt halen uit "big data" uit een gedistribueerde no-sql database kun je bijvoorbeeld bij Google dit nog steeds doen met SQL instructies. Dus de vaardigheid blijft gewoon overeind al wordt er geen relationele database gebruikt.

Ik weet natuurlijk niet op welke schaal jij opereert en Facebook moet je niet willen bouwen in een relationele database, maar voor zeer veel andere toepassingen en groottes kan een relationele database nog prima functioneren.

"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;"

Dus data integriteit is niet meer belangrijk? Zoals je weet is data integriteit in een distribueert systeem best lastig en als de schaal heel groot is, dus ook langzaam.

"En niet te vergeten, de kosten van relationele databases zijn veel te hoog omdat ze vaak op eindgebruikerslicenties gebaseerd zijn."
Je kijkt hier door een Microsoft / Oracle bril. Bijvoorbeeld Postgres is een prima en krachtig alternatief die dus niet hierop gebaseerd is.

Om dan toch even bij Postgres te blijven... daar kun je native JSONB formaat data in opslaan die je er ook nog eens goed op kunt vragen. Leg er een GraphQL laag overheen, kun je er BAM ook nog een microservice van maken die bronnen uit meerdere databases op vraagt.

En die no-sql databases zorgen in de regel ook nog eens voor extra complexiteit waar je weer dure consultants nodig hebt. Dus die eventual consistency is een nachtmerrie bij wijzigingen in systemen.

Met de beweringen die je er verder onder plaatst is het heel afhankelijk wat je wilt en wat je doet welk type architectuur daar het beste bij past.

Relationele databases lijken op hun retour en de no-sql alternatieven zijn steeds beter. Je stelling en onderbouwing zonder voorbeelden vind ik niet sterk en kloppen gewoon niet of laten genoeg ruimte om ook het tegenovergestelde te kunnen beweren.

Ik vind het in ieder geval een slecht verhaal en dat voor iemand die gek is op microservices, graphql, serverless en meer van dat soort spul.

Met "relaties worden hardcoded vastgelegd" bedoel ik natuurlijk "hardcoded in de database vastgelegd". Dat we nog steeds integriteit nodig hebben lijkt me logisch, maar dit moet op een hoger niveau worden geregeld (vanwege alle redenenen genoemd).

Lineage (en dus auditability) van data kan (en moet dus, in moderne data architecturen!) ook op andere manieren worden geregeld.

Echte SQL huggers jullie :-)

En Henri, ik was inderdaad Blockchain nog vergeten in het rijtje moderne opslagmethoden. Kan er alleen nog geen goede toepassing voor bedenken die alleen daar mee kan ;-)

Tuurlijk heb ik het lekker scherp neergezet, maar feit is dat het gebruik van relationele databases in heel kort tijdbestek, in moderne applicaties die de komende jaren worden ontwikkeld, snel zal afnemen. Ook de visie van Gartner (vorige week op Gartner AADI in Londen nog persoonlijk aan me bevestigd door Andy Kyte). En die hebben altijd gelijk. Of krijgen het in ieder geval.

Een modern data lake bestaat uit zowel relationele en niet-relationele databases. Daar moet je governance dus plaatsvinden. Met moderne manieren, waarbij je niet alleen meer op de ingebouwde features van een relationele database kunt vertrouwen.

Spreek jullie over 10 jaar weer hierover! :-)

grofvuil, klinisch dood, afvalberg. Lekker scherp hoor.

Zodirect nog een reactie van Ewout dat Gijs iets vergeet waar Ewout wel aan denkt als we kijken naar iets waar Ewout naar kijkt ;-)

Gijs,
Het klinkt alsof je klakkeloos de mening van Gartner overneemt, een mening die soms meer op marketing gebaseerd is dan op realiteit. Het idee om de information governance hoger in de stack te leggen zorgt voor de 'black-box' modellen zoals van RevNext. Aloude gezegde van crap in, crap out geldt dan ook met name voor Big Data projecten waar de information governance aan de basis niet goed geregeld is.

Je information governance afhankelijk maken van gepatenteerde algoritmen is dus het domste wat je kunt doen en een data lake welke uit allerlei vergiftigde bronnen bestaat leidt tot een bedot.com economie zoals ik dus al in 2012 voorspelde. CPT gaat uitvoerig in op de noodzaak van integriteitscontrole in ketens, vrijwel alle reacties - inclusief Henri - erkennen de problematiek van integriteit in ketens. De term 'eventual consistency' is een marketingkreet die uitgaat van aannames in het proces.

De integriteit van een proces blijkt lastig te schalen maar vormt de basis van het vertrouwen in een systeem en hierin winnen de 'Systems of Record' op basis van aloude RDBMS het steeds vaker van de 'Systems of Engagement' waar de waarheid een gewogen consensus van meningen blijkt te zijn.

En dan te bedenken dat een 4GL zoals SQL juist naadloos is te combineren met komende 5GL-talen. Zodat huidige 3GL/4GL-oplossingen vervangen kunnen worden door 4GL/5GL-oplossingen.

Voor een recente oplossing voor:
https://dmcommunity.org/challenge/challenge-march-2019/

heb ik onderscheid gemaakt tussen opvraagbare variabelen en afleidbare variabelen; zie de toelichting op bladzijde 6 in mijn document. Op dit punt kunnen de beslissingstabellen (5GL) dus naadloos worden gecombineerd met iedere relationele (of niet-relationele) database (4GL). Alle opvraagbare variabelen (attributen en proposities) die aan de gebruiker worden gevraagd door middel van “askable_using” kunnen namelijk vervangen worden door queries in SQL (en via Python worden aangesloten op elke gewenste database).

Het overzicht is nu heel eenvoudig:
opvraagbare variabelen: 4GL, afleidbare variabelen: 5GL.
Vervolgens kunnen de resultaten in de afleidbare variabelen (met name de doelvariabelen) door middel van 4GL weer in de database worden doorgevoerd.

Uiteraard kun je de als-dan regels in de beslissingstabellen ook vastleggen in een willekeurige 3GL (Java, PL/SQL), maar dan krijg je een onoverzichtelijke nesting van als-dan-anders en case opdrachten (zonder controle op volledigheid!).

Ik ben overigens benieuwd hoe een oplossing voor deze challenge er met low-code of no-code uit gaat zien.

Voor wie benieuwd is naar volgende doodlopende wegen in bedrijfstechnologie zijn de artikelen van in ’t Veld beslist een aanrader!

Geeeeez, ik zal voortaan m'n opinies met de volgende disclaimer beginnen: "Niet voor overgevoelige IT-ertjes die alles 100% letterlijk nemen". :-)

Feit is dat data architectuur in rap tempo volwassener moet worden om de complexiteit van gedistribueerde data in verschillende vormen, snelheden en volumes aan te kunnen en dat we dat grotendeels niet in de verschillende datastores zelf zullen kunnen oplossen. In SOA was het al een uitdaging die niet iedereen even goed begreep. Alleen nu is het een factor X complexer geworden. Er zullen ongetwijfeld nieuwe frameworks en talen voor komen. Tot die tijd blijft het knoeien.

Gijs, waarom kijk je niet naar in-memory column-oriented databases als het over volumes en snelheden gaat?

Een paar jaar geleden keek ik Idols en was er een vrouw die vreselijk zong. Het kritiek wat ze kreeg was "Je zingt echt niet goed en gezien je leeftijd verwacht ik niet meer dat het zal veranderen, dus ik stem 'nee'."

Ze kwam de Idols auditie ruimte uitlopen waar haar vrienden stonden te wachten, ze zei "Ze vonden me te oud."

---
Mijn punt is; ik (wij) zijn niet overgevoelig, maar reageren op de inhoud en weerleggen dat met argumenten.

Het is gewoon een slordig artikel wat blijkbaar geïnspireerd is op iets wat je bij Gartner gehoord hebt en je vertaald hebt naar een "prikkelend" stukje. Slordig omdat je de taal om data op te vragen verward met een manier van dataopslag technologie.

SQL vaardigheden zouden we zeker niet bij het grofvuil moeten zetten en is juist een gemiste skill bij veel developers.

Ik zie het al voor me... er komt een nieuw project en omdat je bij Gartner hebt gehoord dat relationele databases dood zijn stel je nu een alternatieve oplossing voor. Dan worden er dure lessen geleerd...

Het aantal keer dat ik de Gartner hype cycle langs zie komen bij praatjes over nieuwe technologie is enorm hoog. Nu blijkt die hype cycle een heerlijk verhaal te zijn waar veel op af te dingen valt:https://www.linkedin.com/pulse/8-lessons-from-20-years-hype-cycles-michael-mullany/

In 2011 schreef ik ook een "prikkelend" stukje op Computable; Cloud computing adopt or die. ( https://www.computable.nl/artikel/opinie/cloud-computing/4145401/1509029/cloud-computing-adopt-or-die.html )
Kreeg ook veel kritische feedback. Het gaat vaak ook over de toon...

Ik vind het gewoon slechte raad die je geeft, omdat die reactie dan als overgevoelig te bestempelen helpt dan niet mee.

Maar goed, misschien komt er een keer dat je jouw reguliere twitter status een keer met me wil delen (biertje drinken), ik hou mij aanbevolen!

Nadat ik dit gelezen heb kwamen een paar associaties "volgend jaar wordt het jaar van de linuxdesktop" en "a fool with a tool is still a fool".
Dat ligt natuurlijk aan mij, ik ben te dom te begrijpen dat half internet geen mysql meer nodig heeft of dat Oracle ten dode opgeschreven is.



Gijs,
Ik waardeer je feedback op de reacties hoewel ik de ad hominem over IT-ers misplaatst vind maar dat zal wel mijn overgevoeligheid voor de valse profeten zijn. Over je geconstateerde ‘flawness’ in het service georiënteerde denken schreef ik trouwens 5 jaar geleden al dat SOA het bestaan van data negeert. En voor alle duidelijkheid, Gartner definieert SOA als volgt:

"Service-oriented architecture (SOA) is a design paradigm and discipline that helps IT meet business demands. SOME ORGANIZATIONS REALIZE SIGNIFICANT BENEFITS using SOA including faster time to market, lower costs, better APPLICATION CONSISTENCY and increased agility."

Ik heb mijn 'overgevoeligheid' in definitie even in hoofdletters gezet want hierdoor zijn veel implementaties van SOA proces- en productgeörienteerd. Als de gepatenteerde software van een leverancier de inrichting van je bedrijfprocessen bepaalt dan wordt je in het pak van legacy genaaid. Voor alle duidelijkheid, het gaat niet om het volwassen worden van de data architectuur maar om de wijze waarop de informatie daaruit gehaald kan worden.

Volgens mij heeft Gijs de rapporten die hij heeft gelezen of niet goed begrepen of verkeerd geïnterpreteerd. Dat er naast relationele databases de alternatieve vormen meer in schwung raken is een belangrijke ontwikkeling. Alleen houd dat niet in dat de relationele database gedoemd is om te sterven. De relationele database is een bewezen en relatief eenvoudige manier om gegevens op te slaan. Naar gelang de eisen kan dit dus nog steeds ingezet worden. Er vindt nog steeds innovatie plaats bij relationele databases. Uiteraard niet zo veel meer als vroeger als de alternatieven.

Dat nieuwere manieren van gegevens opslaan beter lijken is ook relatief want net als alles hebben ook deze manieren hun sterke en zwakke punten. De kracht is juist als je in je applicatielandschap een hybride oplossing kiest die alle sterke punten samenvoegt en zoveel mogelijk zwakke punten neutraliseert je een behoorlijk goede fundatie hebt voor wat voor oplossing dan ook. Met name de laatste tien jaar is er qua standaardisatie van database API's behoorlijk veel veranderd wat het leven van architecten en programmeurs zoveel malen makkelijker maakt dat meer met de echte problemen kunt worstelen.

Het is duidelijk dat Gijs tegen de lamp gelopen is met zijn 'boeken wijsheid' want ik krijg niet echt de indruk dat hij nog recentelijk zelf in de code heeft gedoken en met zijn voeten in de modder heeft gestaan. Wat databases betreft heb ik redelijk lang met het hele scala van varianten gewerkt en weet daarom ook dat als je SQL beheerst de overstap naar alternatieven het makkelijker maakt omdat je die abstracte denkwijze kan overnemen en toepassen in een ander context.

De meeste oudgediende ICTers zijn relatief conservatief en hebben zo vaak al de mooie verhalen van oude wijn in nieuwe zakken wel gehoord. ICT is geen speelveld voor al te veel modegrillen en waar vakmanschap, pragmatisme en lange termijn denken de boventoon vieren. Deze kernwaarden staan altijd in het centrum van welk succes in de ICT dan ook.

Beste Gijs, het aantal technologieën dat bij het grofvuil kan is niet meer op de handen van een heel leger IT-ers te tellen. Het aantal technologieën dat in de datacenters van de gemiddelde grote onderneming te vinden is ook niet.

Een organisatie zoals Gartner moet toch zorgen in de belangstelling te blijven, en zoveel anderen, en ook wel eens choqeren .
Er is natuurlijk evolutie, maar ook hypes als Industrie 4 en Internet of things zijn ook mooie verzinsels, die wel de verdienste hebben een gedachtengoed onder de aandacht te brengen, maar ook als business enabler bedoeld, om vooral bij directies ( die er toch niets van begrijpen) angst en onzekerheid aan te praten , dat ze de boot gaan missen.

In 1970 werden door IBM de Copics Black Books gepubliceerd, opgesteld door IBM ers en wetenschappers, met aanbevelingen hoe SW organisaties software konden ontwikkelen om organisaties te ondersteunen. De voorbereidingen zijn dan zeker meer dan een halve eeuw geleden gestart. Wat vond ik schattig daar in: productie machines aansturen met papertapes, aangemaakt door de computer. En data beheer: nog met ponskaarten, en bij wijziging werd geadvizeerd een Journalling kaart te ponsen.
Over die papertapes : die grote orgels die met brede ponsbanden aangestuurd werden is toch ook al automatisatie, geen idee wanneer de eerste tot stand kwam.
Op een sw-event stond ik als standhouder, toen een van de bezoekende studenten de opmerking maakte : 'IBM heeft fout gemaakt door mainframes te ontwikkelen, ze hadden moeten starten met PC's.'. Mijn reactie overtuigde de bolleboos toch : zonder mainframes waren er nog geen PC.s.
Dus zo maar iets op de vuilnisbelt zetten om,intressant te doen getuigt ook niet van inzicht.

@Ewout - volgens mij gaat data architectuur ook over hoe data er in gaat (dus niet alleen over hoe het er uit gehaald wordt).
@Johan - ik ben zelf jarenlang systeem ontwikkelaar geweest in een team wat een RDBMS en 4gl ontwikkelde en waarop (nog steeds) honderden klanten draaien met hun bedrijfskritische processen. Daarna jarenlang een R&D team geleid (en mee ontwikkeld) wat een integratie middleware oplossing ontwikkelde wat op Unix, Linux, VMS en Windows en Sybase, DB2, Oracle en SQL Server draaide waar uiteindelijk meer dan 500 klanten hun bedrijfskritische processen op draaiden. En vandaag de dag hebben we een team van 80+ specialisten die dagelijks met Azure PaaS oplossingen en service integratie bezig zijn. Dus praktijkervaring is er zeker.
@Robert - Klopt. Afscheid nemen is lastig. En daardoor stijgt de technical debt nog harder. We hebben alles wat ooit uitgevonden is allemaal nog steeds draaien in onze dc's.

Gijs, maak het nou niet erger ;-)

Gijs,
Mijn reactie ging over een 'flawness' in het service geörienteerde denken want daarin is data architectuur - wat een onderdeel is van de Enterprise architectuur - alleen maar de applicatie architectuur. En het is hierdoor dus lang niet altijd duidelijk hoe de data erin gaat en het is ook niet altijd duidelijk hoe - het recht om vergeten te worden? - je de informatie er nu weer uit krijgt.

@Ewout - Next Generation SOA (Thomas Erl) schrijft hier wel wat over. Ik was overigens een van de technical reviewers van dat boek. En AVG / GDPR is inderdaad nog een heel ander vraagstuk.

Gijs, een erg leuk en goed artikel. NIet eens met wat je schrijft, maar dat doet er niet zoveel toe. Gooi de knuppel maar in het hoenderhoek. Het zijn boude beweringen die je daar doet maar het maakt wel de discussie los. Hele goede en leerzame reacties gelezen en het zet aan tot nadenken. Als iemand die altijd op de mariadb uitkomt is het wel eens goed na te denken hoe je een DB kan en wil gebruiken.

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 :-P

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 ;-)

Als aanvulling op mijn vorige reactie:
https://dmcommunity.org/challenge/challenge-march-2019/

en dan deel 2.

Geheel binnen het uitstekende idee van purpose-driven is deze oplossing gewoon goal-driven.

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
Vacatures Digital Transformation

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 2019-05-29T12:09:00.000Z Gijs in ‘t Veld
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.