Is Microsoft toevallig een nieuwe marketingcampagne gestart? We kregen recentelijk van twee klanten het verzoek om hun huidige Oracle systemen te migreren naar het Azure-platform. Hoe gemakkelijk is zo’n migratie eigenlijk? Dankzij onze manier van ontwikkelen wellicht makkelijker dan je zou denken.
Gelaagde infrastuctuur
We hebben veel webapplicaties op maat ontwikkeld met Oracle of andere databases als basis. Onze maatwerk software bestaat vaak uit drie verschillende lagen: een frontend gebouwd met HTML, JavaScript en CSS; een backend API; en een database. Wij richten onze applicaties zó in dat ze niet afhankelijk zijn van de gebruikte technieken. Hieronder bespreken we per onderdeel hoe we deze onafhankelijkheid bereiken.
De frontend
In de frontend draait alles om het gebruiksgemak. De interface moet makkelijk te gebruiken en goed toegankelijk zijn vanaf Desktop, Tablet en Mobiel. Waar en hoe data opgeslagen wordt is voor de frontend niet van belang: er moet alleen een punt zijn waarop de data toegankelijk is. Hiervoor gebruiken wij API-aanroepen in de backend. De frontend verzoekt deze API dan bijvoorbeeld om data voor het tonen van een “Gebruikersprofiel”. Het enige dat de frontend dan hoeft te weten is de juist API aanroep, bijvoorbeeld onder “/user/get”
API diensten
De API is de communicatielaag tussen de frontend en de data. Vaak bouwen wij deze API in Java of PHP. Een API hoeft ook niet veel te weten van een databasestructuur. Wij geven de API instructies om de database te bereiken, maar niet veel meer dan dat. Zo hoeft de API bijvoorbeeld niet te weten in welke tabellen de data opgeslagen is. We proberen het gedrag van de applicatie te onderbouwen met behulp van methodes. Bijvoorbeeld “Gebruikersprofiel opslaan” of “Gebruikersprofiel lezen“. Deze hoeft alleen maar te “weten” welke informatie (naar ons voorbeeld) in een “Gebruikersprofiel” is opgeslagen. Misschien een gebruikersnaam, telefoonnummer, profielfoto en een adres.
Database (gegevensmodel, opgeslagen procedures, triggers en beperkingen)
De Business Logic bevindt zich in de database, omschreven in stored procedures, triggers en constraints. Triggers en constraints zijn een simpele maar effectieve manier om de kwaliteit van de data te bewaken, door bijvoorbeeld er voor te zorgen dat een gebruikersnaam uniek is. Stored procedures kunnen een stuk complexer zijn. Zij zijn nog nuttiger, omdat ze een serie gekoppelde acties kunnen uitvoeren op veel verschillende databasetabellen. Ze zijn gebouwd rondom het gegevensmodel, dus als veranderingen in het datamodel tot onregelmatigheden leiden zien we dat gelijk terug in de procedures. Dit maakt het een stuk makkelijker om de business logic te onderhouden.
Makkelijk te onderhouden
Over onderhouden gesproken: doordat BSL bovenstaande lagen zoveel mogelijk gescheiden houdt, is het eenvoudig om onderhoud en updates uit te voeren voor onze webapplicaties. We kunnen het hele datamodel met bijbehorende stored procedures veranderen zonder dat dit invloed heeft op de frontend. En andersom kunnen onze ontwikkelaars aanpassingen doen in de frontend zonder op de hoogte te zijn van het datamodel. Helaas nemen we soms applicaties over van andere developers waar deze gelaagde infrastructuur niet gebruikt wordt. Dan vinden we bijvoorbeeld database code (“SQL-code“) terug in de JavaScript of PHP code. Een nachtmerrie om te onderhouden, wat voor hogere onderhoudskosten voor onze klanten zorgt!
Wat betekent dit voor de migratie van Oracle naar Azure SQL Server?
We zijn bekend met programmeren in Oracle SQL (PL/SQL), MySQL Stored Procedures (beperkt in vergelijking met Oracle), en in Azure SQL (Transact SQL). We hebben Transact SQL zelfs al gebruikt voordat Microsoft het in gebruik nam voor hun SQL Server. Het komt namelijk voort uit Sybase, een andere database waar we mee gewerkt hebben.
Door onze gelaagde architectuur kunnen we bij de migratie de impact op de frontend beperken. Technisch gesproken kunnen we de ene database vervangen met de andere zonder de frontend aan te hoeven passen. De API moet natuurlijk wel worden bijgewerkt om te vertellen waar de data nu vandaan gehaald moet worden. Maar omdat onze database libraries kunnen werken met verschillende databases zijn er verder vrij weinig aanpassingen aan de API nodig.
De migratie van Oracle naar SQL
Op dit moment zijn we druk bezig met de migratie van een Oracle 12 database applicatie naar Azure, namens een bank. Aan het eind van deze migratie draait de database niet meer op een server in hun beheer. In plaats daarvan komt alle data in een Azure Cloud SQL database. Voor de klant betekent dit lagere onderhoudskosten, betere beschikbaarheid en schaalbaarheid en beveiliging.
We moeten meer dan 20.000 regels PL/SQL code vertalen, gebruikt in 200+ stored procedures. Een hele uitdaging, ook omdat sommige gebruikte datatypes helaas niet bestaan in SQL Server. Maar wat is het leven zonder een uitdaging of twee!
Het goede nieuws: we liggen op dit moment op schema. We verwachten het project binnen acht weken af te ronden. In ons volgende blog vertellen we je meer over hoe we dit gaan bereiken en welke tools we hierbij gebruiken.
Volgende week: Deel 2 van dit blog.
Neem contact op
Heeft u plannen om te migreren naar Azure, of een van de andere databases waar wij mee bekend zijn? Neem contact met ons op! Laat ons u informeren. Wellicht kunnen we van dienst zijn. U kunt te allen tijde contact opnemen met onze klant relatiemanager. Zij kan een online meeting opzetten om van gedachten te wisselen.
