Category Archives: Blog post

Versnelling en complexiteit, daar draait het om

Leave a reply

Snel, sneller, snelst

Bedrijven en organisaties gaan in onze westerse maatschappij steeds sneller. Nergens is dat beter zichtbaar dan in het IT vakgebied. En snelheid is belangrijk, want het houdt de kosten laag en verbetert de concurrentiepositie. Consumenten worden zo eigenlijk verwend met wachttijden die korter worden. We houden dan ook niet van wachten.

Het telkens verder versnellen van organisaties en bedrijven lijkt daarmee een logische keuze en dat is het ook. Er is nooit een bedrijf gestart om productie of diensten te vertragen. Bovendien, versnelling van productie leidt tot lagere kosten, want hoe minder tijd je kwijt bent, hoe lager de kostprijs. Dus ook vanuit een bedrijfseconomisch perspectief is versnelling een goed idee.

Complexiteit

Maar er werkt ook iets tegen de versnelling in. Een tegenkracht, zo je wilt, en dat is complexiteit. Als een situatie complexer wordt, kan je minder snel. Dus versnellen kan je ook door de complexiteit te verlagen. Complexiteit kan je bijvoorbeeld verlagen door te standaardiseren. Als iets standaard is, kan je het sneller leveren en met minder verliezen en dus goedkoper. Een aardig voorbeeld hiervan is Infrastructure as Code. Dit is het bouwen van infrastructuur middels een script (code). Dat bouwt netwerken en systemen volgens jouw recept en specificaties, telkens opnieuw, zo vaak als jij dat wil.

Concert op dubbele snelheid?

Maar moeten we dan alles altijd maar versnellen? Dat is zeker niet zo. Er zijn wel degelijk uitzonderingen. 

In een ziekenhuis of verzorgingshuis kan je de aandacht voor patient en bewoner niet versnellen, daar is juist vertraging nodig om het contact waardevol te maken. Persoonlijke aandacht is echt een belangrijke uitzondering.

Een andere uitzondering is, iets leren. Wanneer je iets wil leren en het echt wilt doorgronden, dan heb je daar aandacht voor nodig, je moet hiervoor vertragen. Je zou kunnen stellen dat alles wat te maken heeft met “Het beleven” tijd vraagt. Je wilt een massage toch niet versnellen? of een concert? Kortom, niet alles laat zich versnellen

Fouten maken mag, mits sneller

Kijk met dit perspectief eens naar kwaliteitssystemen of standaardisatie. Vanuit de automotive weten we dat een fout in processtap 1, tien keer meer inspanning kost om die in stap 2 te fixen. Fouten maken is dus kostbaar. Dubbel eigenlijk, want de inspanning die je daaraan besteed kan je niet gebruiken om (de productie) te versnellen. Je wil fouten daarom zo vroeg mogelijk in het proces identificeren en corrigeren.

Ik denk dan ook dat standaardisatie en (proces) kwaliteit ons direct helpen te versnellen. Ik denk zelfs dat hun bestaansrecht daarin gelegen is. In de IT kunnen we daarom leren van de automotive.

IT gaat snel, IT’ers zijn langzaam

Maar we kunnen zelfs een stap verder gaan. We worden al jaren overspoeld met methoden als ITIL, Prince2, Agile, Scrum en DevOps. Blijkbaar is er telkens iets nieuws nodig om het doel te bereiken. Ik denk dat de rode draad ook hierin versnelling is. Telkens proberen we met nieuwe methodes meer grip te krijgen op IT (projecten) en resultaten. En wat willen we dan bereiken? Waarschijnlijk sneller resultaten bereiken en voorspelbaar worden. Ook hier gaat het dus  om snelheid, want voorspelbaarheid verhoogt de snelheid. Hoe meer grip men op projecten (en de uitkomsten daarvan) heeft, hoe sneller het gaat.

Zoeken naar de balans

Ik denk dat de grote uitdaging van bedrijven en organisaties vandaag de dag is: “Wat kan ik versnellen, maar wat moet ik vertragen?”. Interessant hierbij is dat we met versnelling tijd, ruimte en geld kunnen creëren om andere processen te vertragen. Bijvoorbeeld, als ik het beantwoorden van 80% van alle helpdesk vragen kan automatiseren (chatbots e.d.) dan krijg ik tijd om klanten die dat nodig hebben te woord te staan. Daarmee verbetert mijn dienstverlening en mijn concurrentiepositie.

Een ander mooi voorbeeld hiervan is Coolblue. Het overgrote deel van de verkoop verloopt via de website – lekker snel, maar voor klanten die daaraan behoefte hebben zijn er de Coolblue winkels. Daar krijg je persoonlijke, 1 op 1 , aandacht van een medewerker die je helpt met al je vragen rond de producten die je wil kopen.

Versnelling en complexiteit zijn in mijn ogen bruikbare perspectieven om ons handelen in de IT te begrijpen. Ik zou zelfs willen voorstellen het actief als criterium te gaan gebruiken.

AWSome for the enterprise

Leave a reply

Inmiddels is iedereen er wel van overtuigd. Public Cloud is de toekomst in het IT landschap. Aanvankelijk verzonnen we redenen om niet naar de cloud te moeten. We vonden de cloud bijvoorbeeld niet secure. De data stond niet in Nederland en het was alleen geschikt voor websites. Ook was het voornamelijk bedoeld voor start ups, en ehh, oh ja, de cloud was te duur. Toch zijn er door de jaren heen steeds meer bedrijven die kozen voor de Public Cloud. Blijkbaar waren onze redenen drogredenen. Of misschien hadden we de feiten onjuist, een soort alternatieve waarheden? Nu we deze vooroordelen achter ons hebben gelaten, kunnen we naar de Cloud. Of gelooft u nog steeds dat de mens niet op de maan is geweest en dat Elvis nog steeds leeft?

Natuurlijk verloopt de adoptie niet bij alle bedrijven even snel. Het is alleen niet meer de vraag “Of we naar de Cloud gaan”, maar “Wanneer”. Een interessante observatie daarbij is dat Amazon’s AWS verreweg de grootste aanbieder is van Public Cloud diensten. Interessant omdat Amazon geen speler was in het IT landschap. Ze begon ooit als webshop voor boeken, maar bouwde al snel een infrastructuur waar haar klanten ook graag gebruik van maakten. Inmiddels is ze de grootste aanbieder van Public Cloud diensten. AWS (Amazon Web Services) is vele malen groter dan alle overige Cloud aanbieders bij elkaar. Maar hoe maken we AWS geschikt voor grote bedrijven?

Multi account structuur

Wanneer je snel aan de slag wilt met Public Cloud, dan is een Amazon AWS account zo aangelegd. Voor zo’n account is slechts een credit card nodig en je bent “In business”. Alle AWS diensten staan je vervolgens ter beschikking. Ook echte enterprise features zoals Content Delivery Networks en uitgebreide security tools. Dat klinkt allemaal prima, maar gaan grote bedrijven er zo ook mee om? Is het echt een kwestie van account aanleggen credit-card-klaar? Misschien dat bedrijven op deze wijze starten, maar na verloop van tijd kiezen zij voor een structuur die past bij een enterprise.

Grote bedrijven hebben bijvoorbeeld behoefte om applicaties van elkaar gescheiden te houden. Ook willen ze uitgebreid gebruikersbeheer (met gedelegeerde rechten) te kunnen uitvoeren of IT architectuur uitgangspunten te kunnen afdwingen (zoals off site backups). Daarnaast willen ze security maatregelen kunnen treffen (zoals off site audit trails) en overzicht te houden over de kosten (consolidated billing). In AWS is dit mogelijk door meerdere accounts aan elkaar te koppelen, waarbij sommige account generieke voorzieningen verzorgen, de multi account structuur.

Root account

Nu is het belangrijk om te weten dat de eerste user die je aanlegt de root user is. Dit is de enige user binnen het AWS account waarmee alles gedaan kan worden. Het is ook de enige die het gehele account kan opgeheffen. Het dagelijks gebruik van deze root user is daarom ook af te raden. Deze root user credentials kunnen beter in een kluis worden opgeslagen. Voor het dagelijkse gebruik van de AWS console (de web toegang tot alle AWS diensten) worden gewone user accounts gemaakt.

Operationele- versus non-operationele accounts

Bij het gebruik van meerder AWS accounts wordt een onderscheid gemaakt tussen operationele accounts (zoals bijvoorbeeld een account waarin de productieomgeving van een specifieke applicatie draait) en non-operationele accounts (zoals bijvoorbeeld een account waarin alleen gebruikersbeheer wordt gedaan). AWS biedt daarom de mogelijkheid de accounts op een zinvolle manier te integreren zoals bijvoorbeeld de kosten in een billing account te verzamelen. Hiermee kunnen zaken effectief van elkaar gescheiden worden. Door de verschillende operationele accounts van elkaar te isoleren kunnen bijvoorbeeld fijnmazig rechten worden gegeven aan beheerders. Ook kunnen de omgevingen elkaar niet beïnvloeden, praktisch, want dit zorgt voor een hoger security niveau.

Welke non-operationele account zijn er nodig?

Multi Account structuur

Multi account structuur in de Amazon AWS Public Cloud

Billing

Het is praktisch om alle kosten centraal te verzamelen, ook wel consolidated billing genoemd. Dit gebeurd in een “Billing account”. De billing account wordt niet gebruikt voor productietaken, maar alleen voor de financiële afhandeling van de kosten. Zo “Hangen” alle accounts aan dezelfde credit card, of worden alle kosten middels een enkele factuur afgerekend. De voordelen hiervan zijn dat de volumekorting van AWS over het gehele bedrag wordt verkregen en dat gebruikers met een financiële verantwoordelijkheid alleen toegang krijgen tot deze billing account. Zij hebben geen toegang nodig tot een operationele account en houden toch overzicht over de kosten. Deze kosten worden overigens in groot detail inzichtelijk gemaakt, ze zijn per account en per resource type of tag te bekijken. Zo is te zien wat de kosten van storage zijn, of wat de kosten zijn van een ontwikkel account.

IAM

Naast de billing account is er een “Identity and Access Management (IAM) Account”. Dit is het account waar het gebruikersbeheer uitvoert wordt. Het enige dat in deze account gemaakt wordt zijn users, groepen en rollen. De overige accounts (zoals operationele accounts) hebben geen gebruikers. Vanuit de IAM account krijgen users rechten binnen andere accounts. De voordelen hiervan zijn evident, centraal gebruikersbeheer, een centrale account waarop users inloggen en geen users in de andere accounts. Deze manier van werken leidt ook tot een hogere mate van security en een beter controleerbaarheid daarvan. Voor de duidelijkheid, de users waarover we hier spreken zijn users die werken binnen de webconsole van AWS en niet de eindgebruikers van applicaties.

Audit

Vanuit security standpunt bezien is het wenselijk dat een audit trail veiliggesteld wordt voor het geval een applicatie of account gecompromitteerd raakt. In zo’n geval moet het audit trail aantoonbaar onveranderd zijn en op een andere plaats opgeslagen zijn. Speciaal hiervoor is de “Audit Account”. Dit account bestaat uit S3 buckets (object store – opslag van files) waarin de audit informatie wordt weggeschreven. Ieder operationeel account heeft een eigen S3 bucket waarin alleen dat account mag schrijven, ze mag er niet lezen en niet verwijderen. Uiteraard worden de kosten verhaald op de account die de betreffende S3 bucket gebruikt en netjes verzameld in de billing account.

Backup

De bovenstaande constructie wordt ook gebruikt voor backups. Bedrijven willen graag dat backups aantoonbaar veilig worden opgeslagen, liefst met aparte credentials. Dus waarom zou niet dezelfde constructie gebruikt kunnen worden als bij de audit account? En dat is precies waarom er een “Backup Account” gemaakt wordt. Deze account heeft alleen S3 buckets voor de verschillende operationele accounts waarin zij een backup mogen schrijven. Ook hier kunnen zij de backups niet lezen of verwijderen. De kosten van iedere bucket wordt verhaald op de betreffende operationele account en verzameld in de billing account.

Shared

Soms zijn er generieke diensten die beschikbaar gesteld moeten worden aan de operationele accounts, zoals bijvoorbeeld een GIT repository (een versiebeheersysteem voor software en configuratie files), een Puppetmaster (state config software) of centrale opslag van gedeelde informatie. Het gebruik van een zogenaamde “Shared Account” dan erg handig.

My Organization

Inmiddels heeft Amazon een nieuwe dienst gelanceerd die het opzetten en beheren van een multi account structuur vereenvoudigen, “My Organization”. Organizations geeft overzicht over de gekoppelde accounts (de billing account is leidend). Centraal kunnen bijvoorbeeld beperkingen op andere accounts aangelegd worden.

Tot slot

Er is inmiddels een goed beeld geschetst over een enterprise structuur in AWS. De non-operationele accounts zorgen voor overzicht, inzicht en betere isolatie van enterprise functies. Middels uitgebreide autorisatie kunnen users rechten krijgen op de verschillende functionele gebieden die zo gecreëerd zijn. De hier beschreven non-operationele accounts zijn wel de belangrijkste, maar er is geen beletsel er nog meer te maken als dat opportuun mocht zijn.

Met het ondersteunen van een dergelijke enterprise structuur toont Amazon aan dat Public Cloud klaar is for the enterprise, maar dan wel met de juiste inrichting.

Adopteert Microsoft de OSS gedragscode?

Leave a reply

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.