Om een helder beeld te krijgen van de verschillen tussen DIY en Buy bij het gebruik van open source software, zijn vier aandachtsgebieden van belang: lifecycle management, governance & compliance, upstream commit power en kennislekken & continuïteit. Daarmee bepaal je of een DIY-benadering of een enterprise oplossing de juiste keuze is.

1. Lifecycle Management

Elk open source component kent een eigen lifecycle. Doordat de bouw vaak door een community van verschillende organisaties en personen wordt gedaan, is er niet altijd een eenduidige roadmap. En als die er is, kunnen er geen rechten aan worden ontleend. Het product wordt gratis ter beschikking gesteld, zonder contract of andere verplichtingen.
Voorstellen voor wijzigingen van een communityproject zijn mogelijk via een pull request, maar moeten wel uitvoerig toegelicht en gedocumenteerd worden, en uiteindelijk goedgekeurd worden door de beheerders van de broncode. Daarna moet de code versie nog uitvoerig getest en geïntegreerd worden in de bestaande software-stack. Aanbieders van enterprise open source software bieden een volledig ondersteunde software-stack aan, en hebben hiervoor mensen beschikbaar, inclusief processen en geautomatiseerde tests, om dit proces te versnellen.
Bij DIY-situaties is dat ingewikkelder. Een open source containerplatform bestaat bijvoorbeeld al snel uit tientallen componenten, met allemaal eigen releases, versies en lifecycles. Het evalueren van nieuwe versies kost hierdoor veel meer tijd, met name als er te weinig mensen en kennis beschikbaar zijn. Ook zijn er risico’s, namelijk dat de software-stack door een inschattingsfout bij een update ineens instabiel wordt of kwetsbaar blijkt voor hackers.

2. Governance & Compliance

De overheid verwerkt dagelijks grote hoeveelheden (privé)gegevens van burgers en bedrijven. Dat moet uiteraard op een veilige manier gebeuren om datalekken te voorkomen. Veel van de datalekken en hacks uit het verleden waren het gevolg van onzorgvuldig handelen of processen die niet waren ontworpen met ‘security by design’.

Voor een serieuze productiesituatie is een enterprise open source product, inclusief ondersteuning, updates en garanties, kosten­effectiever en betrouwbaarder.

Bij professionele ontwikkelteams en grote software­huizen wordt veel aandacht besteed aan security en het uitvoerig testen, beveiligen en patchen van hun software. Hiermee is het mogelijk om open source software, die veelal zeer snel wordt doorontwikkeld, toch veilig en betrouwbaar te houden. Het implementeren, onderhouden en beheren van een open source software-stack met onderdelen als bijvoorbeeld Kubernetes is sowieso zeer arbeidsintensief en complex. Uit onderzoek blijkt dat maar liefst 75 procent van de gebruikers van Kubernetes deze complexiteit als belangrijkste blokkade noemt bij het in productie nemen van dit container-orchestratieplatform. OpenShift bevat naast de enterprise-ondersteunde variant van Kubernetes ook developer services, base images en een management-portal. Het neemt het leeuwendeel van het werk uit handen, ook ten aanzien van beheer en beveiliging.

3. Upstream Commit Power

Enterprise open source producten zijn gebaseerd op upstream community-software, aangevuld met actieve ondersteuning en aanvullende diensten rond beveiliging, compatibiliteit, certificeringen en beheer. Naast Red Hat zijn er nog veel meer bedrijven die diensten leveren rond open source software, zoals Microsoft, Rancher en VMware. Kijkend naar het CNCF-landschap zien we dat Red Hat, na Google en onafhankelijke ontwikkelaars, de grootse bijdrager is aan deze open source componenten.
Als grote enterprise open source bijdrager, heb je vanzelfsprekend ook meer zeggenschap in een community. Dit maakt het eenvoudiger, zowel voor de softwareleverancier als zijn klanten, om bepaalde functionaliteit of wijzigingen onder de aandacht te brengen. Deze zogeheten ‘upstream commit power’ is zeer waardevol, zeker voor organisaties die op grote schaal gebruikmaken van open source software. In een DIY-situatie en als kleine partij is je zeggenschap een stuk minder.

4. Kennislekken en continuïteit

Kubernetes, en microservices op basis van containers, zijn de nieuwe standaard voor cloud native development geworden. Ontwikkelaars zijn enthousiast over de mogelijkheden en maken dankbaar gebruik van alle generieke services in de software-stack. Waarom zou je zelf iets proberen te bouwen, als het beschikbaar is in de Platform as a Service-laag (PaaS)?
Daardoor geven veel developers de voorkeur aan OpenShift voor zakelijk gebruik, met name door de focus op zakelijke functionaliteit en beheergemak. Waar je met Kubernetes nog weleens iets moet opzoeken, biedt OpenShift een uniforme workflow en beheertooling, waardoor de productiviteit minder vaak wordt onderbroken. Mede hierdoor is het ook minder noodzakelijk om gespecialiseerd technisch personeel in dienst te hebben. Zeker in een DIY-scenario ligt daarin ook een risico verscholen, namelijk dat er bij het vertrek van deze mensen mogelijk kennis van de DIY-software-stack verdwijnt. Dit kan zelfs de continuïteit van het platform en daarmee de dienstverlening in gevaar brengen.

Conclusie

Duidelijk is dat er grote verschillen zijn tussen een ondersteund enterprise open source platform met bijbehorende ontwikkel-stack en een DIY, in-huis beheerde oplossing. Wat ze gemeen hebben is de open source community, die uiteindelijk alle ontwikkeling en innovatie realiseert. Maar ze verschillen in de manier waarop je er als organisatie mee werkt. Ga je voor de DIY-aanpak, dan is de upstream-software weliswaar ‘gratis’ te gebruiken, maar er komen wel aanvullende operationele kosten en beveiligingsrisico’s bij. Dat is geen probleem voor een hobby-omgeving, waaraan lage eisen worden gesteld. Maar voor een serieuze productiesituatie is een enterprise open source product, inclusief ondersteuning, updates en garanties, kosten­effectiever en betrouwbaarder.

Meer informatie over de verschillen tussen Kubernetes en OpenShift

Stefan van Oirschot is Chief Digital Advisor bij Red Hat

Source