Als één bedrijf een goede reden had om Oracle te dumpen, dan was het Amazon wel. Maar toch, 14 jaar nadat Amazon begon met klagen over zijn "belastende Oracle database infrastructuur" en startte met het "evalueren of we een speciaal gebouwde database kunnen ontwikkelen die onze zakelijke behoeften op de lange termijn zal ondersteunen" is de internetwinkel en cloudprovider nog zeker tot het eerste kwartaal van 2020 niet vrij van Oracle, zoals dat wordt beschreven door CNBC's Jordan Novet.
Die "I can't leave you, baby"-realiteit, om de tekst van Led Zeppelin aan te halen, is niet zozeer een bewijs van Oracle's database-grootsheid, maar van de moeilijkheden die inherent zijn aan het verplaatsen van gegevens. Of, zoals Gartner-analist Merv Adrian ooit zei: "De grootste kracht van legacy-databases is inertie."
Waarom zelfs het machtige Amazon vastzit op zijn legacy Oracle databases
Waarschijnlijk heeft Amazon de database van Oracle al in 2004 verder opgeschaald dan die aankon, zoals Amazon CTO Werner Vogels toen al zei, maar pas tien jaar later overwoog Amazon serieus om de eerbiedwaardige technologie te vervangen. Zoals uit de interviews van Novet blijkt:
"Amazon begon ongeveer vier of vijf jaar geleden met verhuizen weg van Oracle, zei een van de mensen, die verzocht niet bij naam te worden genoemd omdat het project vertrouwelijk is. Sommige delen van Amazon's core shopping business draaien nog steeds op Oracle, zei deze persoon, en pas over 14 tot 20 maanden moet de volledige migratie zijn afgerond. Een andere persoon vertelde dat Amazon al jaren overwoog om Oracle uit te faseren voordat de migratie begon. Maar ze besloten op dat moment dat het veel te veel ingenieurswerk zou kosten en te weinig zou opleveren."
"Te veel werk met misschien te weinig rendement" beschrijft perfect waarom de meeste legacy tech blijft hangen. Als een applicatie eenmaal geschreven is om op het mainframe te draaien, heeft het vaak weinig zin om deze te herschrijven zodat hij elders kan draaien. In de woorden van Adrian: "Als iemand heeft geïnvesteerd in het ontwerp, de fysieke plaatsing van gegevens, de netwerkarchitectuur, enzovoort rond een bepaalde tool, dan doek je dat niet zomaar op en verplaats je die data niet zomaar even."
Wat niet kapot is, hoeft niet te worden gerepareerd. Tenminste, dat wordt niet gedaan.
En dus zat Amazon vast aan Oracle, zelfs met de legacydatabase die niet zo kan schalen zodat hij aan de behoeften van Amazon kan voldoen. In plaats van alles opnieuw ontwerpen, heeft Amazon simpelweg nieuwe toepassingen gebouwd die draaien op hun eigen databasetechnologieën zoals DynamoDB en Aurora.
Ondertussen, meesmuilde Oraclebaas Larry Ellison op een bijeenkomst in december 2017 dat Amazon $50 miljoen moest ophoesten, bovenop honderden miljoenen die ze in de loop van de afgelopen jaren al hadden betaald. Maar zulk leedvermaak kan het totale falen van Oracle niet verdoezelen om te concurreren met Amazon Web Services in de cloud, waar haar marktaandeel niet meer is dan een afrondingsfout. En dat zou niet zo erg zijn als het niet voor het voldongen feit stond dat data in toenemende mate in de cloud ontstaan, en dat het daar dus blijft in cloud-databases, zoals die van AWS of Microsoft Azure.
Waarschijnlijk gebruik je je RDBMS niet zoals hij bedoeld is
Bedrijven die hun huidige toepassingen eens goed onder de loep leggen, zouden wel eens kunnen ontdekken dat, net zoals Amazon in 2005 deed, "ze vaak niet werden gebruikt voor hun relationele functies". Graaf je nóg dieper, dan kun je erachter komen, net als Amazon, dat "about 70 percent of operations were of the key-value kind, where only a primary key was used and a single row would be returned. About 20 percent would return a set of rows, but still operate on only a single table."
Met andere woorden: bedrijven die goed kijken naar hun data komen erachter dat Oracle (of willekeurig welke relationele database ze ook gebruiken) helemaal niet geschikt is voor wat ze ermee doen.
Het strijdtoneel voor data is het mogelijk maken van transformatie
Maar het is helemaal niet denkbeeldig dat bedrijven, net als Amazon, er 14 jaar over gaan doen om hun RDBMS uit te faseren voor die oude workloads, omdat "er te veel werk mee is gemoeid en het misschien te weinig oplevert." Voor nieuwe toepassingen staat er daarentegen voldoende rendement tegenover.
Data ontstaat niet alleen in toenemende mate in de cloud, ook is het aantal manieren waarop je ze kunt beheren aanzienlijk toegenomen. Dit betekent niet dat relationele databases zoals Oracle dood zijn. Het betekent alleen dat één enkele applicatie vaak verschillende databases zal gebruiken. Zoals Vogels schreef:
"We zien steeds meer dat klanten toepassingen willen bouwen die schalen over het internet, en daarvoor zijn diverse datamodellen nodig. Om aan deze behoeften te voldoen, hebben ontwikkelaars nu de keuze uit relationele, key-value, document, graph, in-memory en search databases. Elk van deze databases lost een specifiek probleem of een groep problemen op."
Dit is echter een op de toekomst gerichte verklaring. Het gaat om wat bedrijven bouwen of gaan bouwen, in plaats van wat ze al hebben gebouwd (en waar ze mee moeten leren leven).
Dit is het strijdtoneel van data. Het gaat niet om legacy-applicaties en de legacy-databases die deze ondersteunen. Nee, het gaat om de toekomst van het bedrijf, want bedrijven proberen een verbluffende hoeveelheid gegevens aan het werk te zetten om hun manier van werken te veranderen.
Dit is een wereld waar Oracle - als marktleider - tot nu toe heel weinig impact heeft. Als dit zo doorgaat, zal niet alleen Amazon zich uiteindelijk ontworstelen aan de greep van Oracle op zijn data-infrastructuur, maar ook de meeste andere bedrijven.
Ik snap de referentie naar het mainframe niet in het kader van dit artikel? Sinds wanneer draait Oracle op mainframes?
Staat letterlijk in het artikel. Als iets werkt, pas je het niet meer "even" aan. Dit kunnen hele complexe aanpassingen zijn. Zeker als er in het begin niet goed over nagedacht is.
In de woorden van Adrian: "Als iemand heeft geïnvesteerd in het ontwerp, de fysieke plaatsing van gegevens, de netwerkarchitectuur, enzovoort rond een bepaalde tool, dan doek je dat niet zomaar op en verplaats je die data niet zomaar even."
Wat niet kapot is, hoeft niet te worden gerepareerd. Tenminste, dat wordt niet gedaan.
Ik zie dat Oracle 12 al op [Link]
Verwijzingen naar Oracle 10 [Link]
Dank je wel Rolfieo.
AIX machines zijn geen mainframes, hoewel er wel mensen zijn die ze zo noemen. Mainframes zijn machines die z/OS draaien. AIX staat al jaren stil, terwijl de "echte" mainframes nog steeds gemoderniseerd en doorontwikkeld worden. Mainframes hebben (ten onrechte) een slechte naam als zijnde ouderwets. Bij mainframes geldt wel hetzelfde als bij alle systemen: als je de architectuur van de applicaties nooit aanpast, dan loopt het vanzelf vast. Architectuur en software moeten meegroeien.
Oke.
Ik kan nog wel referentie vinden op basis van de IBM zEnterprise
[Link]
Maar ik weet niet of je dit ook vind onder definitie van mainframes? Maar ik snap wat je bedoelt.
Hele leuke link! IBM probeert dit zeker als mainframe gebruik te positioneren. zLinux is onder andere gemaakt om het mainframe ook relevant te laten zijn in een wereld waarin Linux steeds belangrijker is geworden. Strikt genomen is dit Oracle op Linux en geen mainframe op zich, maar ik zou het toch wel een beetje mainframe noemen.
Tenzij de kosten de pan uit rijzen of oracle stopt met de support (zie [Link] )
Standaard ellende van bedrijven met gesloten systemen. Eerst zorgen dat je verslaafd bent dan cashen.
Qua database is een Oracle RDBMS op zich niet eens een slechte keuze, zeker niet op het moment dat je support bij kan blijven kopen en dat kan vaak ook nog wel bij Oracle.
In dit geval gaat het om een groot IT-bedrijf (Amazon) dat moeite heeft om een migratie goed af te ronden, maar in het geval van de overheid heeft men natuurlijk kilometers boter op het hoofd.
Er zijn tig moties aangenomen om open standaarden voorrang te geven, maar aan de andere kant blijft de overheid gewoon met MS-Office werken en doc-bestanden mailen - terwijl diezelfde overheid aangeeft dat OpenDocument de voorkeur heeft...
Dit is maar 1 voorbeeld, maar ook op het gebied van besturingssystemen is er geen sprake van open standaarden maar is het een gesloten geheel (mocht het toepassen van een open standaard niet mogelijk zijn ga dan de bestaande opzet maar openbreken in EU-verband...)
SQL is dan wel weer redelijk open. Probleem is echter meestal dat Oracle niet alleen een zuiver RDBMS levert maar ook stukken middleware waar een hoop businesslogica in ligt besloten.
Hangt er vanaf. Als het je core is van je bedrijf, dan mag dit gewoon geld kosten. Vaak zijn er geen alternatieven, zeker niet als je kijkt naar het verleden. Zelf ontwikkelen kost ook een vermogen, zowel in tijd, geld en resources. Je moet dus wel de kennis en kunde in huis hebben om dit te doen. Dus wat zijn dan de "kosten"..... Als je 50 miljoen per jaar uitgeeft (wat een hoop geld is), op een kwartaal omzet van 6 miljard en een
winst van 2 miljard. Dan hebben we het over 1% aan kosten tov de winst. Tov an de omzet is het nog eens een stuk lager. Het zijn natuurlijk kosten, die je graag wilt voorkomen. Maar de ontwikkeling/beheer en migratie van een compleet nieuw product zijn ook hele grote kosten posten.
Zelfs als je "opensource" gebruikt, heb je het zelfde issue van "application lifecycle management" en goede architectuur neer zetten. Dat staat helemaal list van verslaafd en gesloten systemen.
Het principe van gesloten systemen in relatie met vendor lock wil maar niet landen bij je.
Omdat het vaak niet de oorzaak is van de issues.
Reageer
Preview