Organisaties worden steeds meer uitgedaagd om meer te doen met minder middelen. Ze moeten innovatieve strategieën ontwikkelen, mooie producten creëren, klanten beter bedienen, en dat allemaal terwijl ze geconfronteerd worden met beperkte budgetten. Als reactie daarop zoekt het it-personeel naar efficiëntere manieren om hun it-stack te beheren om zo extra geld vrij te maken voor dit soort strategische initiatieven. Maar waar moet je beginnen?
Binnen de gemiddelde it-stack kan veel geld bespaard worden op de databasekosten. Zeker voor bedrijven die Oracle gebruiken, kan een (gedeeltelijke) migratie naar een open source database een praktische eerste stap zijn om in hun kosten te snijden. Uit onderzoek van Gartner is gebleken dat organisaties hiermee een besparing van 70 procent of meer te kunnen realiseren, zonder concessies te hoeven doen op het gebied van performance, technische ondersteuning of beheersoftware.
Door een aantal ingrijpende veranderingen in het licentiebeleid van Oracle is het migreren naar een open source database zoals Postgres nog aantrekkelijker geworden voor Oracle-klanten. Oracle verving namelijk zijn populaire SE-database-licentie door een nieuwe licentie genaamd Oracle SE2. Die zou veel van de huidige SE-gebruikers ertoe kunnen dwingen om nieuwe hardware te kopen, applicaties te herconfigureren of anders een lagere performance te accepteren. Het is daarom goed mogelijk dat meer bedrijven dit moment zullen aangrijpen om een migratie van Oracle naar open source te overwegen.
Migratieplanning
Een databasemigratie klinkt misschien als een zware klus, maar dit zou niet direct reden moeten zijn om ontmoedigd te raken. Als je het proces opsplitst in de volgende stappen, dan wordt het al een stuk makkelijker. De migratie zelf is vaak nog het eenvoudigste deel van het proces, tenminste als je eenmaal een algemene strategie hebt bepaald.
• Prioriteer de juiste applicaties voor migratie. Maak een inventarisatie van de bestaande toepassingen die gebruik maken van je bestaande Oracle-database. Veel hiervan zullen standaard commerciële toepassingen zijn, zoals erpasaq-systemen van SAP en Salesforce. Deze moet je negeren. Die applicaties kunnen uit technisch oogpunt wellicht met open source databases werken, maar het is mogelijk dat de leverancier van de toepassing dit niet officieel ondersteunt. Het is daarom het beste om je bij de migratie in de eerste plaats te richten op zelf ontwikkelde maatwerktoepassingen.
• Zorg voor medewerking van het applicatieteam. Het is heel belangrijk om voorafgaand aan de migratie samenwerking te zoeken met degenen die de meeste kennis hebben van de toepassingen die gemigreerd zullen worden. Hun kennis is immers van groot belang in het geval er kleine wijzigingen in de code of de applicaties nodig zijn. Afgezien daarvan zal het sowieso noodzakelijk zijn om met een team te werken met de benodigde vaardigheden en opleiding om het migratieproces in goede banen te leiden.
• Hanteer een gefaseerde migratieaanpak. Migreer niet alle toepassingen tegelijk. Als er eenmaal een eerste groep applicaties gedefinieerd is, blijf de groep dan verder verkleinen, totdat er een groep overblijft die het gemakkelijkste en snelste te migreren is, maar wel de meest besparing oplevert. Door deze eerste applicaties te migreren, krijgt het team meer gevoel bij het gebruik van een open source database, en worden hun vaardigheden op dit gebied verbeterd. Vanaf dat moment kan de migratie van de resterende apps gepland worden op basis van complexiteit en roi. Daarbij is het van belang om een analyse te doen, die antwoord geeft op alle vragen rond potentiële incompatibiliteit.
• Deel de migratie op in stukken. Migreer de schema’s en object-definities eerst om ervoor te zorgen dat er geen mogelijke storingen kunnen optreden die vervolgens tot dataverlies kunnen leiden. Als er toch storingen optreden, zorg dan voor workarounds, voor zover die mogelijk zijn. Daarna kan de datamigratie van start gaan. Er zijn meerdere manieren om die uit te voeren, maar dat is sterk afhankelijk van de specifieke situatie binnen een organisatie en het tijdspad dat voor het project is bepaald.
Bijzondere gevallen
Voor alle duidelijkheid: migreren van Oracle naar een open source database is geen sinecure. Er kunnen immers altijd zaken zijn die handmatig opgelost moeten worden. Leveranciers van enterprise open source-databases bieden echter oplossingen aan die een migratie kunnen vergemakkelijken. Het is ook mogelijk dat een specifieke functionaliteit van Oracle niet in een open source database wordt ondersteund. In de praktijk blijkt dit echter maar een klein deel van de workloads te betreffen. Voor het overgrote merendeel is een migratie wel mogelijk, en dit kan dus zo’n 70 procent aan kostenbesparing opleveren. Dit moet elke organisatie als muziek in de oren klinken. Zeker als het betekent dat het vrijgekomen budget ingezet mag worden voor nieuwe technologie en innovatie.
Om maar even heel ongezouten te zeggen. Als je van Oracle naar een OS database kan migreren dan had je het eigenlijk niet nodig gehad. Oracle gebruik je als het echt nodig hebt. Zoals een vrachtwagen voor grote vrachten, een landrover voor als je door de bush bush moet of een F1 als je een paar uur heel hard moet rijden. Niet voor een ritje naar de supermarkt.
Maar er zullen zat bedrijven zijn die of voor de degelijke naam en/of de zo goed luisterende verkoper gegaan zijn.
Maar als je toch Oracle gebruikt en maatwerk op hebt toegepast (met bijv. PL/SQL, materialized views etc) let dan even heel goed op of je niet maatwerk met het badwater weggooit en wat met die andere database niet kan of veel lastiger is.
Aan te bevelen is om ook de performance te checken of die niet verslechtert en als dat goed gaat je meer zekerheid hebt bij een overstap. Want Oracle is niet alleen in aanschaf maar ook in het onderhoud niet goedkoop. Maar dat is met bijna elke specialistische software niet anders.
Bedankt voor je reactie, Johan. Tegenwoordig zijn er op basis van Postgres ook oplossingen beschikbaar die juist in staat zijn om het Oracle-maatwerk in de database(zoals stored procedures en triggers) grotendeels naar Postgres te migreren. Met een eenvoudig onderzoek kun je vrij snel inzichtelijk maken hoeveel van deze Oracle maatwerkcomponenten zonder aanpassingen overgezet kunnen worden. Tevens zijn er zogeheten Oracle compatibility layers beschikbaar, die je in staat stellen om native PL/SQL tegen Postgres te spreken, waardoor je een PL/SQL-applicatie niet hoeft te herschrijven. Eenvoudiger kan het eigenlijk niet worden. Deze mogelijkheden hebben al diverse grote Oracle-gebruikers doen besluiten een deel van hun databases (of soms zelfs alle) naar Postgres te migreren. Persoonlijk denk ik dat dit een begin is van een enorme shift in database-land, vergelijkbaar met wat we eerder in de open source-markt gezien hebben met de opkomst en het uiteindelijke leiderschap van Linux.
Veel applicatieleveranciers ondersteunen alleen een aantal DB-leveranciers (zoals MS SQL, Oracle etc). Hoe ga je dit oplossen als je weet dat je geen support van je applicatieleverancier krijgt als je naar dit type DB migreert?
Op dat vlak is er zeker nog een slag te slaan in de markt voor standaardapplicaties. Toch merk ik in mijn dagelijks werk dat er steeds meer applicatieleveranciers overstappen naar Postgres, simpelweg voor de lage TCO en de kwaliteit van de database. Een mooi voorbeeld hiervan is Infor (de eigenaar van het voormalige Baan). Er kan absoluut nog het nodige verbeterd worden, maar daarbij moet je de kracht die je klant hebt ook niet onderschatten. Er zijn nog veel bedrijven en applicatieleveranciers die gewoonweg niet weten welk kwaliteitsniveau een open source database als Postgres heeft bereikt (of ze hebben er helemaal niet eens van gehoord). Maar als je als klant niet je voorkeur of wens uitspreekt om Postgres te gaan gebruiken, dan zal er ook geen ‘sense of urgency’ zijn bij de applicatieleverancier zijn om Postgres te gaan ondersteunen.
In het artikel van de heer Bos staat niets dan de waarheid over migraties van Oracle naar Postgres, maar ik mis een essentieel onderdeel, t.w.:
• Iedere applicatie is uniek. Een “one size fits all” gaat niet op. Zorg dat je daar op voorbereid bent! Alleen de database en de eventuele code in de database migreren betekent nog niet dat je de applicatie hebt gemigreerd…hoe om te gaan met de user interface als de klant bijvoorbeeld Forms gebruikt? En zo zijn er nog veel meer smaken waar potentieel rekening mee dient te worden gehouden. Uiteraard is veel/alles oplosbaar.
• Veel zaken kunnen inderdaad van Oracle naar Postgres worden gemigreerd, maar wil je dit goed doen dan dien je op de hoogte te zijn van de specifieke eigenschappen van beide omgevingen om ook de juiste keuze te maken om optimaal van Postgres gebruik te maken. Er zullen veelal specifieke zaken overblijven die niet automatisch kunnen worden gemigreerd, maar die handmatig dienen te worden aangepast in relatie tot de gewenste werking van de betreffende applicatie, geen probleem maar wees er duidelijk over.
In de reactie van de heer Bos op de reactie van de heer Duinkerken wordt mijns inziens ook een essentieel onderdeel weggelaten die ik hier toch wil meegeven:
• Met het noemen van het gebruik van zogenaamde Oracle Compatibility Layers moet je goed uitkijken. Mijn ervaring is namelijk dat je dan van de ene vendor lock-in in de andere terechtkomt. De Oracle Compatibility layer is namelijk geen Open Source en dat is toch de onderliggende essentie van het stuk. Stap over naar Open Source.
Het migreren van Oracle applicaties met Postgres als Open Source database en daarbij rekeninghouden met de totale architectuur is absoluut te doen, maar zorg dat je daadwerkelijk weet waar je mee bezig bent en last but not least…voorkom een nieuwe vendor lock-in!
Het is een goede zaak om de discussie rondom “enterprise ready” open-source databases levend te houden. Wij zien dat het de relationele database een logische volgende stap is in het gebruik van open-source producten, maar wij zien ook dat er veel angst, onzekerheid en twijfel (FUD) bestaat om Postgres te gaan gebruiken of ernaar over te stappen
Postgres is een volwaardige relationele database die ingezet kan worden als tegenhanger van Oracle. In de kosten zit het grote verschil, ten voordele van Postgres. Heb ik dan ook support, is een veel gevraagde vraag van organisaties die interesse hebben om Postgres te gaan gebruiken. Het antwoord hierop is volmondig ja! EnterpriseDB is een organisatie die support levert op Postgres, goed vergelijkbaar met support op de Oracle database. Is er een vendor lock-in als ik support afspreek op Postgres? Nee, er zijn meer partijen die support op Postgres bieden, dus als EnterpriseDB als support leverancier niet bevalt, kan een switch gemaakt worden naar een andere support partij.
Indien een support abonnement afgesloten wordt bij EnterpriseDB, dan biedt EnterpriseDB, zonder extra kosten, tooling op allerlei gebied. Een voorbeeld hiervan is de Oracle comptabiliteitslaag. Het gebruik van deze tools is een vrije keuze. Vaak is er een alternatief te vinden al dan niet open-source. Dus is er dan sprake van een vendor-lockin als je tools gebruikt van EnterpriseDB? In mijn ogen niet. Vendor-lockin heeft niets te maken met al dan niet open-source maar met een gedwongen keuze voor één leverancier. En ook met het gebruik van de tooling is dit niet het geval.
EnterpriseDB is de enige Postgres leverancier die gepositioneerd is in het Leader kwadrant van Gartner, mede vanwege de kwaliteit van het support en de tooling. Tooling zoals de Oracle compatibiliteitslaag en performance verbeteringen. Hierdoor zien we dat EnterpriseDB een keuze is voor bedrijven die een alternatief voor Oracle zoeken en daarbij support willen hebben.
Als blijkt dat een organisatie pijn heeft aan Oracle omdat bijvoorbeeld de kosten en het budget niet meer met elkaar te verenigen is, is dit meestal geen probleem dat men wil oplossen op de langere termijn, maar zulke problemen spelen vaak in de komende maanden of jaar. Daarom wil men ook naar een oplossing die te realiseren is in weken of maanden. Het antwoord hierop kan de Oracle compatibiliteitslaag zijn van EnterpriseDB. Hierdoor kan snel een migratie plaats vinden van Oracle naar Postgres waarbij er een goede prijs-kwaliteitverhouding is en een korte doorlooptijd. Of Postgres met de Oracle compatibiliteitslaag een eindstation is, is ook een keuze. Men kan daarna altijd kiezen om uiteindelijk te migreren naar native Postgres zonder compatibiliteitslaag. Door in eerste instantie snel te migreren naar Postgres met Oracle compatibiliteit worden kosten bespaard.
Het succes van de migratie hangt natuurlijk van een aantal factoren af. Als men naast de Oracle database ook gebruik maakt van de Oracle ontwikkeltools of als men gekochte applicaties heeft, en dus te maken heeft met applicatieleveranciers, wordt een migratie complexer. In de markt zien we ook hierop steeds meer antwoorden, zoals het migreren van Oracle forms naar Java (inclusief Postgres als nieuwe database). Maar het overgrote deel van de Oracle databases wordt gebruikt zonder deze zaken en kunnen dus uitstekend gemigreerd worden.
Natuurlijk brengt de migratie kosten met zich mee en is een support abonnement niet gratis. Maar deze kosten zijn snel terugverdient als men ze afzet tegen de kosten die men maakt voor de Oracle database. Die rekensom is snel gemaakt.