Categoriearchief: OSS gedragscode

Data replicatie is het begin data sovereignty.

Geef een reactie

Er is de laatste maanden voldoende geschreven over Digital Sovereignty. Dit wordt natuurlijk beïnvloed door geopolitieke ontwikkelingen. Bedrijven en organisaties denken opnieuw na over de keuzes die ze kunnen maken en de afhankelijkheden die zij hebben. Tenzij je bereid bent zelf computers te bouwen en zelf software te ontwikkelen – en oh ja, zelf stroom op te wekken, ben je altijd wel van iets of iemand afhankelijk. Deze afhankelijkheid is niet per se een probleem, zolang je vrij bent om de afhankelijkheden te kiezen en de zelfstandigheid van de organisatie, en ze de uitvoering van het werk, de productie of de services niet in de weg staan, zit je goed. Keuzes zouden de toekomstige opties niet moeten beperken. Dus ga nooit een eenrichtingsverkeer straat is qua IT.

Bij de meeste bedrijven en organisaties betreft Digital Sovereignty eigenlijk hoofdzakelijk Data Sovereignty. Het “In control” blijven van data betekent vaak bepalen wie toegang heeft tot data, waar de data opgeslagen is (geografisch) en dat het niet gestolen-of encrypted kan worden (ransomeware). Ook compliancy speelt hierbij een rol. GDPR / AVG vereisen dat je garanties kan geven over het niveau van beveiliging en bescherming van data. Hoe doe je dat wanneer jouw data onder buitenlandse wetgeving valt?

Voor Data Sovereignty is het dus erg belangrijk dat je data technisch kan manipuleren (managen) en dan vooral kan repliceren. Dit is zeker geen nieuw onderwerp, in ons IT vakgebied doen we dit al jaren. Omdat het wederom zo’n actueel onderwerp is, wordt in dit artikel gekeken naar de verschillende soorten data replicatie die er zijn – dit alles tegen het licht van Data Sovereignty.

Verschillende soorten replicatie

Om maar meteen met de deur in huis te vallen, er zijn 3 fundamentele vormen van data replicatie. Zo kunnen disk-blokken gerepliceerd worden (block based replication, bijvoorbeeld bij Reduntant Arrarys of Inexspensive Disks – RAID), kunnen er records gerepliceerd worden (bij databases) of volledige files gerepliceerd worden (denk aan bijvoorbeeld AWS S3 buckets, Google’s Cloud Storage of Microsoft Azure Blob storage). Allen hebben hun sterke en zwakke kanten en daarmee specifieke toepassingsgebieden. In “Cloud Speak” hebben we het dan over “Patterns and Anti-Patterns“. Hierbij zijn de “Patterns” de juist toegepaste replicatie types en de “Anti-Pattrens” onjuist toegepaste replicatie types in een specifiek geval.

Block based storage

Block based storage komen we vaak tegen in de wereld van Storage Area Networks (SAN’s). Dit zorgt ervoor dat data op meerder disks komt te staan en het falen van een disk niet leidt to data verlies. Het is een heel efficiente vorm van data replicatie omdat alleen gewijzigde blokken gerepliceerd worden. Dit in tegenstelling tot het repliceren van het complete bestand. Niet alleen bij SAN’s komen we dit tegen. Zo is er ook open source software om block based replicatie te doen (eventueel over een netwerk), zoals o.a. DRBD.

Block based replication wordt meestal toegepast met als doel redundantie (van disks bijvoorbeeld) te realiseren. Wanneer het geen replicatie is tussen lokale disks, maar er naar een andere disk op een andere locatie gerepliceerd wordt, gaat het niet alleen om disk redundantie, maar ook om de beschikbaarheid van de data. De (fysieke) locatie van de data is dan als Single Point of Failure (SPoF) uitgesloten. Maar ook zo’n oplossing kent zijn grenzen. Wanneer data aan een zijde gedelete wordt, wordt dat gebeurt dat ook aan de andere kant. Daar beschermt het dus niet tegen. Het is geen disaster recovery (DR). Een off site backup is dat bijvoorbeeld wel.

Record gebaseerde replicatie

Record gebaseerde replicatie wordt toegepast bij databases. Databases kennen lees-acties en schrijf-acties van bijvoorbeeld records . Bij replicatie worden alleen schrijf-acties gerepliceerd, de lees-acties veranderen immers niets, De schrijf-acties worden aan de andere zijde opnieuw gedaan zodat beide databases weer gelijk zijn. Vaak is de gerepliceerde database een “Alleen lezen” database (ook wel “Slave” genoemd). De gerepliceerde (slave) database kan bijvoorbeeld prima gebruikt worden om backups van te maken. Er is dan geen performance impact op de “primaire” of “Master” database.

Replicatie wordt hier dus ook gebruikt om de beschikbaarheid te vergroten (en is er geen sprake van DR). De backup die van de “Slave” database gemaakt wordt is wel een DR maatregel. De gerepliceerde schrijf-acties Kunnen in een re-do log file geplaatst worden (Oracle technologie). Deze re-do log files worden dan vaak ook in de backup meegenomen. Met de combinatie van backup van de database en de re-do log files kan een “Point-in-Time restore” worden uitgevoerd.

Databases hebben legio mogelijkheden om te repliceren. Bijvoorbeeld MySQL / MariaDB bieden uitgebreide mogelijkheden hiertoe. In het bovenstaande voorbeeld werd de database replica niet gebruikt voor productie. Het wordt gebruikt om een backup van te maken en het heeft ook geen eindgebruikers. Maar voor lees-acties kunnen beide databases (“Master” en “Slave”) gebruikt worden, zolang wijzigingen alleen naar de “Master” geschreven worden. In het algemeen heeft een database 10 keer zoveel lees-acties als schrijf-acties. Een “Master” met 9 “Slaves” kan dus een manier zijn om de totale performance van het gehele systeem te verhogen. Maar hoewel de performance dan hoger is, is de “Master” nog steeds een Single Point of Failure (SPoF). Een van de “Slave” database kan “Master gemaakt worden, maar dat vraagt tijd en dat levert dus Down time op voor schrijf-acties.

“Master”-“Master” setup

ACID

Een term die bij databases gebruik wordt is ACID (Atomicity, Consistency, Isolation & Durability). Dit zijn kenmerken van een database waarmee de juistheid en compleetheid van data gegarandeerd wordt. Het 'Atomicity" kenmerk stelt dat database bewerkingen ondeelbaar zijn en dus juist of helemaal niet doorgevoerd en opgeslagen worden. Het voorkomt dat bewerkingen half doorgevoerd worden en dat er data mist of corrupt raakt.

Een andere mogelijkheid is een “Master-Master” setup te bouwen. Hierbij kunnen beide “Master” databases schrijf-acties ontvangen en repliceren deze naar de andere “Master”. Er moet voorkomen worden dat records met hetzelfde record nummer geschreven worden. Daarom wordt gekozen de ene “Master” de “Even” inserts te laten doen en de andere “Master” de “On-even” inserts. Beide databases zijn met lokale performance te gebruiken – ook wanneer ze ver uit elkaar staan. Deze systematiek kan naar believen verder uitgebreid worden, bijvoorbeeld met een 3 “Master” setup (zie de figuur). De beschikbaarheid van de data gaat hiermee omhoog evenals de performance. Maar een “Drop Tabel” (verwijder tabel) wordt naar alle “Masters” gerepliceerd en dus is het geen DR.

Nog een laatste opmerking over de multi "Master" setup. Wanneer de databases ver van elkaar verwijderd zijn, is er sprake van een hogere lantency bij de replicatie. Beide databases kunnen lokaal met uitstekende performance gebruikt worden. Het is een goede setup voor active-active (of ook wel Multi Region) designs. replicatie kan hierbij "Achterlopen" (denk dan aan de RPO, zie sectie over RPO en RTO).

File based replicatie

In cloud omgevingen is het (op simpele wijze) repliceren van files een basis voorziening. Dit bestond al voor de cloud (Ceph bijvoorbeeld), maar de cloud heeft het wel populair gemaakt. Tegenwoordig weet iedereen wat een AWS S3 bucket is. Met file gebaseerde replicatie worden files op meerdere storage systemen (en vaak ook locaties) opgeslagen. Zodra een file verandert, wordt een volledig nieuwe versie van de file (of object) gemaakt, dit wordt ook wel “Copy-on-Write” genoemd. Het gevolg hiervan is dat als een file (of object) verandert, alle kopieën gelijk gemaakt moeten worden. Dit kost hierdoor tijd en daarmee spreek men wel over “Eventually Consistent” storage. De file (het object) kan van iedere locatie gelezen worden (nadat het consistent is geworden). Dit levert een hoge performance op. Versiebeheer is ook (relatief) eenvoudig, na een “Copy-on-Write” wordt de oude versie niet verwijderd.

Nadeel van het “Copy-on-Write” principe is dat wanneer slechts 1 bit van een file veranderd wordt, het gehele file opnieuw geschreven moet worden. Het opslaan van een database file op een object store (zoals S3) is dan ook niet efficiënt. Iedere record change leidt tot een nieuwe kopie van het complete database bestand. De performance hiervan is dan ook slecht, het is een zogenaamd “Anti-Pattern“. Gesteld kan worden dat object storage (file based replicatie) dus zowel de performance ten goede komt (in de juiste situaties, de “Patterns”) net als de beschikbaarheid (availbility). Het kan ook DR bieden, mits versiebeheer ingeschakeld is. Een laatste voordeel van een dergelijk storage techniek is dat het vrijwel onbeperkte schaalbaar is qua opslag capaciteit. Het is buitengewoon krachtig in z’n eenvoud.

Maar kan een object storage file systeem gekoppeld (gemount) worden?

Block gebaseerde file systemen kunnen gekoppeld (gemount) worden "In" of "Aan" een computer. Het wordt daarmee gezien als lokale storage ook al is het dat niet. Dit is niet gebruikelijk met object storage. Het heeft een Application Programming Interface (API) die gebruikt kan worden. Lees, schrijf, create en delete acties kunnen middels deze API uitgevoerd worden. Toch is het - als je dat echt wil - wel mogelijk een object store te koppelen (mounten). De performance van een dergelijk oplossing is laag vooral vanwege het "Copy-on-Write" principe. De object store gedraagt zich fundamenteel anders dan lokale storage en dat heeft niet veel toepassingen (Patterns).

RTO en RPO

Bij het design van een omgeving wordt vast gesteld welke RTO en RPO behaald moeten worden. De Recovery Point Objective (RPO) is het maximale data verlies dat een omgeving mag hebben. Recovery Time Objective (RTO) is feitelijk de maximale down time, maar je kan het ook zien als de beschikbaarheid van de omgeving. Deze waarden worden vaak tijdens een Business Impact Analyse (BIA) vast gesteld.

De RTO wordt bereikt door alle maatregelen die getroffen zijn om de beschikbaarheid te kunnen garanderen of te herstellen. De RPO wordt vooral bepaald door de latency van de data replicatie en de backup / restore (DR). Maar wanneer er een netwerk storing optreedt voordat data volledig gerepliceerd is, hoeveel data is dan verloren gegaan? Welke hoeveelheid dataverlies is eigenlijk acceptabel? RPO is dus een complex onderwerp, want hoe weet je welke data nog wel gerepliceerd is tijdens een storing en welke niet? Hoe bepaal je welke van de twee zijdes de correcte data bevat als ze niet meer in sync zijn? Dit wordt ook wel de data “GAP” genoemd. Hiermee raken we aan het onderwerp van synchrone en a-synchrone data replicatie. Meer hierover in de sectie “Timing”.

Welke data is nu correct nadat we een replicatie storing hebben gehad? Met een database kan de "Time Stamp" gebruik worden. Het laatste correct weggeschreven record is de laatste data die goed is, alles daarna is fout. Voorwaarde hiervoor is dat beiden kanten de correcte tijd hebben. Bij Block gebaseerde replicatie wordt iets gebruikt dat "Fencing" genoemd wordt. "Fencing" wordt gebruikt om te bepalen welke (storage) zijde de waarheid bevat.

En backup dan?

Je kan je – terecht – afvragen of backup / restore een data replicatie techniek is. Dat is vast een discussie waard. In de meeste gevallen wordt een backup / restore echter niet gezien als een replicatie techniek. Een backup / restore gaat eerder over retentie en recovery. Het maakt een “point-in-Time” kopie van data (inclusief fouten). Data replicatie is eerder een techniek die gebruikt wordt om “Business Continuity” te garanderen. Verwarrend is dat object storage ook gebruikt kan worden voor de opslag van backups. Het is hoog beschikbaar en ondersteund versiebeheer. Deze discussie is lastig te beslechten. Cruciaal is dan ook het antwoord te vinden op de vraag, “Wat moet er bereikt worden”?

En Off site backups dan?

Object store biedt goede opties voor het opslaan van backups. Want niet alleen ondersteund het versiebeheer, het geeft ook de mogelijkheid om van andere regio's gebruik te maken. Hiermee komen we dicht bij het idee van off site backups.

Granulariteit

De 3 replicatie technologieën hebben allen hun voor- en nadelen, hun “Patterns & anti-Patterns”. Een groot verschil tussen deze technieken is wel de granulatriteit. De kleinste replicatie eenheid is block based replicatie. Het gaat dan bijvoorbeeld om blokken van 4 kilobytes. Records zijn meestal veel groter en files zijn vaak nog vele malen groter.

In overzicht:

TypeData eenheidUse casePerformance
Block4 KB – 64 KB blocksSAN’s, virtuele servers, RAIDHoogste (lage over head)
RecordIndividuele database rijenSQL / NonSQL databasesHoge performance (selectief)
FileGehele files / objectenCloud opslag (S3 bijvoorbeeld), backupsverieert, (Copy-on-Write)

Toplogie

Het artikel raakte eerder al aan “One-way” replicatie en “Two-way” replicatie. Dit wordt ook wel de topologie van de replicatie genoemd.

Deduplicatie

Wanneer de opslag van files geanalyseerd wordt dan valt op dat vaak dezelfde bestanden / files vaker opgeslagen worden. Dat is jammer, want met replicatie worden toch al meerdere kopieën bewaard. Kopieën van kopieën is onnodig en kostbaar. Sommige opslagsystemen halen deze dubbelingen eruit zonder dat je dat als eindgebruiker merkt. Dit wordt deducplicatie genoemd. Deduplicatie bespaard opslag capaciteit en dus kosten.

Compressie

Als toevoeging op deduplicatie kunnen data en files ook gecomprimeerd worden. Hierbij maken we bestanden / files kleiner door middel van compressie en besparen zo op opslag capaciteit. Het grootse voordeel wordt behaald wanneer zowel deduplicatie als compressie gecombineerd worden. Beiden vragen echter ook rekenkracht (overhead) en voegen dus (al is het theoretisch) latency toe.

Encryptie

Een onderwerp dat regelmatig langs komt is encryptie. De meeste cloud provider / hypescalers bieden dit “Out of the Box” aan. Dit kan toegepast worden op lokale (block) gebaseerde opslag, op databases en op object gebaseerde opslag. Het is een goed idee om encryptie toe te passen, het is makkelijk en kost vrijwel niets. Het beschermt je echter niet tegen de cloud provide / hyperscaler zelf. Zij kunnen gewoon bij de encryptie sleutels. Moet dat voorkomen worden, dan zal een bedrijf of organisatie zelf haar encryptie sleutels moeten beheren. Dat is te doen, maar integreert niet zo fijn in de cloud omgeving. Bijvoorbeeld met een Hardware Security Module (HSM). Dit beschermt dan wel tegen de cloud provider / hypescaler en tegen informatie verzoeken van overheden en geheime diensten. Het is dus belangrijk in de discussie rond Data Sovereignty. Deze encryptie van opgeslagen data wordt ook wel encryptie van “Data at Rest” genoemd. Naast encryptie van “Data at Rest” kennen we encryptie van “Data in Transfer“, het netwerkverkeer. Beiden zijn encryptie, beiden beschermen tegen andere risico’s.

Caching

Een onderwerp dat hier genoemd wordt worden is caching. Caching - in het algemeen - is de benadering waarbij veel gevraagde data op snelle disk (SSD), memory of geografisch dichtbij wordt geplaatst. Hierdoor kan deze data heel snel aangeleverd worden. Ook operating systemen zoals Linux, OSX en Windows kennen zoiets. Databases kennen ook cache. Hiermee kunnen veel opgevraagde records snel verstuurd worden. Bijvoorbeeld handig voor sessie informatie die veelvuldig gevraagd wordt. Cache is een data replicatie onderwerp om dat het enerzijds replicatie kan versnellen en anderzijds replicatie kan verstoren. Hier wijden we niet verder uit over dit onderwerp, maar je gaat dan bijvoorbeeld in op onderwerpen als "Cache hits", "Cache misses" en "Flushing Cache".

Timing

Een ander interessant aspect van data replicatie moet nog in meer dertail besproken worden. De tijdsvertraging (latency). Dit is van belang bij replicatie. Dit kwam eerder aan bod bij de RTO en RPO. De fysieke afstand tussen de storage die we repliceren bepaalt welke tijd er nodig is om die data te repliceren. Pas wanneer data aan beide kanten compleet is weggeschreven is de data veilig. Wanneer de afstand groot is begint dit een rol te spelen. Bij synchrone replicatie wordt pas een bevestiging gegeven als beide zijden geschreven hebben. Vanwege de afstand moet een eindgebruiker dan langer wachten. Bij echt grote afstanden kan dit vervolgens een probleem worden. Er kan dan beter gekozen worden voor asynchrone replicatie. Hierbij kan de eindgebruiker verder wanneer de data lokaal is weggeschreven. Daarna wordt de data nog gerepliceerd. Dit is goed nieuws voor de performance, maar minder goed voor data veiligheid. Want het kan dus voorkomen dat de data nog niet volledig is gerepliceerd en er zich een verstoring voordoet. De storage is dan niet meer hetzelfde. Welke zijde heeft nu gelijk als er bidirectonele replicatie toegepast werd? Hier zijn natuurlijk wel oplossingen voor, maar die vallen buiten de scope van dit artikel.

Data Soverignty

En waarom was dit allemaal zo belangrijk voor Data Sovereignty? In het licht van de Data Sovereignty zouden bedrijven en organisaties kunnen overwegen data op meerder plekken op te slaan. Bijvoorbeeld om zeker te zijn van de (geo)locatie van de data (Data Residiency). Ook bieden verschillende technieken de mogelijkheid tot DR van data. Dit is iets dat Data Sovereignty zeker raakt. De beschreven technieken zijn dus van belang om dergelijke doelstellingen te verwezenlijken. En omdat geen enkele techniek alle problemen oplost en situaties van elkaar verschillen, zijn alle technieken zinvol om kennis van te hebben en ze “Meester” te zijn. Misschien dat zelfs een combinatie van technieken gebruik kan / moet worden.

Hoewel het geen replicatie technologie betreft, moet open source software (OSS) hier toch genoemd worden. Omdat Data Sovereignty gaat om in “Control” te komen van data, heeft de software die gebruikt wordt daar een grote impact op. De beste manier om controle te behouden (of opnieuw te verkrijgen) is controle te behouden over de software die gebruikt wordt. OSS is dan de beste keuze die gemaakt kan worden. Interessant detail is overigens dat alle cloud provider / hyperscalers gebruik maken van OSS. Soms gaan ze zo ver om OSS een nieuwe naam te geven en het als een eigen product in de markt te zetten. Dat is overigens legaal. Zelfs al wordt de hernoemde versie gebruikt, men kan altijd terug naar de OSS variant en daarmee blijft data toegankelijk.

Nog een voordeel van het gebruik van OSS is dat het de beste garantie is om open standaarden te gebruiken. OSS kan niet anders dan open standaarden gebruiken en dat garandeert de toegankelijkheid tot de data.

Samenvattend kan gesteld worden dat het begrip van “Patterns and Anti-Patterns” en het beheersen van de technologeen van data replicatie hoogstwaarschijnlijk noodzakelijk zijn om Data Sovereignty te bereiken. Data Sovereignty is het mitigeren van geopolitieke risico’s in data opslag. Deze technieken gaan je daarbij helpen.

Het pad naar Digital Sovereignty

1 reactie

Een van de onderwerpen waarover ik de laatste tijd veel nadenk is “Digital Sovereignty”. Het afgelopen jaar is er veel veranderd in het geopolitieke speelveld, ik denk dan aan de Amerikaanse politiek, de verhouding van het westen met China en de oorlog in Oekraïne. Inmiddels is dit onderwerp bij de IT consultancy bedrijven aan beland, onze klanten vragen hiernaar.

Het onderwerp “Digital Sovereignty” lijkt een veelkoppig monster omdat je er verschillende perspectieven op kan hebben. Je kan het benaderen vanuit een bedrijfsvoering perspectief, namelijk kan ik mijn bedrijf operationeel houden? Je kan ook focus hebben op de data, waar verblijft deze? Of je kijkt naar de geldende wetgeving, is de Amerikaanse Patriot act van kracht, of is de Europese wetgeving leidend? Als laatste is er het technische perspectief, welke technische maatregelen kan of moet ik treffen? Na studie (o.a. het AWS perspectief middels een online cursus), discussie met klanten en collega’s, cloud leveranciers white papers en – niet geheel onbelangrijk – er goed over nadenken, is het volgende mijn kijk op de zaak.

Eerst studeren dan maar

De externe bronnen die ik als eerste heb geraadpleegd zijn bijvoorbeeld Gartner, wat is hun kijk op deze materie. Maar ook AWS, Microsoft en Oracle hebben aanbod op dit onderwerp. Erg nuttig vond ik zelf informatie van de Europese Commissie zelf. Zo kan je online het “Cloud Sovereignty Framework” document vinden met daarin verschillende perspectieven op dit onderwerp. Zo kijkt zij naar de “Sovereignty Objectives”, de “Sovereignty Effective Assurance Levels” en “Assessment of Sovereignty Effectiveness”. Als laatste biedt zij een rekenmodel voor een “Sovereignty Score”. Dit laatste heeft vooral betrekking op aanbestedingen.

Voor mijzelf is het technisch / IT perspectief interessanter. Wat kunnen  / moeten we doen voor onze digitale soevereiniteit? En als je er goed over nadenkt, dan hebben die maatregelen veel weg van de maatregelen die we treffen bij security-onderwerpen. Die moet ik als cloud architect (of security architect) vaak meenemen in ontwerpen en adviezen. Het gaat dan om het mitigeren van (security) risico’s. In dit geval risico’s van geopolitieke aard, maar ook die leiden tot technische maatregelen. Dus is het dan gewoon “Risk management”?

Centraal bij security risico’s is dat je als bedrijf “In control” blijft. In control van wie er toegang hebben tot data, in control van wie er gebruik maken van ons netwerk en zo verder. Waarom wil je als bedrijf “In control” zijn? Dat is om zeker te kunnen stellen dat de bedrijfsvoering doorgang kan vinden. De bedrijfsvoering vraagt (vaak) dat de IT weerstand kan bieden aan verstoringen van welke aard dan ook (“Resilience”). Daarbij wil een bedrijf of organisatie in staat blijven veranderingen in de IT aan te kunnen brengen, bijvoorbeeld als de bedrijfsvoering daarom vraagt, of wanneer wet- en regelgeving verandert.

IT capabilities

Vanuit een IT architectuur bezien gaat het wat mij betreft vooral over “IT Capabilities” – kennis, kunde en verworvenheden. Als de “IT capabilities” toenemen, is men steeds beter in staat verstoringen te weerstaan en keuzes te maken die bij de bedrijfsontwikkeling passen. Op welke zaken heeft dit dan betrekking? Wat mij betreft zie ik (minimaal) de volgende onderwerpen waarbij je “In control” moet blijven:

  • software development
  • security
  • scalability
  • availability
  • licenses
  • hardware
  • (geo) locatie van data en
  • vendoren

Ik zie eigenlijk een soort denkbeeldige ladder waarbij je omhoog klimt en steeds meer “IT capabilities’ verwerft. Helemaal onderaan de ladder is een situatie waarbij er sprake is van “Technical debt”. Er worden verouderde software en platformen gebruikt, men is niet goed in staat aan de eigen software verder te ontwikkelen, er zijn in toenemende mate security risico’s. Er is veel handwerk. En er worden proprietary software en licenties gebruikt – waarvan men moeilijk af raakt. Eigenlijk is men niet in staat enig risico te mitigeren.

Applicatie modernisatie, de eerste stap

Hierna volgt de reis van de applicatie modernisatie. Platformen worden vernieuwd (zowel hardware als software) en met behulp van moderne software development tools kan de ontwikkeling van de eigen software weer gestart worden. Er kunnen nu weer keuzes gemaakt worden, men kan operationele uitdagingen mitigeren, bijvoorbeeld op het gebied van availability, resilience, licenties en security. Men neemt voorzichtige eerste stappen met het automatiseren van IT processen, installaties en configuraties.

Digital Sovereignty “ready”

In het volgende “Plateau” is de mate van automatisering groter zodat dat men in staat is om “Workloads” op verschillende (cloud) platformen te draaien. Er komt grip op de data residency (waar staat mijn data) en zaken als hoge beschikbaarheid (multi site) kunnen gerealiseerd worden. Ook krijgt men meer grip op leveranciers, er kunnen tenslotte keuzes gemaakt worden en veelal gaat men nu Open Source Software (OSS) gebruiken. De risico’s die nu gemitigeerd kunnen worden zijn van tactische aard. Eigenlijk is het bedrijf klaar om “Digital Sovereignty” te bereiken als dat gewenst zou zijn.

Strategische controle

Naar mijn idee is het hoogste “Plateau” een niveau waarin de organisatie grip heeft op alle “IT capabilities” die er zijn. Men kiest voor Open Source Software (en containers bijvoorbeeld) waar men dat wil en waar men vrijwillig kiest voor afhankelijkheden waar mogelijk. Men is daarbij in “Control of data residency”. Eigenlijk heeft men de functionaliteit losgekoppeld van de technische implementatie. Hierdoor ontstaat ruimte om te kunnen manoeuvreren en de risico’s die daarbij dus gemitigeerd kunnen worden zijn van strategische aard.

Voor mij gaat “Digital Sovereignty” dus om het beklimmen van de “Ladder” van “IT capabilities”. Bedrijven en organisaties die hoger op deze “Ladder” staan zullen dus beter in staat zijn de “Digital Sovereignty” te bereiken. Mijn suggestie daarbij is, laten we het een discussie maken over “IT capabilities”.

Adopteert Microsoft de OSS gedragscode?

Geef een reactie

Na 15 jaar tegen Linux en Open Source software te hebben gestreden, verzet Microsoft zich niet langer. In anderhalf jaar tijd is het bedrijf van fel tegenstander veranderd tot een actief aanhanger. Dit is geweldig nieuws, want van strijd werd niemand beter, van samenwerking natuurlijk wel. Maar een interessante vraag is of het zich aan de (ongeschreven) gedragscode van de Open Source software community’s kan houden. Welke regels zijn dat eigenlijk?

Gedragscode

Gedragscode

Wie deelt heeft meer

Een groot deel van de gedragscode van Open Source software community’s vindt haar oorsprong in de hacker cultuur. De relatie tussen Open Source software projecten en hackers (developers) is van oudsher erg innig. Het zijn voor een belangrijk deel deze hackers die de software schrijven en daarom hun cultuur opleggen.

De term "hacker" wordt vaak misbruikt voor computer criminelen, iemand die 
inbreekt op systemen, data / informatie steelt of virussen schrijft. Volgens 
Wikipedia is een hacker iemand met goede computer (programmeer) skills. 
Het programmeren wordt dan ook wel hacken genoemd en er is zelfs sprake 
van een hacker cultuur. Iemand die computers binnendringt wordt “Cracker” 
genoemd. Tegenwoordig wordt de term hacker voor beide gebruikt en
dat kan verwarrend zijn.

De essentie van Open Source software projecten is gezamenlijk aan de software te werken, de bijdrages te delen en daarvan te profiteren. Het delen van broncode is daarvoor noodzakelijk anders gaat dat niet. Dus wat betreft normen en waarden, gaat het om bijdragen een een gemeenschappelijk belang – het software project. Als mensen niet delen, werkt het principe niet.

Iedereen doet mee

In Open Source software projecten telt alleen je bijdrage, je code. En vooral de kwaliteit van je code is belangrijk. Als gevolg van deze gedragscode worden mensen die willen deelnemen dan ook niet buitengesloten, niet op grond van afkomst, nationaliteit of huidskleur. Het goede nieuws voor bedrijven zoals Microsoft, je mag meedoen, maar je bijdragen moeten van goede kwaliteit zijn.

Vrijheden van OSS

Commerciële software leveranciers houden de broncode juist voor zichzelf en verkopen alleen  het recht op het gebruik van de (gecompileerde) software middels licenties. Hierin verschilt  deze software fundamenteel van Open Source software projecten, want het recht op het gebruik van Open Source software hebben eindgebruikers al en de broncode krijg je erbij. Overeenkomstig is wel dat Open Source software ook onder een licentie valt. Maar hier is de licentie bedoeld om eindgebruiker rechten te geven, de software te beschermen en ervoor te zorgen dat deze “Open” blijft.

Er zijn veel soorten Open Source software licenties. Deze licenties  
beschermen de software tegen misbruik en verlenen de eindgebruiker 
verschillende vrijheden. Volgens Richard Stallman is Vrijheid 0 
het recht om de software te gebruiken voor elk gewenst doel. 
Vrijheid 1 is het recht om de software te bestuderen en aan te passen 
(hiervoor is de beschikbaarheid van de broncode dus een voorwaarde), 
vrijheid 2 betreft het recht om de software te mogen kopiëren en 
te verspreiden en, de laatste vrijheid (3) betreft de het recht 
om de veranderde software te mogen verspreiden. Er zijn veel 
licentievormen voor Open Source software die allemaal in detail 
van elkaar verschillen. Een van de meest bekende is de 
General Public License v2 (GPL v2) die bijvoorbeeld voor 
de Linux kernel gebruikt wordt.

Het respecteren van de gebruikte licentievorm is belangrijke binnen Open Source software community’s. De voorwaarden van de verschillende Open Source software licenties zullen niet altijd in het (commerciële) belang van Microsoft zijn. Het goede nieuws is dat Microsoft vrij is de Open Source licentie (variant) te kiezen die haar het beste past.

Open standaarden

Om software onderling te laten samenwerken (interoperabiliteit) is het nodig dat standaarden gebruikt worden. Standaarden kunnen betrekking hebben op bestanden (zoals document standaarden) of bijvoorbeeld netwerk protocollen. Om deze interoperabiliteit zo goed en makkelijk mogelijk te realiseren zijn Open standaarden nodig. Open standaarden zijn door iedereen te gebruiken en toe te passen. De specificaties zijn beschreven en is geen gevaar van hoge kosten of Intellectual Property (IP). Open Source software projecten baseren zich op Open standaarden vanuit praktische (kosten) overwegingen. Daarnaast is het onmogelijk gesloten standaarden in Open Source software te implementeren, immers, dan worden de standaarden ook open en dat is eigenlijk altijd tegen de licentie van de gesloten standaard. 

Microsoft kan prima open standaarden toepassen of ze zelfs introduceren. Nadeel is wel (kan zijn)  dat anderen dat ook kunnen en er keuze vrijheid voor eindgebruikers ontstaat. Zij kunnen bijvoorbeeld een andere applicatie gebruiken om dezelfde documenten te bewerken. Deze keuze vrijheid maakt het lastig voor Microsoft, want de consequentie is dat er concurrentie op prijs en kwaliteit plaats gaat vinden. Hoe concurreer je met gratis software?

De eerste packet filter (firewall) in Linux was ipfwad. Deze werd vervangen 
door IPchains die werd opgevolgd door IPtables. Inmiddels heeft nftables 
IPtables weer opgevolgd. Commerciële software bedrijven denken er niet aan 
dit zo te doen. Ze zou moeilijk aan haar klanten kunnen uitleggen 
waarom zij haar medewerkers opnieuw op moeten opleiden en wederom een 
migratie moet uitvoeren. En wel tot drie maal toe. Open Source software 
projecten hebben deze commerciële druk niet en kunnen de technisch beste 
oplossing kiezen, ook als dat commercieel niet handig is. Maar is dit niet
te prefereren?

Het beste idee wint

Als software ontwikkelaars samenwerken in een Open Source software project, dan wordt soms de ene implementatie verkozen boven de andere. Ook kan een al bestaande implementatie van een functie vervangen door een compleet nieuwe. Er zijn geen marketing of bedrijfspolitieke redenen om deze keuze te maken. Steevast wordt daarom de (technisch) beste implementatie gekozen. De firewall code in de Linux kernel is daarvan een voorbeeld en is al drie keer volledig vervangen. De beste implementatie wint het bij Open Source software projecten uiteindelijk.

De keuze voor de beste oplossing hangt samen met het efficiënt willen zijn van software ontwikkelaars. Ze willen dan ook geen dingen dubbel doen. Bestaat functionaliteit al, dan heeft het de voorkeur dit te hergebruiken, tenzij het beter kan natuurlijk.

Microsoft heeft wel bedrijfspolitiek en wel een marketing strategie die haar keuzes beïnvloedt. Deze strategie zou strijdig kunnen blijken met de gedragscode dat de beste implementatie altijd gekozen wordt.

Trots

De individuele bijdragen aan projecten kan vanuit verschillende motieven komen. De  ontwikkelaar is bijvoorbeeld trots op zijn of haar werk en wil daar graag de eer van hebben. Ontwikkelaars verbinden immers hun eigen naam aan Open Source software projecten. Er valt eer te behalen, of roem te verliezen naar gelang je goed werk levert. Het is dan “not done” om software te (her) gebruiken zonder de namen te noemen van alle personen die eraan hebben bijgedragen. Dit heeft in essentie alles te maken met werken binnen een community van software ontwikkelaars waarin je elkaar respecteert en individuele bijdrage waardeert.

Transparant

Ontwikkelaars in Open Source community’s hebben vaak een hekel aan commercie. Er mag wel geld verdient worden, maar dan wel door een echte meerwaarde te leveren. De stellingname is dat als je iets zegt je dat waar moet maken. Mooie verkoopverhalen worden niet gewaardeerd.

Elon Musk, de CEO van zowel Tesla als SpaceX, doet regelmatig product presentaties 
zoals onlangs van de Tesla Model 3. Hoewel deze bedrijven commercieel opereren 
vinden veel technisch geïnteresseerde mensen ze cool. Uit de presentaties die 
Elon geeft blijkt dat hij technisch op de hoogte is, er echte vernieuwingen 
zijn (geen “oude wijn in nieuwe zakken”) en hij bedient zich van 
“techneuten humor”. Bovendien draagt hij gewoon een jeans en geen stropdas. 
Echt interessant is dat ook veel niet-technisch aangelegde mensen zijn 
presentaties cool vinden. Het lijkt wel of nerds populair worden.

Het logische gevolg hiervan is dat als er zich problemen voordoen (bijvoorbeeld met security issues in software) dat deze niet verzwegen worden. Openheid en transparantie zijn namelijk de norm. Dergelijke issues worden zo snel mogelijk bekend gemaakt en als gevolg daarvan komen security fixes eveneens snel beschikbaar. De community’s zijn er, evenals het NIST, van overtuigd dat “Security through obscurity” niet werkt.

Commerciële software bedrijven hebben geen goede reputatie als het gaat om transparantie bij security issues. De vraag is daarbij hoe klanten dat zien. Zouden zij het juist niet waarderen als ook Microsoft hier transparant is?

Kan Microsoft de gedragscode naleven?

Zoals gezegd, de (ongeschreven) gedragscode binnen Open Source software projecten zijn een afgeleide van de hacker cultuur. Sommige daarvan zijn ook binnen commerciële software bedrijven te vinden, zoals (o.a.) het naleven van licentievoorwaarden. Maar er zijn voldoende spelregels die lastig zullen zijn voor een groot bedrijf. De transparantie die de norm is, staat haaks op het achterhouden van software exploits en security issues. Het gebruik van open standaarden laat klanten vrij andere software te gaan gebruiken. De vier vrijheden van Open Source software zijn ook niet in het belang van commerciële software bedrijven.
Als grote bedrijven zoals Microsoft serieus willen participeren in Open Source software community’s en daarbij van de voordelen te profiteren, dan helpt het als ze zich op deze punten kunnen schikken naar de norm. Vanwege de grote commerciële en financiële belangen is dit een hele uitdaging, zowel om het te doen, maar vooral om het niet te doen.