Om als bedrijf het verschil te maken, moet digitale transformatie bestaande functionaliteit niet verbeteren, maar functionaliteit toevoegen. Dit vraagt veel van ontwikkelaars. Hoe zorg je ervoor dat innovatie plaatsvindt, en tegelijkertijd de druk op ontwikkelaars niet oploopt door meer complexiteit, kosten en beveiligingsrisico's?
Bedrijven van elke omvang moeten ontwikkelaars in staat stellen de volgende geweldige digitale dienst, mobiele app of online-ervaring te creëren. Hiervoor is vertrouwen, autonomie en gedistribueerde besluitvorming nodig. Ontwikkelaars moeten in staat zijn tools naar eigen inzicht te kiezen en belangrijke ontwerp- en service-keuzes te maken voor hun digitale meesterwerken – in redelijkheid en binnen een rationeel kader.
Het stimuleren van innovatie brengt kosten met zich mee. Ontwikkelaars de mogelijkheid geven om te innoveren, is essentieel. Tegelijk kan het gevaarlijk zijn om dit zonder enige beperkingen te doen. Ontwikkelaars houden van tools (vaak opensource), maar te veel tools leidt tot wildgroei, met soms drie of vier alternatieven voor eenzelfde taak. Dit maakt architecturen aanzienlijk complexer, waardoor overheadkosten voor het beheer en operationele en beveiligingsrisico’s toenemen. Complexiteit verhoogt op die manier zowel de harde als de zachte kosten, zelfs met gratis opensource-tools.
Hoe meer tools je hebt, hoe meer tijd infrastructuur- en platformteams moeten besteden aan het onderhoud ervan. Het inwerken van nieuwe ontwikkelaars is ook ingewikkelder en tijdrovender, omdat ze vertrouwd moeten raken met de gebruikersinterface van elke tool, inclusief de eigenaardigheden.
Meer tools leidt ook tot mogelijke downtime: meer bewegende onderdelen met hun eigen operationele modellen en toolchains vergroten de kans dat dingen stuk gaan onder belasting. Het uitvallen van apps brengt zowel reputatierisico’s als financiële risico’s door gederfde inkomsten met zich mee. In plaats van te wachten tot u het probleem hebt opgelost, kunnen gebruikers ontevreden worden of overstappen naar andere aanbieders.
Overigens is complexiteit niet per definitie slecht, en in tijden van multi-cloud ook niet te vermijden. Het gaat erom hoe je het beheer overzichtelijk houdt; dan hoeft complexiteit zelf geen probleem te zijn.
Meer mogelijkheden en meer bescherming
Er zijn vier cruciale stappen die ontwikkelaars meer mogelijkheden bieden en tegelijkertijd bescherming bieden tegen (problematische) complexiteit, kosten en beveiligingsrisico’s.
- Beveiliging naar links verschuiven
Ontwikkelaars willen coderen. Ze willen nieuwe functies en functionaliteit bieden. Ze willen niet per se tijd en energie besteden aan beveiliging. Maar wanneer beveiliging eerder in de ontwikkelingscyclus wordt geïntroduceerd, is beveiliging developer-friendly te maken, waardoor het onderdeel wordt van de workflows. Dit noemen we ‘shifting left’.
Hierbij gaat het erom ontwikkelaars meer verantwoordelijkheid te geven over de implementatie van beveiliging terwijl ze code schrijven, of het nu gaat om beoordelingen van het dreigingsmodel, code-audits, pentests of de toepassing van beveiligingsbeleid via controles zoals een firewall voor webtoepassingen. Een verschuiving naar links betekent ook dat het voor ontwikkelaars eenvoudiger en intuïtiever moet worden om deze taken binnen hun bestaande workflows uit te voeren.
- Omarm moderne opensource
Ontwikkelaars hebben een opensource-first-mentaliteit. Vangrails werken niet als ze geen opensource-tooling kunnen gebruiken die past bij hun gewoontes en voorkeuren. De meeste bedrijven gebruiken opensource, met Linux, Docker, Kubernetes en duizenden andere tools in de hoofdrol.
Volgens Red Hats ‘The State of Enterprise Opensource-rapport van 2021’ maakt negentig procent van de it-leiders gebruik van enterprise-opensource. Er is tegenwoordig echter een scala aan opensource-mogelijkheden met vele duizenden projecten voor uiteenlopende taken. Het is belangrijk wildgroei van tools te voorkomen door te standaardiseren op een samengestelde set van opensource-tools – uiteraard rekening houdend met de wensen en begeleiding van de developers.
- Implementeer infrastructuur als code
Het verschuiven van beveiliging naar links en het omarmen van opensource berust op een andere best practice: het behandelen van je infrastructuur als code. Dit betekent dat je code implementeert als software of services die zijn te programmeren door api’s.
Volgens het ‘State of Application Strategy’-rapport van F5 heeft iets meer dan de helft van de organisaties infrastructure-as-a-code (iac) omarmd. Iac betekent dat een infrastructuur naar behoefte op- en afgeschaald kan worden, en het gaat verder dan alleen beveiliging en open-source tooling. Door alle moderne app-infrastructuur als code te behandelen, komt de verantwoordelijkheid voor het configureren van de infrastructuur bij diegenen te liggen die de applicatie het beste kennen: de ontwikkelaars en DevOps-teams. De opkomst van containers heeft een revolutie teweeggebracht in de manier waarop infrastructuur kan worden ingezet en heeft ontwikkelaars en DevOps-teams in staat gesteld om eenvoudig de infrastructuur te ontwerpen en op te roepen die het meest geschikt is voor hun app-implementaties.
- Automatiseren door zelfbediening
Security links laten liggen, opensource omarmen en infrastructuur implementeren als code, terwijl ontwikkelaars de ruimte krijgen om dit allemaal te doen zonder vangrails te voorzien, kan leiden tot operationele risico’s. Daarom is selfservice-infrastructuur nodig, zowel om het ontwikkelaars makkelijker te maken de infrastructuur en services te implementeren die ze nodig hebben, als om de groeiende complexiteit onder controle te houden en tegelijkertijd de kosten te beheersen.
Uit het ‘State of Application Strategy’-rapport blijkt ook dat 65 procent van de organisaties automatisering en orchestration heeft geadopteerd. Meer specifiek, 68 procent adopteert automatisering voor netwerk en beveiliging. Waarom? Zodat DevOps, NetOps, SecOps en PlatformOps teams infrastructuur eenvoudig kunnen maken voor ontwikkelaars om te provisionen via selfservice catalogi, mogelijk gemaakt door containers die goedgekeurde deployments beperken tot ‘golden images’ die zijn doorgelicht als veilig en effectief voor productie.
In feite is deze combinatie van selfservice en golden image onderdeel van wat publieke clouds zo populair heeft gemaakt. Ze fungeren als selfserviceportalen voor een catalogus van ontwikkelaarvriendelijke technologieën, waardoor kleine teams apps kunnen bouwen en schalen die kunnen concurreren met grote ondernemingen. Dat gezegd hebbende, weten we dat cloudproviders niet altijd de meest veilige standaardconfiguraties bieden. Daarom is het zo belangrijk om eigen golden images te beheren en deze in te stellen om de eigen specifieke infrastructuur te beschermen.
Innovaties stimuleren vooruitgang en productiviteit
In de afgelopen twee jaar hebben we gezien dat klanten die snel actie hebben ondernomen om ontwikkelaars meer mogelijkheden te geven, de vruchten hebben geplukt van hun vertrouwen en vooruitziende blik. Veel van hen hebben nieuwe verkoopkanalen opgezet of hun ontwikkelaars in staat gesteld hun toepassingen en infrastructuur volledig te herontwerpen voor een toekomst met gedistribueerde cloud- en servicegebaseerde implementatieframeworks. Die klanten staan er nu beter voor en kijken uit naar de toekomst.
Een verschuiving naar links, het mogelijk maken van opensource, het schalen van infrastructuur als code, het creëren van selfservice-architecturen en het bouwen van adaptieve applicaties op de meest moderne en veerkrachtige infrastructuurtechnologieën zoals Kubernetes zijn de drijvende kracht achter digitale innovatie.
Complexiteit is geen probleem als het maar simpel is ?
“Dit betekent dat je code implementeert als software of services die zijn te programmeren door api’s.”
code implementeren als software ?
“eigen golden images te beheren en deze in te stellen om de eigen specifieke infrastructuur te beschermen.”
eeeh, wtf ?
En elke keuze is vrij zolang je maar de golden image kiest 🙂
En wie gaat die beheren, de klassieke IT afdeling met de bofh ciso ?
We zijn weer thuis.
Eigenlijk valt de auteur bij de eerste zin al met de deur door de mand.
Het gaat niet om verbeteren, maar om toevoegen.
Dat krijg je als je Pre Sales Consultant laat adviseren over security en devops.
“Security links laten liggen, open source omarmen en infrastructuur implementeren als code, terwijl ontwikkelaars de ruimte krijgen om dit allemaal te doen zonder vangrails te voorzien, kan leiden tot operationele risico’s.”
Een lange zin met veel komma’s waar weinig over de operationele risico’s gezegd wordt maar verder niet onwaar. Aangaande die operationele risico’s kijk ik wat verder dan alleen de digitale aspecten want ook de eerste zin waar de auteur mee begint is niet onwaar maar incompleet. Tenslotte was het opzetten van nieuwe verkoopkanalen de afgelopen 2 jaar voor velen een noodzaak tot overleven door een lockdown. Eerste zin, tweede alinea is wat mij betreft de open deur waarmee de auteur door de mand valt als we kijken naar operationele risico’s van schaalbaarheid. Want hoewel beheer in de cloud inderdaad – zoals Dino zegt – thuis gedaan kan worden zal het wel gedaan moeten worden.
Verbeteren of toevoegen is een discussie die niet alleen om het loket aan de voorkant gaat, een app is tenslotte niet een businesss functionaliteit in de zin van zoiets als een nieuw verkoopkanaal.