Nogal wat leveranciers van softwarepakketten adverteren met hun ondersteuning van meerdere merken databases. En het zijn niet de minsten. Onder hen: SAP, Opentext, en Topdesk, om er maar een paar te noemen. Als enige eis stellen deze applicaties dat er een SQL-compliant database wordt gebruikt. Elke serieuze relationele database spreekt dit protocol.
Oppervlakkig beschouwd klinkt dat aanlokkelijk: welk merk database in je organisatie al aanwezig is, Oracle, IBM DB/2, MS SQLServer of MySQL: het gaat werken. Dat scheelt installeren, het opleiden van je beheerders en het onderhandelen met een databaseleverancier.
Toch is het gewoon een slecht idee en moet je dit niet willen. Waarom niet? Er zijn argumenten van technische en architectonische aard. Daarover graag een volgende keer. Hieronder een simpeler reden: geld. Je betaalt bij zo’n applicatie teveel licentiekosten voor de database en voor de licentiekosten van het pakket zelf.
Licentiekosten database
De afgelopen decennia hebben leveranciers van databases enorm veel functionaliteit toegevoegd aan hun producten. Waar databanken in het (verre) verleden uitsluitend de opslag van gegevens regelden in tabellen, zijn deze in de loop van de tijd geëvolueerd tot geavanceerde platforms met de introductie van autorisatielagen, integriteitscontroles, stored procedures, triggering mechanismen en zelfs embedded fileservers, webservers en jobschedulers. Voor al die mooie functies wordt dan wel stevig betaald door de afnemers. Zelfs de instaplicentie van een database van één van de grote merken kost al snel duizenden euro’s per jaar.
In tegenstelling tot de standaardtaal SQL, (die overigens vele dialecten kent) zijn al die extra opties leverancierspecifiek en daardoor niet (zomaar) uitwisselbaar. Pakketten die meerdere SQL-databases ondersteunen gebruiken daarom alleen die opties van een database die altijd aanwezig en universeel zijn: het verbinden met de database en de opslag van data. Dat is natuurlijk doodzonde: al die mooie opties van jouw database worden niet gebruikt. Maar je betaalt er wel voor.
Licentiekosten pakket
Om meerdere databasemerken te kunnen ondersteunen moet een pakketleverancier flink investeren. Tenslotte moet hij minimaal testen of zijn applicatie ook echt werkt met al die SQL-databases. Dat betekent kosten voor de licenties van al die gegevensbanken, het inhuren of in dienst nemen van personeel met de benodigde kennis, testen, extra infrastructuur, et cetera.
Jij, als afnemer van zo’n pakket kiest echter (meestal) maar één optie: SAP met Oracle of Opentext eDocs met SQLServer. Je betaalt dan echter eveneens voor de ontwikkelkosten van SAP met SQLServer, DB/2 of SAP-DB. De licentiekosten van de applicatie zijn dus (aanmerkelijk) hoger voor functionaliteit waar je als afnemer niets aan heeft.
Niet doen dus, die applicaties die meerdere databases ondersteunen. Dat is het weggooien van (veel) geld. Kun je echt niet om een pakket heen, omdat het de standaard in jouw branche is of de functionaliteit precies aansluit bij jouw behoefte: kies dan voor de goedkoopste database, al is deze nieuw voor je organisatie. Je beheerders zullen er weinig werk aan hebben want van al die geavanceerde functies wordt toch geen gebruik gemaakt. In alle andere gevallen: kies een pakketleverancier die keuzes durft te maken en optimaal gebruik maakt van de opties van jouw dure database.
Jurrie Zaat, managing consultant Orcado
Het artikel is helder geschreven maar de concludering is nogal kortzichtig omdat het simpelweg vendor lock-in voorstelt. Maar ook wordt achteloos decennia aan innovatie over de schutting gekieperd en toont het een strategisch inzicht van een pakje boter.
Iedere IT architect kan je helder en duidelijk uitleggen waarom je een generieke database ontsluiting nodig hebt. En ja dat kost extra geld, tijd en soms ook wat performance. Maar wat krijg je er voor terug?
Dat je applicatie makkelijker kan migreren vanwege diverse redenen zoals het groeien naar een grotere, snellere en redundante omgeving. Een gunstigere en goedkopere partij. En als een leverancier stopt met het product wat je gebruikt of zelfs failliet gaat dan kan je op alternatieven overstappen.
Wat de praktijk betreft heb je wel degelijk een punt want vaak wordt beweert dat men generieke ondersteuning heeft voor databases maar kan dat niet worden aangetoond omdat het simpelweg niet werkt. De reden is omdat er diverse SQL dialecten zijn en dat er soms oplossingen gebruikt zijn die niet werken op een bepaalde database technologie.
En vaak wordt er mettertijd maatwerk uitgevoerd vanwege onderhoud en/of performance issues die wel database afhankelijk is. Dit wordt overigens met liefde door consultants gedaan omdat ze weten dat ze hiermee zichzelf onmisbaar maken voor de rest van de tijd van het gebruik van het product en toekomstige ontwikkelingen. In dat opzicht is elk stukje maatwerk vaak een klinknagel tussen je product en de gebruikte database.
Het is dan de kunst om er een bout en moer van te maken. Dat kan door gebruik te maken van een database API die database onafhankelijk is en daarmee de scheiding is tussen de twee onderdelen.
Een software product die hier geen gebruik van maakt is feitelijk achterhaald want software ontwikkeling is mede dankzij de cloud in het modulaire tijdperk beland.
Jurrie,
Als we in de hele keten kijken dan zou het gebruiken van een onbekende db een risico vormen in het geval dat je een probleem krijgt.
Stel je voor:
– Je hebt performanceproblemen binnen de applicatie die gebruik maakt van die (onbekende)db.
– Of je hebt performanceproblemen binnen andere applicaties die op hetzelfde deel van je storage zitten als die onbekende db,
– Of je hebt performanceproblemen binnen andere applicaties die door dezelfde host-server aangeboden worden als de host-server van die onbekende db.
Alle leveranciers (van andere applicaties, van je netwerk, van je hypervisor, van je storage) gaan eerst met de vinger wijzen naar je onbekende db! Hun advies: Tja, we ondersteunen die database niet en je zou eerst moeten proberen die database te isoleren (op andere hardware zetten). Terecht of onterecht, dit is de eerste wat je zou MOETEN doen om verder door de leveranciers geholpen te worden.
Maak je gebruik van een bekende database dan ben je heel verder in je oplossingsproces.
Na veel tijd en geld besteed te hebben aan onderzoek en consultancy kom je er achter dat je:
1) een hardware moet aanschaffen voor hosten van die db en applicatie + migratiekosten
2)of een andere database gebruiken dus weg met je beoogde besparing,
3)of een andere applicatie aanschaffen want de betreffende applicatie ondersteunt geen andere databases.
Maw, je investering zal desinvestering worden 🙁
P.s. wat ik je hierboven verteld heb, heb ik al eerder bij een klant meegemaakt.
@Reza en @Ewout,
Allereerst ging mijn betoog er om dat je moet proberen om applicaties die meerdere database-smaken ondersteunen te mijden. De discussie (waarvoor dank overigens) lijkt zich nu toe te spitsen op mijn advies voor een keuze voor een afwijkende (goedkopere) database.
Ik weet niet waar dat idee vandaan komt, maar ik suggereer nergens dat je dan maar een onbekende database moet nemen en zeker niet één die niet wordt ondersteund door de leverancier. Mijn advies is (en blijft) dat je in zulke gevallen zeker naar de goedkoopste variant moet kijken die wél wordt ondersteund. Als de leverancier geen voorkeur uitspreekt, waarom zou ik dan een duurdere nemen?
Tweede misverstand: een goedkope(re) database wil niet automatisch zeggen dat dit een obscuur iets is. Zoals Ewout hierboven aangeeft, wordt er in Oracle-bolwerken in dit soort gevallen automatisch een dure Oracle Db onder een standaardapplicatie gezet. Hoewel ik een groot fan van Oracle RDBMSen ben vind ik die oplossing in de meeste gevallen absurd, zelfs als het de standaardeditie betreft. Je zou in zo’n geval ook kunnen kiezen voor een Mysql, PostgreSQL of SQlServer variant. Allemaal prima (goed gesupporte) databases voor minder geld.
Mijn conclusie na jaren overwegen of je wel of niet meerdere databases moet ondersteunen is nu: doe het niet.
Redenen:
– Je maakt je applicatie nodeloos complexer
– Je gebruikt de betere features niet van de database
– Er zijn weinig omgevingen waar nog maar 1 smaak wordt gebruikt
Er zullen best nog voordelen voor zijn te noemen, maar voor mij wegen die niet tegen de nadelen.
@Leen,
In je profielbeschrijving lees ik dat Cloudcomputing and Interoperabiliteit je speciale interesse hebben.
Maar niet in een tiered/frontend/backend omgeving ?
😛
@Leen
Als eerste hangt natuurlijk veel af van je applicatie, als database niet meer is dan een ‘emmer’ dan kun je portabiliteit overwegen. Nadeel is wel dat alle logica dan vaak in de applicatie zit wat prestatie niet altijd ten goede komt. Zeker niet als deze van elkaar gescheiden zijn en alle queries over het netwerk gaan, soms flinke hoeveelheden packets die door de TCP/IP stack en over het draadje moeten.
Aan de andere kant zie ik ook nog weleens dat niet alleen een duur RDBMS gebruikt wordt doordat alle cores gelicenseerd moeten worden terwijl dat voor de prestatie helemaal niet nodig is, zeker bij Oracle gebeurt dit nog weleens of je moet hard partitioning gaan gebruiken.
Laten we nu – heel toevallig – een oplossing hebben waarbij de interconnect (in-memory of infiniband) voor een prestatie verbetering zorgt in communicatie tussen applicatie en database en hard partitioning voor lagere licentiekosten. Oja, doordat data-in-motion en data-in-rest volledig gecompartimeerd is – gecertificeerd tot EAL-4+ – worden ook nog veel beveiligingsproblemen met legacy databases en applicaties opgelost en kan één machine multitenant gebruikt worden met gegarandeerde prestaties.
Nieuwsgierig? http://www.slideshare.net/edekkinga/forward-unisys
@Ewout
Een wat commercieel getinte reactie van je.
De end-to-end response time van een applicatie hangt af van vele factoren. De RDBMS response tijd is daar maar een onderdeel van. Voor SAP is de RDBMS response time idealiter 40% van de totale RT. De RT van het RDBMS hangt verder af van de beschikbare resources en de snelheid daarvan en het storage subsysteem. (SAN of NAS). In de praktijk zie ik met 10GbE niet erg veel netwerk-related bottlenecks.
De bottlenecks die ik in de praktijk tegen kom hebben meestal te maken met simpelweg onjuiste parameter instellingen, bijvoorbeeld een database cache van 1 GB op een server met 60 GB RAM.
Oracle werkt met een variabele (CPU_COUNT) die de waarde krijgt van het aantal cores dat wordt aangetroffen. Vanuit deze variabele worden weer andere waarden afgeleid die bijvoorbeeld van belang zijn voor een andere belangrijke feature van Oracle : parallel query.
Een applicatie als SAP gebruikt Oracle als een “byte container”, maar dat maakt dit RDBMS nog niet meteen uitwisselbaar met een ander merk. Een volwassen RDBMS als Oracle heeft in de loop van de tijd heel wat zaken ontwikkeld die niet meer zijn weg te denken : het genoemde parallel query, een hele serie van compressie opties die werkelijk geld kunnen besparen, Automatic Storage management, maar ook build-in zaken als de file system cache bypass (direct en concurrent I/O), Write-protect, snapshots etc. etc. geven dit RDBMS een zekere robuustheid en betrouwbaarheid die je niet bij overige RDBMS-en ziet.
Als je perse geld wil besparen, vervang dan eerst je dure OS (AIX, HP, Solaris, MS) met Linux bijvoorbeeld of beter nog, gebruik een Linux Guest om je applicatie een virtueel onderkomen te geven. Gebruik verder een modern file system type (WAFL) met build-in snapshots bijvoorbeeld zodat je de ouderwetse tapes de deur uit kan doen.
Beste Jurrie,
Als software-ontwikkelaar bij TOPdesk kan ik je wel iets vertellen over hoe het is om een applicatie voor meerdere typen database te ontwikkelen.
Zelfs als je maar één merk database ondersteunt moet je al verschillende versies van dat merk ondersteunen, aangezien niet alle klanten tegelijkertijd nieuwe versies van de database installeren. Dus je hebt sowieso al een systeem nodig dat met meerdere versies van één merk database overweg kan. Daarmee wordt de stap naar verschillende RDBMS’en een stuk kleiner.
Verder zijn de kosten van het testen op verschillende databases, ongeacht of ze van hetzelfde merk zijn, slechts een fractie van de totale kosten van het hele ontwikkelproces. En de database is maar één van de variabelen. We kunnen als standaard-applicatie ook overweg met de diverse andere systemen die bij de klant aanwezig zijn. Denk aan verschillende typen en versies operating systems, mailservers en protocollen, proxies, authenticatiesystemen, koppelingen met diverse gegevensbronnen, browsers, etc. We zijn dit gewend.
Daarnaast zijn er ook andere voordelen voor de klant. We hebben al een aantal klanten gehad die eerst op één merk database wilde draaien, aangezien andere software dat vereiste, maar later die software had vervangen en een goedkoper RDBMS kon gebruiken. TOPdesk kan niet alleen met verschillende RDBMS’en overweg, maar kan ook probleemloos zijn database van het ene merk naar het andere merk converteren.
Tenslotte bieden we TOPdesk ook aan als SaaS-oplossing. In zo’n cloud-scenario is het merk van de database voor de klant niet of minder belangrijk. Doordat we meerdere RDBMS’en ondersteunen kunnen we daarbij dus voortdurend de beste oplossing kiezen.
Ik hoop dat ik hiermee een aantal misverstanden heb kunnen oplossen.
@KJ
Ik stel nergens dat een DBA of systeembeheerder vervangen kan worden, ik geef zelfs aan dat deze functies essentieel zijn en ik het een slecht idee vindt om te kiezen voor een database waarover geen kennis aanwezig is. Betreffende de genoemde prestatie problemen heb ik al meerdere opinies geschreven want inderdaad zijn de ‘next-next-finish’ inrichtingen niet altijd optimaal.
Aangaande je voorstel om dure platformen te vervangen geef ik je ook gelijk mede ook omdat hier nog vaak een ‘hands-off’ strategie gehanteerd wordt, niet zelden omdat DBA en systeembeheerder dus weg zijn bezuinigd. Oja, MS SQL draait naar mijn weten niet op Linux en ik denk dat je met legacy juist wilt voorkomen dat je alles in één keer moet wijzigen want olifanten eet je nu eenmaal hapje voor hapje.
@Ewout
Sorry, alleen de eerste zin was voor jou bedoeld, gezien je verwijzing naar de Unisys-link. De rest was een verdere verduidelijking gericht aan de auteur van het artikel.