Whitepaper
Kleine iteraties, grote eisen: Scrum-ontwikkeling en je platforms
Kleine iteraties, grote eisen: Scrum-ontwikkeling en je platforms Met de mond beleidt een IT organisatie meer en meer Agile en kortcyclische methoden, maar de praktijk is weerbarstiger. Juist wanneer je Scrum of vergelijkbare technieken wilt invoeren blijkt dat er heel wat meer omgeturnd moet worden dan de mindset van gebruikers, informatie-analisten en ontwikkelaars: de nu verfoeide ‘waterval’ blijkt tot in de poriën van je platforms en datacenter-inrichting te zitten. Ook daar moet veel aan veranderen om Agile op te leveren, en je ziet een aantal trends en twee voorbeeldcases langskomen. Bottom line: termen als private clouds en self-service provisioning zijn niet voor niets populair, en elke vendor in je platformstack moet daarin meewerken! Agility in het ontwikkelen Agile betekent snel, in kleine teams, resultaten boeken tot aan produktionele systemen toe. Of de gebruikte techniek nu het klassieke ‘ prototyping’ is of het moderne scrummen of DSDM dat meerdere vormen kent maakt niet zoveel uit. Mits maar conform hun bedoeling opgezet; DSDM bijvoorbeeld zie je dicht bij z’n agile-roots gebruikt worden maar ook als een vorm van waterval, en prototyping blijkt zich ook in ruimere contexten te kunnen nestelen dan zijn wortels doen vermoeden. In dit paper gebruiken we scrum als voorbeeld, juist omdat het door zijn relatieve nieuwheid nog weinig mengvormen kent; de conclusies voor de platforms gelden echter grosso modo voor elke agile methode. Juist omdat de insteek vanuit de platformkant is vatten we scrum slechts kort voor je samen. De diverse stakeholders voor een nieuwe applicatie, inclusief eindgebruikers, worden in ‘pressure cooker’ workshops samengebracht en moeten in kleine incrementen specificaties opstellen. Dat gebeurt zoveel mogelijk met visuele tools inclusief schermen, en relatief beperkt middels detail-teksten. Zo’n increment heet een Sprint, en een hele applicatie bevat er veelal minstens vier a vijf. Resultaat van de Sprint (dus een reeks workshops die steeds één onderdeel verder uitdiept) is het visuele prototype en een set definition-of-done documenten; plus een backlog van zaken die later nog gedaan moeten worden danwel doorschuiven naar andere sprints. Het gevolg aan de platformzijde is dat de traagheid (en relatieve degelijkheid) van het inrichten en weer vrijgeven van een ‘waterval-teststraat’ gewoon niet meer kan. Er zijn veel meer en kortere incrementen nodig, en liefst parallelle releases – bijvoorbeeld Sprint 3 in functionele test en Sprint 4 in loadtest. En elk van die incrementen heeft in principe dezelfde schone startset aan testdata nodig, geïsoleerd van wat de andere Sprints doen zodat men elkaar niet onderling kan dwarszitten. Je raadt het al: de oplossing zit in de richting van IT-as-a-service oftewel ‘ private clouds’ maar met veel minder nadruk op ITIL operationeel beheer dan voor gewone produktie. De platform-club ondersteunt immers alleen operating system en (virtuele) ‘hardware’, de hele stack bovenop het OS (inclusief Dotnet
of JEE middleware) is Admin mode voor de developers hoewel je bij loadtest al meer produktie-like beveiliging ziet. Maar loadtests komen pas aan het einde van een Sprint en hebben al meer karakteristieken van normale produktieapplicaties, dus de ITIL-aspecten daarvan vind je meer in whitepapers over gewone flexibele datacenter-inrichting. Aan de andere kant heeft het ontwikkel- en testcircus ook behoefte aan specifieke applicatie- en databaselogica vanwege de testdata, en ook die hebben extra eisen indien je agile gaat. Trends in platforms Op alle fronten is virtualisatie aan het landen in je moderne multiplatform-landschap, net zoals de fundamenten ervan al tientallen jaren bekend waren in singleplatform-stacks zoals pakweg z/OS of Solaris. Voor de server zelf gaat het om hypervisors: grote namen zijn VMware, Hyper-V, XenServer en KVM. Maar vlak ook IaaS clouds niet uit, met name EC2 en Azure VM role bieden hier soms goede uitwijk of zelfs vervanging voor een interne private cloud. Natuurlijk is het dan wel gewenst dat de externe en interne private cloud vanuit de beheerder gezien zich als een enkele resource pool gedragen, en dat is bijvoorbeeld bij Hyper-V samen met Azure best goed haalbaar. Naast de hypervisor heb je voor je hele stack (ook netwerk en opslag) een configuratiebeheertool nodig met nadruk op ‘runbook automation’: o.a. Tivoli, CA, HP, Microsoft. Maar een hypervisor zelf biedt onvoldoende als niet de hele ‘keten’ er achter ook goed aanstuurbaar is als resourcepool, inplaats van uit legacy hardware zoals DAS disks en volledig hardwarematige networkswitches te bestaan. Voor het netwerk betekent dit dus dat de netwerkswitching nauw moet samenwerken met de software switching binnen de hypervisor; bij voorkeur vallen beiden onder dezelfde netwerkbeheerclub en dus niet deels onder het server-beheer. En voor de opslag betekent het dat je een opslagbeheertool nodig hebt, minimaal Storage Resource Management (SRM) maar liever nog een kompleet Storage Operating System, dat alle opslag als één geheel kan tonen en inzetten; inclusief gebruik van steeds belangrijker functies zoals redundante clusters, replicatie, deduplicatie en het met name voor agile tests essentiële ‘ cloning’. Zulke beheersoftware kun je minimaal verwachten van alle grote opslagleveranciers: NetApp, EMC, HP, Dell en Oracle. We zoomen verder in op voorbeeldvendor NetApp. Hun Data ONTAP produkt profileert zich echt als een ‘storage operating system’: een softwarelaag die volledig via de browser bediend wordt en zelf via API’s communiceert met alle relevante hardware. Belangrijke concepten van Data ONTAP zijn: • Storage VM’s, een groep opslagresources (connectiviteit, capaciteit en performance) met een bepaalde SLA. Binnen zo’n SVM zal de hypervisor weer logische VM’s gaan maken. SVM’s doen voor opslag wat hypervisors voor servers doen: ze ontkoppelen data-opslag van specifieke hardware, en kunnen bijvoorbeeld ook data verhuizen zonder dat de hypervisor-werking zelf zichtbaar beïnvloed wordt. Een soort ‘Storage Vmotion’ dus. • Deduplicatie en compressie, om ruimtebesparingen te realiseren – ideaal voor testsets. • Snapshot en Cloning, wat met name voor ontwikkel- en testscenario’s essentieel kan zijn. Natuurlijk bieden de hypervisors zelf al elementen van deduplicatie en cloning, maar het mooie van Data ONTAP en vergelijkbare appliance-aangepaste tools is dat veel van het werk kan worden uitbesteed aan de NAS/SAN hardware zelf – dus beduidend sneller gaat dan pakweg een ‘clone’ operatie op gewone DAS opslag in een VMWare Wintel/Lintel machine. Casus 1: Financieele instelling Om de gevolgen van agile development op platforms en opslag helder te maken krijg je twee voorbeeldcasussen, toevallig beiden uit de financieele sector. Te beginnen met eentje in Europa, die wel ver is in de scrum-invoering maar de platformgevolgen ervan nog niet al te tool-gestuurd weet op te pakken. Hun startpunt is DSDM doch dat werd primair gebruikt als flat-demand-model voor een waterval ontwikkelmethode; PRL’s werden in detail uitgeschreven en lang niet altijd in gezamenlijke sessies van gebruiker/informatie-analist/ontwerper. Nu is er
overgestapt naar een echt drielagenmodel qua softwarebouw. Voor de ‘business service layer’ zijn er nog steeds klassieke PRL’s, maar die worden door designers afgeleid van de agile designs in de andere twee lagen; scrumming etc. zou hier niet werken omdat deze layer totaal geen user interface heeft. Voor de ‘process layer’ wordt een BPMspecifieke agile methode met BPMN 4GL-model als ‘levend prototype’ gebruikt. En tot slot voor de presentatielaag, waarvan je hier de meeste details leest, is het standaard scrum. Dat is zo gekozen omdat scrum het beste werkt bij applicaties met een UID; ook elders in deze organisatie, o.a. voor inrichting van CRM- of Financial pakketten, wordt scrum gebruikt. De scrumworkshops richten zich op bouwen van Ajax-schermen in Java gekoppeld aan een Portal. De link met de Rest-services die vanuit de BPM laag gaan komen wordt initieel met stubs gedaan. De Sprints richten zich op ‘user journeys’ door reeksen prototype-schermen; het resultaat is geen PRL maar een storyboard van deze journey plus interfacebeschrijving. En dat storyboard kan vervolgens vrij snel, à la de aloude HTML-naar-JSP route, worden omgezet in een skelet van een Java Ajax-widget. In deze taakverdeling met de andere twee layers is dat het skelet van het proces min of meer parallel ontwikkeld wordt in het BPM team en het presentatieteam, en dat qua eindgebruikers ook dezelfde mensen aan beide Sprint-teams worden toegevoegd. Zit er een verschil in de tijdslijnen dan heb je namelijk teveel regressie als een interface toch in één der zijden niet haalbaar blijkt. De gevolgen voor de platforms laten zich raden: er zijn niet meer 1 maar 3-4 testomgevingen tegelijk nodig vanwege de korte cycli. Er wordt ingezet op intensief gebruik van VDI voor de ontwikkelaars, en op server-VM’s voor alle tests. Qua netwerk worden alleen standaard bouwstenen gebruikt, zodat de standaard switching van VMware (binnen de hypervisor) en Cisco (voor het core network) vooralsnog voldoende is. De problematiek van het inzetten van een komplete Service Oriented Archicture keten bleek pas in de loadtest enigszins oplosbaar, in de fasen ervoor moeten veel stukken van de keten door stubs vervangen worden. En dit alles wordt gedaan deels met Xen en deels met VMware, zonder goede scripting. Dat is wel een urgente wens, en wordt naar gekeken samen met platforms; opslag is een essentieel onderdeel van deze private cloud. Voor de testdata heeft men gelukkig al vrij goede sets van database-vulling met scrambling; de database-servers hebben een eigen set VM’s en worden steeds netjes gecloned als weer een nieuwe test-keten nodig is. Casus 2: ING Direct Australië met hun “Bank in a box” Bij deze casus is niets gepubliceerd over de exacte ontwikkelmethode, anders dan dat hij primair Dotnet-gebaseerd is inclusief MS Team Foundation Server als code-repository en Virtual Lab Management als workflowmodule voor provisioning. Het zijn typisch werkwijzen die met agile ontwikkeling gebruikt worden, en de wens van ING Direct was ook expliciet om sneller nieuwe ontwikkel- en testomgevingen te kunnen provisionen. Inclusief een stuk Unix en Oracle, naast de mainstream Dotnet en SQL Server ontwikkeling De truuk voor ING was om legacy opslaghardware te combineren met nieuwe NetApp opslag, een Hyper-V gebaseerde blade server inrichting met Cisco UCS blades en hierbovenop een Microsoft-centrische set beheertools. Je ziet de stack van ‘onderen’ (de hardware bouwstenen) naar ‘boven’: datgene dat de ontwikkelaars/testers via selfservice bedienen, met alleen zware taken gereserveerd door beheerders.
• Een NetApp iSCSI SAN. Dit heeft deduplicatie, compressie en fouttolerantie geconfigureerd, en de ‘FlexClone’ optie voert de cloning van een VM uit zodra dat vanuit de hypervisor gevraagd wordt – veel sneller dan dat de hypervisor dat zelf met DAS opslag had kunnen doen. • Data ONTAP als aansturing van de nieuwe NetApp disks maar ook van de legacy SAN array disks waarop de SQL Server en Oracle databases staan. • Cisco UCS bladeservers en Nexus switches, zowel de ‘core’ switches rond de blades als de ‘edge’ switches naar de werkstations toe. Vooralsnog met switching tussen de diverse VM’s in een UCS-systeem door de ingebouwde
Hyper-V switch zelf. Eerder dit jaar kwam Cisco’s Nexus 1000V Softswitch voor Hyper-V uit dus alle kans dat in een volgende Bank-in-a-box versie deze 1000V toegevoegd gaat worden. Groot voordeel hiervan is geïntegreerde aansturing van alle switching, fysiek en virtueel. • Als generieke softwarelaag bovenop deze stack Microsoft System Center. Met name Virtual Machine Manager en System Center voor de configuratie op respectievelijk Hyper-V en Windows-niveau, Operations voor meting van de belasting en Orchestrator (voorheen Opalis) voor de hele uitvoering van de runbooks. • En het allerhoogste niveau, vanwaaruit ontwikkelaars en testers selfservice jobs voor provisioning en deprovisioning afschieten, is Microsoft Test Manager met Team Foundation Server of SC-VMM. Dit niveau is op allerlei punten gelinkt aan de diepere lagen van de stack: tijdens het testen wordt bijvoorbeeld vaak eerst NetApp SnapDrive gebruikt om een snapshot te maken en daarna SnapRestore om terug te keren naar de situatie-voor-de-test. • Zoals gezegd houden de beheerders zich vooral met het zware werk bezig. Zoals onderhoud op de script zelf, en onderhoud van de ‘gold images’ voor Windows of Linux VM’s met alle patches of voor een database-snapshot met alle korrekte versies en recente maar toch anoniem gemaakte testdata. Gevolg voor ING Direct was dat men van twee testomgevingen over kon stappen naar tientallen Bank-in-a-box omgevingen, zonder parallel stijgende opslagbehoefte door inzet van o.a. cloning en deduplicatie. En verder kon men overstappen van 12 weken (!) doorlooptijd voor een extra testomgeving naar 10 minuten, en van een testdata refresh die een vol weekend kostte inclusief produktievertraging naar een data cleansing via een gesnapshotte ‘staging environment’. Deze data refresh operatie werd daarmee onbemensd en veroorzaakt nauwelijks meer vertragingsload op de produktiedatabase.
Relaties tussen casussen en de gegeven trends in platforms/NetApp Okay, de casussen hebben vrij veel detail dus het kan geen kwaad nog eens samen te vatten op welke punten ze de gesignaleerde overall trends illustreren:
• Netwerkswitching moet nauw samenwerken met de software switching binnen de hypervisor:
de drielaagsscrum-casus ontwijkt dit probleem door vooralsnog alleen standaard bouwstenen te gebruiken. De ING Direct-
casus mikt een stuk hoger maar wordt gedwarsboomd door de op hun moment van beslissing nog te beperkte software-switching opties van Hyper-V; sinds begin 2013 (met Server 2012 en de nieuwe Cisco 1000V for Hyper-V) kan dit gelukkig beter. • Opslag eist minimaal Storage Resource Management (SRM) maar liever nog een kompleet Storage Operating System, dat alle opslag als één geheel kan tonen en inzetten: de drielaags-scrum-casus lost dit op door standaard database-VM’s, met (te) beperkte scripting. De ING Direct-casus is op dit vlak beduidend verder door inzet van NetApp Data ONTAP. Kleine iteraties, grote eisen, grote impact Agile ontwikkeling heeft nogal wat gevolgen. Je wilt immers ófwel sneller applicaties gereed hebben ófwel meer applicaties tegelijk ontwikkelen, en dat betekent dat platform- en datacenter-inrichting ook moet gaan veranderen. In de beschreven casussen zie je twee verschillende insteken daarvoor. De eerste casus had al enkele virtualisatiebouwstenen klaarstaan en moest toen scrum invoeren doch op platform-niveau ‘roeien met de beschikbare riemen’. Dát men heel wat klaarspeelt is knap maar de hoeveelheid handmatige arbeid van ontwikkelaars en beheerders is ongewenst hoog, en op de scrum-backlog figureert prominent de wens om de platforms nu eens beter te automatiseren. In de tweede casus kon men juist wél kiezen voor een totale herinrichting van het platform, en zijn de resultaten aan die kant ook spectaculair beter en vooral minder menskracht kostend dan die voor de eerste casus. Doch jouw eigen situatie zal beslist weer in andere stukken van het mogelijkheden-spectrum zitten dan de twee genoemde. De gegeven eisen aan serverhardware, netwerk en opslag gelden in ieder geval als ‘endstate’ ongeacht de omstandigheden; hopelijk kun je in jouw geval op zijn minst serieus laten kijken naar de mogelijkheden die partners zoals NetApp op dit vlak bieden!
