nlOUG Visie kersteditie 2021

Page 1

ViSIE WINTER 2021 - JAARGANG 27 - NUMMER 3

IT-AUTOMATION EN OCI IN EEN ’BROWNFIELD’ SITUATIE

IS ER NOG EEN DBA NODIG IN DE CLOUD?

DBA-DAG IN APRIL LIVE OP SS ROTTERDAM


Qualogy Managed Services Zoekt u een partner die flexibel

Onze expertise:

invulling kan geven aan uw behoeften

• Oracle hardware, zoals Oracle

op het gebied van IT-beheer, technisch of functioneel? Qualogy vult deze behoefte graag voor u in. Wij helpen u met het waarborgen van de

Database Appliance • Oracle Database-technologie: tot meest recente versie • Oracle Fusion Middleware:

continuïteit en betrouwbaarheid van

WebLogic Java EE | Service

uw bedrijfsapplicaties. En adviseren u

Bus | SOA Suite | ADF | OBIEE |

voor nu en in de toekomst. Kom met

Forms & Reports | EBS

ons in contact en laat u inspireren!

• Cloud en cloud-migraties, waaronder Oracle-cloud en Azure-cloud

De Bruyn Kopsstraat 9 | 2288 EC Rijswijk (ZH) 070 319 50 00 | info@qualogy.com

Q UA LO GY.CO M


INHOUD

VOORWOORD

Geachte lezer,

|

3

Z

o, dat was me het jaar wel weer… 2021. Na een zwaar 2020 begon 2021 niet veel beter. Alles moest virtueel - werken, vergaderen, meet-ups en conferenties. Helaas moesten we ook APEX World uitstellen en over de zomer heen tillen. Maar gelukkig kwam van uitstel geen afstel. Ik ben enorm blij dat we weer een echte in-person event konden neerzetten voor jullie en ik ben heel erg trots op iedereen die dit mogelijk heeft gemaakt. Het was een succes, en dat smaakte naar meer!

IT Automation en OCI Wat hadden we zin om de DBA-dag te organiseren. De voorbereiding liep op rolletjes, maar opnieuw gooide COVID-19 roet in het eten. De DBA dag moest helaas worden uitgesteld en staat nu op de agenda voorapril 2022. Ik ga er van uit dat we tegen die tijd weer een conferentie kunnen organiseren zoals we dat gewend zijn uit het verleden. Dit doen we uiteraard voor onze leden (jullie dus), maar wij merken dat het steeds lastiger wordt om de echte verbinding met jullie in stand te houden. Het aantal leden loopt terug, net als het aantal bezoekers van meet-ups en andere events. Deze trend is al een tijdje zichtbaar, maar de afgelopen twee jaar is dit sterker geworden. Voor 2022 willen we dit graag omdraaien en willen we als usergroup weer groeien. Dat kan alleen maar als we onze (potentiële) leden weer kunnen bereiken. We hebben een aantal prima ideeën en initiatieven die ons kunnen helpen om dit doel te bereiken, en daar ga je komende maanden meer van zien. We kunnen dit echter niet alleen. We doen dit voor de community en de community dat zijn jullie. Jullie weten het beste wat er nodig is, waar je blij van wordt en hoe we dat kunnen bereiken. Daarom zijn we op zoek naar mensen die ons kunnen helpen. Dit kun je doen door je beschikbaar te stellen als bestuurslid, maar uiteraard mag je ook altijd via mail of social media je ideeën delen.

Luc Bors Voorzitter

Ik wil graag afsluiten met het uitspreken van dank naar iedereen die afgelopen jaar, in welke vorm dan ook, een bijdrage heeft geleverd aan de activiteiten van de nlOUG; leden en toehoorders, organisatiecomités, onze backoffice bij BMO, iedereen die ik vergeet en last but not least onze trouwe sponsoren.

in een ‘brownfield’ situatie 4 Doet Bijna Alles

9

There is no MAA without ZDLRA

10

Is er nog een DBA nodig in de (Autonomous) Cloud?

11

Ontwikkelingen in en rond OCI 15 DBA-dag in april live op SS Rotterdam

17

Nederlandse Oracle User Group - nlOUG

Ik wens jullie allemaal fijne feestdagen en een gezond 2022!

COLOFON REDACTIE Hans Gerritse (hoofdredacteur) Learco Brizzi (Itium BV), Luc Bors, Job Oprel (Qualogy) REDACTIEADRES/ SECRETARIAAT / ADVERTENTIEEXPLOITATIE Nederlandse Oracle User Group Emmaplein 10 1075 AW Amsterdam T +31 30 6997065 E secretariaat@nloug.nl REALISATIE MAT ONTWERP, BNO, Den Haag E maya.timmer@gmail.com ORGANISATIE / nlOUG-SECRETARIAAT/ ADVERTENTIE-EXPLOITATIE BMO B.V., Amsterdam T +31 30 6997070 E info@bmowerkt.nl BESTUUR nlOUG Luc Bors (voorzitter) E l.bors@nloug.nl Theo Veltman (penningmeester) E t.veltman@nloug.nl Job Oprel (secretaris) Qualogy E j.oprel@nloug.nl Yvonne Bakx (bestuurslid) iAdvise nlOUG VISIE is een uitgave van de Nederlandse Oracle User Group (nlOUG) en wordt verzonden aan al haar leden en overige abonnees. AANMELDEN voor een abonnement kan via www.nloug.nl. © 2021 nlOUG


4

|

IT-AUTOMATION EN OCI

DOOR RICHARD DUIM

IT-AUTOMATION EN CLOUD-TECHNOLOGIE IN EEN ‘BROWNFIELD’ SITUATIE Voor wie te dealen heeft met een situatie waarin ‘legacy’-applicaties part-of-life zijn en ‘cloud native’ geen optie is. Ook in die situaties hoeft het toepassen van ITautomation en Oracle Cloud-technologie geen belemmering te zijn.

ViSIE

I

k ben erg enthousiast over de mogelijkheden die IT-automation met zich meebrengt. In combinatie met de Oracle Cloud Infrastructure wordt het mogelijk de volledige stack geautomatiseerd te provisionen. Onder IT-automation versta ik overigens de omslag naar een beheerwerkwijze waar het applicatielandschap (incl. de onderlagen) door software wordt aangemaakt en onderhouden. Verbreding en verdieping

Terecht of niet terecht: het is als beheerder in eerste instantie vreemd om je jarenlange erva-


IT-AUTOMATION EN OCI

|

5

Het belangrijkste is beginnen, kies een pragmatische aanpak en durf fouten te maken.

ring ‘weg te automatiseren’. Zelf heb ik eerlijk gezegd iets anders zien gebeuren. Verbreding en verdieping van beheer-skills, het delen van ervaring tussen beheerders om tot de best practice te komen en vervolgens het uitrollen van die aanpak over klanten en omgevingen heen. Een van de effecten: alle beheerders, binnen hun discipline, zijn inzetbaar op alle omgevingen en klanten. Er was wel behoorlijk wat voor nodig om zover te komen. Ons werk speelt zich namelijk niet af in een greenfield situatie. De Oracle-applicatie die we voor onze klanten als SaaS-oplossing aanbie-

den kent geen microservices, docker containers of feature-toggles. In tegendeel, de applicatie is vergroeid met de Oracle database, maakt gebruik van Oracle Forms en het fenomeen batchverwerkingen is springlevend. Hoe ga je in zo’n situatie de voordelen verzilveren die IT-automation belooft? Het belangrijkste is beginnen, kies een pragmatische aanpak en durf fouten te maken. We beheren een unieke applicatie, maar deze ‘brownfield’ situatie is niet uniek. Ik wil de ervaringen en afwegingen van Truston op een klein onderdeel van deze ontdekkingstocht delen: het uitvoeren van IT-automation code-releases. Het is misschien een open deur, maar DevOps is zo’n gekke term nog niet. Beheerders zijn (ook) developers geworden. En developers schrijven code én releasen. Zonder release geen wijzigingen, zonder wijzigingen geen waarde voor de klant. Drie sporen

Vrij snel werd ons duidelijk dat er om de volledige stack te automatiseren meer IT-automation oplossingen nodig zijn. We hebben drie sporen gedefinieerd: infra, application-landing zone en application-deployment. Het infra-spoor maakt (inmiddels) gebruik van Oracle Cloud Infrastructure en wordt volledig met Terraform gemanaged. Vervolgens gebruiken we Puppet om software, ViSIE


6

|

IT-AUTOMATION EN OCI

rdbms en middleware te beheren, dit vormt de application-landing zone. Boven op die basis werkt het application-deployment met Jenkins waar we de dataset, de ERP-applicatie en de applicatieconfiguratie mee uitrollen. Met de drie sporen in het achterhoofd hebben we de beheer-workload in de ‘oude’ situatie geanalyseerd. Conclusies: a. Ieder spoor kent een eigen frequentie/cadans waarin wijzigingen naar productie gaan. We deployen nu eenmaal vaker een stukje software (application deployment) dan dat we een nieuwe netwerkzone of VM aanmaken (infra). En nog belangrijker, we moeten voorkomen dat de wijzigingen op het ene spoor de andere hinderen. b. Daarnaast heeft niet iedere wijziging eenzelfde impact. Een rdbms-upgrade kent nu eenmaal meer risico’s, voorbereidings-, test- en dus ook doorlooptijd dan het toevoegen van een OS-user, wat we al veel vaker op eenzelfde manier hebben gedaan. Laten we het benoemen als eenvoudige vs complexe wijzigingen. Uiteraard komen eenvoudige wijzigingen veel vaker voor (typisch voor beheeractiviteiten) dan complexe wijzigingen. Conclusie: Wijzigingen (en dus ook code releases) variëren qua cadans en risico. De wens om vanuit de drie sporen onafhankelijk van elkaar te kunnen releasen was eenvoudig te realiseren: Doordat we drie IT-automation- oplossingen gebruiken voor elk spoor (Terraform, Puppet en Jenkins) is dat geregeld. Genuanceerder

Voor de variatie in risico lag dat wat genuanceerder: Terraform en Puppet kennen beide een werkwijze om de logica en de configuratie (parametrisering van die logica) te scheiden. Denk bij logica aan: wat is de blauwdruk voor het koppe-

ViSIE

len van filesystems aan een database-server, wat zijn de mount points, naamgeving, disk names enzovoort. De configuratie geeft input aan die logica, dus bijvoorbeeld voor welke klant en welke omgeving roep ik die blauwdruk aan. Ons uitgangspunt is dat we voor het uitvoeren van eenvoudige wijzigingen niets aan de logica hoeven aan te passen, het moet beperkt blijven tot een user toevoegen aan een lijstje. Maar daarmee zijn we er nog niet, we moeten in staat zijn om configuratie en logica onafhankelijk van elkaar te releasen. Dat introduceert natuurlijk wel wat complexiteit in versiebeheer (meerdere repositories en/of branches). Het projectteam had een beperkte omvang, met ervaren (externe) en onervaren interne ontwikkelaars. Om de leercurve niet te stijl te maken hebben we tijdens de projectfase de meest eenvoudige werkwijze gekozen. Geen onderscheid tussen het releasen van configuratie en logica. Daarmee blijft de feedbackloop klein. Nadelig gevolg: de scheiding configuratie en logica


IT-AUTOMATION EN OCI

hebben we in sommige situaties in de beheerfase aan moeten brengen doordat blauwdruk en configuratie minder strikt gescheiden bleken dan gewenst. Hebben we spijt van deze keuze? Zeker niet. De grootste impact is de cultuurverandering en werkwijze binnen het beheerteam. Het is vervelend, maar de clichés kloppen. Dus het verlagen van drempels om het team mee te krijgen in de verandering is prima, maar geef nadien wel de ruimte de inhaalslag alsnog te maken.

|

7

Meer uitstel leidde tot meer code-wijzigingen en daarmee werd het water steeds kouder.

Externe toezichthouders

Onze klanten bevinden zich in een branche waarin externe toezichthouders een belangrijke rol spelen. Nieuwe versies van de applicatie, applicatie-inrichting en landschap-aanpassingen lopen door een OTAP-straat met een cadans van twee weken. Niet erg agile, maar het is de praktijk waar we mee dealen. De codewijzigingen vanuit de drie IT-automation sporen moet dus inhaken op die OTAP-straat. In de ideale wereld zouden we iedere wijziging vanuit onze DevOps teams, zonder bundeling in releases, naar productie laten stromen. De realiteit is echter dat vrijgave voor in productie met name afhankelijk is van bijvoorbeeld functionele applicatietests. De tests worden deels handmatig in de GUI van de applicatie uitgevoerd en maken bijvoorbeeld gebruik van batchverwerking. inclusief de daarbij bijbehorende complexiteit van testautomatisering. Daarnaast hebben wijzigingen in de IT-automation stack regelmatig impact op onderdelen buiten onze invloedsfeer (denk aan ketenpartijen en het applicatielandschap van de klant). Een wekelijkse IT-automation release naar productie is op dit moment in deze omstandigheden het hoogst haalbare. Natuurlijk hebben we ook fouten gemaakt. We hebben ons, na de initiële projectfase, laten verleiden om enige tijd geen releases naar productie uit te voeren. Een klassieker. De kern van het probleem: een aantal grote wijzigingen in combinatie met businessplanning. Kortom koudwatervrees. Het niet doorvoeren van die spannende wijzigingen werd op termijn blokkerend omdat nieuwe wijzigingen er afhankelijk van werden. Meer uitstel leidde tot meer code-wijzigingen en daarmee werd het water steeds kouder. We hebben dit uiteindelijk weten te doorbreken door een sprint vrijwel volledig te wijden aan het op gang brengen van de release. De les: ‘Release

die code!’ en als er twijfel is neem die weg, dat is de kern van het probleem. Voer aanvullende tests uit. Maar hoe dan ook, stel niet uit. Verder is een belangrijke les: besteed aandacht aan het inzichtelijk maken van de impact van code-wijzigingen, als DevOps engineer heb ik de verantwoordelijkheid om niet alleen de wijziging aan te brengen maar ook de impact van de inproductiename in beeld te brengen. Per codewijziging is dit namelijk prima te overzien, maar van zeg 100+ wijzigingen wordt dit een veel te complex geheel. Als derde maatregel hebben we een strikte wekelijkse release-cadans ingevoerd, overslaan is geen optie. En mochten er issues optreden gedurende de release-cadans dan geldt: fix what is broken. We gaan niet uitstellen, we ronden af. Conclusie

Zijn we tevreden? We zijn in staat nieuwe klanten op uniforme wijze aan te sluiten. We lossen problemen nu éénmalig in de code op en passen die toe op alle klanten en omgevingen. We nemen relatief eenvoudig nieuwe OCI-componenten gestructureerd in gebruik. Besparen compute-kosten door geautomatiseerd up/down-time schema’s toepasbaar op alle omgevingen. Dus een volmondig ja. Zijn we klaar? Zéker niet. Om maar wat te noemen: Er zitten nog behoorlijk wat handmatige stappen in ons releaseproces, nog niet al onze collega-beheerders schrijven code, we zien kansen om standaard taken te automatiseren. En we willen natuurlijk de release-cadans verhogen. n Richard Duim is Chief Architecture Owner en Projectmanager bij Truston.

ViSIE


Meet The DOC

Your Oracle APEX Partner WHERE BUSINESS MEETS IT

Managed Services Application Development Business Analytics Consulting Oracle Cloud Oracle APEX

Tailored Software Solutions? MEET THE DOC Tel. +31 (0)85 002 1831 E-mail: info@thedoc.nl Weert - Langbroek


COLUMN

|

9

DOET BIJNA ALLES

S

tel: er zijn geen DBA’s. Stel. Niemand om de schuld te geven van performance-verlies, of aan te merken als vertragende factor in het developen van wéér een briljante applicatie. Maar ook niemand die

kan helpen met het versnellen van die applicatie c.q. robuuster of hoog beschikbaar te maken. En wie gaat er zijn bed uit om een database met de kostbare data weer te repareren omdat er een crash is geweest, of een foute release. Ik ben opgegroeid in de tijd dat de DBA nog alles bepalend was bij het in beheer nemen van een relationele database. Destijds begeleid/getraind

Job Oprel

door een academisch geschoolde DBA, die alles al had meegemaakt, en waarbij developers bang waren om binnen te komen en een vraag te stellen. Het risico was namelijk groot dat je doorgezaagd werd als developer waarom hij/zij dit nu eigenlijk wilde, en waarom het niet paste in het datamodel, of waarom het script niet zou performen e.d.

Ik roep van deze plaats op om één dag per jaar uit te roepen tot de ‘dag van de DBA’!

Goed bedoeld, en je kreeg een gratis les hoe het wel zou moeten, maar de manier waarop was niet bevorderlijk voor het imago van de DBA en de communicatie met het project of release. Om niet te spreken van de andere DBA’s die met ontzag (en vooruit, met een beetje angst) naar deze senior opkeken. DBA’s hebben hun imago niet altijd mee (‘koppig, onbuigzaam’), doen hun werk in de achtergrond, en veel IT-ers weten niet echt wat het vak van een DBA inhoudt. Maar, zoals Bob Dylan al wist te melden: ‘The Times They Are A-Changin’... Er lijkt wellicht een kentering gaande. Door het agile werken, en het opkomen van DevOps lijkt het erop dat men er achterkomt dat er tijdens de sprints ook kennis en ervaring van een database en infrastructuur/ cloud nodig is, en dat je niet alles kan overlaten aan Developers, hoe slim ook. DBA-ers voegen wat toe – zij zijn het verbindende stukje tussen het project en het beheer. Niet elke DBA-er is daar overigens geschikt voor, en sommige DBA’s moeten zich opnieuw uitvinden, en soms groeit een Developer uit tot een DBA-achtige. De werkzaamheden van de ouderwetse ‘classic’ DBA zullen dan ook verschuiven en in beide stromingen, classic of niet, zal het technische ontwikkel- en beheerplatform zich steeds meer richten op de cloud. En de scope beperkt zich niet alleen tot relationele databases, maar zal zich ook richten op andersoortige databases en op de software die de database bestookt. Kortom, de DBA staat niet voor niets voor ‘Doet Bijna Alles’. Hoe het ook zij, de DBA zal nodig blijven. En het viel me op dat voor veel zaken een dag in het jaar is uitgeroepen, zoals ‘dag van de vrijwilliger’, ‘dag van de vrachtwagen-chauffeur’ etc. Maar... nog geen erkenning voor de DBA. En dat moeten we toch kunnen veranderen? Hierbij roep ik dan ook van deze plaats op om één dag per jaar uit te roepen tot de ‘dag van de DBA’! Of - excuus - moet dat de ‘dag van de Oracle DBA’ zijn?

ViSIE


10

|

NO MAA WITHOUT ZDLRA

DOOR FERNANDO SIMON

THERE IS NO WITHOUT

MAA ZDLRA

I will start with some questions: Do you know your environment? Which kind of database do you need to support at this exact moment? What is the SLA in case of outage for those databases? In case of an outage, all of them have the same RPO (Recovery Point Objective)? What is the cost to put them synced again?

T

ViSIE

hose questions are just a few of Infrastructure DBA’s (I will call them like that) and architects need to answer every day. Or at least every time that an outage occurs. And let’s be honest, Oracle most of the time does not help you because you have a lot of options that you can use to protect your databases. And this is the focus for MAA – Maximum Available Architecture which guides you to have no data loss and have application continuity. Here I will discuss just the infrastructure part, the information related to Load Balancer, FCF (Fast Connection Failover), TAF (Transparent Application Failover), and JDBC/TNS configuration are beyond the scope of the article. So, MAA defines some base architectures (took directly from official MAA Reference https:// www.oracle.com/a/tech/docs/maa-onpremises-overview.pdf):

ZDLRA

But look at one detail from the image next page, for all architectures the Zero Data Loss Recovery Appliance (ZDLRA) is there (it is the ‘R’ appliance at the image above for architectures). But do you know why? Do you think that is just to do the backups?

Imagine that you do every day one incremental level 1 and you have available for you one level 0 backup of your 27TB tablespace? How much load over the network do you remove from your environment? This is how the backups for ZDLRA helps you in your environment. One

Let’s check some details about ZDLRA and the features that are available. There are a lot of details beyond what I describe below, but is a good resume to understand the relation between ZDLRA and MAA.

BACKUPS First, for sure that ZDLRA can help you with the backup. The Virtual Full Backup/Incremental forever strategy reduces a lot of the load over the environment during the backup. With this feature, ZDLRA can receive your full backup, inspect it and identify all the datafile blocks inside of it. After that, store all of them and when you do the incremental backup merge all the previous blocks with the new datafile blocks and create a new level 0 for you. Just to remember that this new virtual full is validated against corruption (logical and physical corruption).


NO MAA WITHOUT ZDLRA

simple 1GB incremental backup can save one full weekend of backups. And to add, ZDLRA does policy management (and RMAN catalog management) automatically. All backups that are expired are automatically removed, and you don’t need to do any cross­ check when you restore your database. Everything that you see in the RMAN catalog, can be restored.

REPLICATION ZDLRA has native replication that is executed as soon as possible and automatically. All the

|

11

backups that you ingest over it (data files and archive logs) can be replicated from one ZDLRA to another. You can have a multi-site copy of your backups done automatically, and again, validated and cross-checked for you. But let’s review this from MAA perspective. Using the replication feature for ZDLRA you can have multi-site protection in case of an outage. Even for a single instance database that doesn’t have Data Guard. In case of datacenter outage, all your backups are replicated to another site, all DEV. UAT, INT, and even PROD databases with an external copy of all backups. ViSIE


12

|

NO MAA WITHOUT ZDLRA

CLONES Another feature for ZDLRA is the clone for Tape and OCI cloud. You can schedule and clone your backups directly to tape or OCI based on several attributes and metadata (like TAG, and backup type as examples). So, again, you can have external copies of all your backups, from all MAA architectures. If you focus on the MAA architectures, you can protect your environment with multiple copies of your data (backups) even in case of a complete site outage.

REAL-TIME REDO TRANSPORT If you read until now, you saw that we talked just about backups. Backups itself, replication, and clones. But ‘backup is backup’, if I made it yesterday at 21:30 and now is 18:22 and occurs a complete storage outage (as an example) I will have data loss. Almost one day of data loss. As you can imagine, this is not what MAA purpose. The Real-Time Redo Transport (RTRT) is the reason for the ‘zero data loss’ of the ZDLRA name, and the reason that does not exist MAA architecture without ZDLRA. And this feature is simple to explain: ZDLRA can be a log_archive_dest for your database. Simple like that, ZDLRA can receive your redo stream and protect you in case of an outage, until the last received SCN. It can operate SYNC and ASYNC and even in case of uncomplete archive from the database (in case of outage) ZDLRA generate for you one archivelog backup until the last transaction. So, looking from MAA perspective, you can reach zero RPO for all your databases with just one product. You don’t need to take care of multiple storage syncs between sites (try to sync EMC and HP), or add another layer over the storage layer (like VSAN for VMware). Using ZDLRA all your databases from single instances (DEV/UAT or even some PROD), RAC, Exadata, and DG databases can be protected and have zero RPO.

THIS IS THE REASON THAT ZDLRA IS THE MOST IMPORTANT PART OF MAA DESIGN (FROM AN ARCHITECTURE POINT OF VIEW) ViSIE

And going further, they will have the same RPO in case of a complete site outage. I would like to add one detail here. If you look for the MAA Gold architecture, you have the DG to sync sites, but one question: how do you survive for multiple outages? In case you need to do DR due to site outage (or even for planned outage due to storage upgrade), what’s happens if you have a second failure? Data loss? This is the reason that ZDLRA is there as well, you can be resilient to multiple outages and continue with zero data loss. One experience that I passed some years ago: I suffered multiple storage cells corruption at my Exadata and this caused a complete disk group corruption (both DATA and RECO). So, all databases got affected and needed to restore data from backup. But since all of them were using real-time redo transport I had zero data loss. And since all of them got protection for the same timestamp I could restore and recovery to the last SCN and all was already synced. Not needed to call the app team and check what needs to be done later (to sync user data).

EVERYTHING TOGETHER This is the reason that ZDLRA is the most important part of MAA design (from an architecture point of view). With one appliance you can reach zero RPO for all of your databases. And since you have ZDLRA you don’t need to pay a Data Guard license to use the Real-Time redo transport protection for your databases, your single instance running at standard edition can have the same protection that you can reach with DG. And if you join with the replication feature of ZDLRA, you can have multiple site protection for all of your databases. Just to be clear, your databases will not run at ZDLRA, so, your Recovery Time Objective (RTO) can still be higher, but you will not have data loss. Complete zero RPO from the Bronze to the Platinum architectures without doing fancy solutions and adding layers of complexity (like storage synchronization, virtualizations layers for I/O to reach zero data loss). One simple and native Oracle integrated product can do that. So, today, there is no MAA without ZDLRA. n Fernando Simon is Senior Database and Infrastructure Specialist at CTG Luxemburg and Founder and Board member of LUXOUG.


COLUMN

|

13

IS ER NOG EEN DBA NODIG IN DE (AUTONOMOUS) CLOUD?

D

e recente APEX World was weer even wennen. Voor het eerst sinds 1½ jaar met velen in één zaal, stoelen dicht bij elkaar, in de rij voor koffie en lunch en scannen voor binnenkomst. Ook een verandering ten positieve kan lastig zijn, je zou zeggen:

omarm de nieuwe (of eigenlijk oude) situatie, geef iedereen een hand of sla een arm om ze heen. Maar toch, niets menselijks is ons vreemd en men liep nog wat aarzelend en terughoudend om elkaar heen te draaien. Als we er woordenboeken op naslaan, dan komt men bij het begrip ‘verandering’ niet

Sandor Nieuwenhuijs

veel verder dan ‘als er iets nieuws gebeurt’ of ‘het ontstaan van een nieuwe situatie’. Een vernieuwing is radicaler dan een verandering. Het betreft iets wat er daarvoor nooit was, zoals een nieuw product of dienst, een nieuwe werkwijze (zoals het ‘nieuwe werken’), of een andere wijze van organiseren via nieuwe technologieën. En met name dit laatste gebied heeft veel impact op de DBA. Over de jaren heen heeft

Nu kijken we met z’n allen naar de Cloud. Sommigen doen schoor­ voetend de eerste stapjes, anderen gaan met grote stappen recht op hun doel af.

Oracle continu faciliteiten aan de Database en management tools toegevoegd om het leven voor hen eenvoudiger te maken. Helaas werden deze niet altijd meteen omarmd. Ik herinner me nog de eerste versies van Enterprise Manager (2001), tijdens demonstratiesessies bespraken regelmatig aanwezige DBA’s trots hun eigen (klaarblijkelijk superieure) scripts. Vernieuwingen leiden mogelijk tot een beperkingen van het aantal DBA-activiteiten en leidt soms tot terughoudendheid in plaats van het omarmen van nieuwe, coole mogelijkheden. Allerlei andere ontwikkelingen in de markt compliceren dit nog, denk bijvoorbeeld aan “Agile” werken. Binnen deze werkmethode, met inzet van Scrum teams, is de “Apps DBA” persoon betrokken bij gegevensmodellen die niet alleen per release veranderen, maar soms zelfs per sprint of per story. En dezelfde DBA bewaakt ook nog de consistentie en integriteit over het geheel. Maar ook concepten als DevOps, met zeer frequent kleine incrementen van applicaties, vereist ook inbreng van de DBA voor een ongestoord Continuous Deployment proces. De nieuwste ontwikkeling, specifiek gericht op de publieke Cloud omgevingen heet FinOps (www.finops.org) ook wel omschreven als Cloud Financial Management. Uitgangspunt van FinOps is het beter inzicht krijgen in- en controle krijgen over de uitgaven in de cloud, onder meer door het opzetten van een Cloud Center of Excellence (CCoE). In zo’n CCoE heeft de DBA een prominente rol om te verzorgen dat resources, zoals een Database, optimaal ingezet en gecombineerd worden. Kortom, de rol van de DBA wordt alleen maar belangrijker en complexer, en nadert de business steeds dichter. Maar waar komt dan de angst vandaan dat de rol uitgehold zou worden? Een van de sleutelwoorden is “Automation”, het steeds meer overnemen van repetitieve taken door de machine en zelfs “Recommendations” die ervoor zorgen dat de database zichzelf gaat besturen, met minimale tussenkomst van de DBA. En dit lijkt dan opeens veel op de ontwikkelingen rondom zelfrijdende auto’s waarvan de trendwatchers ons enkele jaren geleden meldden dat dit een revolutie zou veroorzaken. Echter de storm is hier al wat geluwd. Moderne auto’s kunnen ons inmiddels helpen met een aantal praktische, repeterende activiteiten zoals afstand houden, binnen de belijning blijven, ons informeren over

Sandor Nieuwenhuis is

de maximale snelheid en ons wakker maken als we achter het stuur wegdommelen. Maar

licentie-adviseur binnen

uiteindelijk bepaalt de bestuurder toch wat er gebeurt, omringd en geholpen door systemen

het SIA (Software

om zich maximaal veilig, efficiënt en ontspannen te verplaatsen.

Investment Advisory)-

En net zoals er voorlopig nog bestuurders nodig zullen zijn voor auto’s, zullen er nog DBA’s

team van Oracle

nodig zijn voor databases, het takenpakket en de rol binnen de organisatie zal veranderen,

wereldwijd.

maar het werk zal veel effectiever, veiliger en ontspannen zijn.

ViSIE


14

|

OCI-NIEUWS

Ontwikkelingen in en rond Oracle Cloud Infrastructure

In dit laatste nummer van 2021 wederom een kleine selectie van een aantal opvallende en minder opvallende ontwikkelingen de afgelopen maanden die direct en soms ook indirect met de cloud te maken hebben. Met name dank aan de inspanningen van thatfinnishguy.blog.

ViSIE


OCI-NIEUWS

|

15

H

et aantal tutorials voor developers groeit, zie developer.oracle.com/free/, waaronder het bouwen van je eigen Minecraft server, het maken van een RESTful service met ORDS tegen de autonomous database aan, deployen van een Wordpress site etc. Waard om even rond te snuffelen. •H et gebruik van zogeheten ‘Build Pipelines’, en een code-repository zijn in de Developer’s wereld bijna een voorwaarde. Deze zijn inmiddels ook aanwezig in de DevOps-service. •E xadata X9M is gelanceerd, nu nog alleen voor Cloud@ Customer en on-premises, binnenkort OCI. •S ecurity: Autonomous Database kan nu ook geconfigureerd worden voor TLS (Transport Layer Security) naast de iets veiliger geachte mTLS (‘m’ staat voor mutual = client/server handshake). • Small step for mankind: de session time-out voor de console is nu instelbaar (5-60 minuten). •D e ‘Resource Manager Terraform Host’ komt nu standaard met ondersteuning voor Ansible Playbooks om OCI resources om via Terraform b.v. een OCI-VM – te deployen en te laten connecten via Bastion Service, en Ansible te gebruiken om de applicatie te deployen op die VM. •A lert-berichten kunnen nu beter geconfigureerd worden (‘e-mail friendly alarm notifications’). Keuze uit verschillende formaten : template bericht, JSON-template met line-breaks, JSON-bericht (zoals nu wordt verzonden).

En er is een nieuwe region in Israel, waar Oracle blijkbaar ook de eerste grote Cloud vendor is. • ‘ Data Labeling Service’ is nu beschikbaar. Met Data labeling worden documenten, tekst en afbeeldingen geidentificeerd, en een waarde (label) toegekend. Dit is voornamelijk belangrijk voor Machine Learning, om software te trainen om een autonome taak uit te voeren. Ondersteunde formaten om te kunnen labelen: PDF, TIF, TIFF, JPG, JPEG, PNG, TXT. •E r is een nieuwe API m.b.t. Vulnerability Scanning om een beter overzicht te krijgen van ontdekte kwetsbaarheden in de uitgevoerde security scans. •D e Data Migration Service verbetert elk kwartaal zo lijkt het, deze ondersteunt nu ook het migreren naar non-autonomous databases (in OCI cloud), en o.a. het uitsluiten

van schema’s, objecten of types bij een migratie. • MySQL service kunnen nu ook externe, asynchrone, replica’s gemaakt worden. • Met ‘Certificates Services’ kunnen certificaten, Certificate Authorities (CA’s) en CA bundels gemaakt worden en onderhouden. Inclusief automatische vernieuwing en importeren van third-party certificaten. • Web Application Firewall (WAF) kan applicaties beschermen tegen ongewild internet-verkeer (b.v. SQL Injection), en kan nu aan elk endpoint gekoppeld worden die tegen het internet aan zit, zoals een load-balancer. • Een compleet nieuwe service: Database Tools. En die kan gevonden worden onder... Developer services (vooralsnog). Nadat een database gemaakt is, kan connectie-informatie opgeslagen worden, met b.v. een password in de OCI Vault met encryption keys. Het opzetten van een Vault met Keys is wel mandatory om dit te doen. Voordeel? Het door een programma de connectie ophalen uit deze repository. Zoals Python, SQL Worksheet e.d. n ViSIE


OOK

ViSIE ONTVANGEN?

Wilt u ook op de hoogte blijven van actuele ontwikkelingen en nieuws en achtergronden over Oracle en Oracle-producten, de Oracle-community en de activiteiten van de Nederlandse Oracle User Group?

Abonneer u dan op het gratis e-magazine

ViSIE Inschrijving via de website www.nloug.nl


DBA DAG

|

17

DBA-DAG IN APRIL LIVE OP SS ROTTERDAM Na de virtuele Database-week was er in december dit jaar weer een echte dedicated bijeenkomst voor DBA’s gepland. Een live event met als vanouds veel diepgang en hoogwaardige content en op aansprekende locatie die volop gelegenheid biedt om te sparren met vakgenoten: SS Rotterdam.

H

elaas moest deze DBA-dag door de geldende Covid-maatregelen worden verschoven naar een later tijdstip in 2022. De DBA-dag wordt nu gehouden op 13 april a.s. Op dezelfde locatie en met een programma dat in de komende periode verder zal worden verfijnd en aangepast aan de actuele ontwikkelingen in database-land. Het gevarieerde programma biedt de deelnemers alle mogelijkheden om op een efficiënte manier en in een prettige ambiance op de hoogte te blijven van wat er speelt in en rond de (Oracle) database-community. Alle sprekers zijn fysiek aanwezig, dus geen remote presentaties. De afsluitende keynote wordt verzorgd door Mike Dietrich, Distinguished Product Manager Database Upgrades and Migrations van Oracle. Een uitgelezen mogelijkheid om met hem in gesprek te gaan en antwoord te krijgen op je vragen. Het programma is onderverdeeld in drie tracks, waarvan twee presentietracks: een klassieke

DBA-track – inclusief Cloud en customer cases, en een track die meer gericht is op development met en in de database .Daarnaast is er gelegenheid tot het volgen van Oracle Live-labs, begeleid door Oracle-experts. Het volledige programma van de DBA-dag is te vinden op de website van nlOUG. Het evenement is gratis voor nlOUG-leden, nietleden betalen € 125, 00, excl. BTW. N.B. SS Rotterdam en nlOUG zullen zich houden aan de op dat moment geldende Covid-19 richtlijnen van de overheid. n

De DBA-dag wordt gesponsord door:

Gold sponsor

Bronze sponsor

ViSIE


Leuk maakt alles beter!