Het lijkt wel of we steeds proberen uit de lengte te halen wat er in de breedte gewoon niet altijd in zit. Zo proberen we applicaties die nimmer ontworpen waren voor virtualisatie en gedeeld resource gebruik toch in het keurslijf van standaardisatie te drukken met bijvoorbeeld Remote Desktop Services. En hiermee maken we van de eerdere correctieve ‘ctrl-alt-del’ gewoonte een preventieve door elke nacht servers te herstarten.
Nu is regelmatig herstarten van een server natuurlijk niet slecht, twintig jaar geleden moest ik dit ook al wekelijks doen voor de mainframe om zodoende de aangebrachte wijzigingen actief te maken. En nu veranderen dingen natuurlijk sneller dan ze vastgelegd worden maar mijn tablet herstart ik desondanks met een veel lagere frequentie, meestal als ik vergeten ben deze op te laden. Het is dus best een rare ‘Best Practice’ om servers te herstarten omdat er onopgeloste problemen met applicaties zijn.
Log-a-ritme
Zolang alleen naar functionele oplevering gekeken wordt en geen rekening gehouden wordt met overdraagbaarheid, efficiëntie en onderhoudbaarheid blijven we dus achter de feiten aanhollen.
Universele oplossingen blijven hierdoor knellen met het maatwerk dat er nodig is, waardoor relatief kleine veranderingen grote impact hebben op de gevoelswaarde van ict. Zo wordt met Agile software ontwikkeling nog onvoldoende gekeken naar aspecten die de mogelijkheden voor Root Cause Analysis in de keten verbeteren. Dat laten Coding Cowboys nog steeds over aan het implementatieniveau waardoor preventief herstarten een begrijpelijke ‘Best Practice’ wordt. En zoeken naar de bottleneck is er ook niet eenvoudiger op geworden met de dynamiek van virtualisatie en load balancing. Het heeft veel gelijkenis met het spel ‘Whack-a-mole’ omdat de nodige informatie in logfiles simpelweg ontbreekt.
Door ontbreken van gegevens over bezetting en belasting worden de verschillende lagen van de infrastructuur zoals netwerk, opslag en servers op basis van vuistregels gedimensioneerd. Maar met de zwaarte die aan de factoren gegeven wordt is hier geen sprake van een lineaire schaal waarmee gewogen wordt. Eerder een logaritmische omdat goedkoper, flexibeler en betrouwbaarder moeilijk tegen elkaar afgezet kunnen worden.
Lengte x breedte
Lagen van de architectuur zoals applicaties, servers, netwerk en opslag vormen samen dan wel een keten maar het beheer hiervan is dikwijls opgedeeld naar techniek. En dus kunnen we wel precies zien welke resources en hoe zwaar deze belast worden binnen de verschillende lagen maar niet door wie. En horizontaal schalen, door de server farm te vergroten zal een bottleneck in andere lagen natuurlijk niet oplossen. Zo wordt de end-to-end response, welke gewoon een optelsom van de prestaties van alle lagen in de infrastructuur is, nog steeds gemeten aan de bovenkant. Reactief dus via gebruikers die klagen over trage applicaties en hangende terminal servers bijvoorbeeld. En hoewel er geen gebrek is aan beheertools is het hierbij net als met de examens waar tachtig procent altijd gaat over dat ene boek dat je niet hebt gelezen. Gelukkig zijn deze steeds vaker multiple choice en wie gokt komt dus al een heel eind.
Virtualisatie gecombineerd met load balancing geeft dus ook meerkeuze oplossingen waarbij we onmogelijkheden direct kunnen doen maar wonderen altijd wat langer blijven duren. Zo kunnen we problemen in applicaties isoleren met Virtuele Desktops (VDI) zodat geheugen lekken niet leiden tot verstoringen. Maar dit lost niet problemen in de andere lagen op en dus krijgen we weer nieuwe uitdagingen zoals ´boot storms´ als er herstart moet worden.
Oud-er(n)-dom
Hoewel hier geschetste problemen natuurlijk niet exclusief zijn voor gecentraliseerde desktop omgevingen zijn deze hier het sterkst herkenbaar. In aangeboden applicatie set zitten namelijk nog weleens erfenissen uit de tijd van Windows 95, oplossingen die ooit gemaakt zijn op basis van dezelfde principes als Agile software ontwikkeling. Gebruikers maakten met Pascal, Visual Basic en andere programmeertalen applicaties voor de eigen afdeling. En natuurlijk werd er niet gedacht aan overdraagbaarheid, rekening gehouden met multiprocessors, 64-bits adressering, gedeeld resource gebruik of alle andere technologische vernieuwingen. Dat deze generatiekloof voor problemen in de race om resources kan zorgen is ook niet nieuw. Het is eerder een telkens terugkerend probleem omdat techniek gewoon sneller veranderd dan de applicaties.
Met desktop virtualisatie kunnen we de levensduur van applicaties verlengen maar dus niet het geheugenbereik verbreden, de interne werking efficiënt verbeteren en keten beter afstemmen. Met het stapelen van oplossingen blijven we proberen uit de lengte halen wat er in de breedte gewoon niet in zit.
Ewout,
De uitdaging van een infrastructureel project ligt 90% in het aanbieden van applicaties. Het realiseren van deze zaak is juist de grootste kostenpost in de offerte. Wanneer een applicatie niet geschikt is voor de nieuwe omgeving (VDI, RDS etc) dan wordt geprobeerd dit probleem met de beschikbare technologieën op te lossen. In dit kader wordt geïnvesteerd in de oplossingen die de betreffende applicaties isoleren of andere technologieën waarmee je de door applicatie vereiste CPU/geheugen of andere negatieve aspecten, in kan perken. Dit is naar mijn mening een verkeerd beleid! Zo los je het probleem niet op, je schuif het probleem maar door!
Een opdrachtgever doet er verstandig aan als hij eerst voor zichzelf inzichtelijk maakt welke applicaties met welke eigenschappen, de mate van geschiktheid, wendbaarheid, beheerkosten etc met zich meebrengt. Een lange applicatielijst betekent veel kosten op verschillende ict-zaken tijdens en na het project. Wanneer deze zaak geëlimineerd wordt door de consolidatie van applicaties bijvoorbeeld door het inzetten van ERP/CRM oplossingen die verschillende functionaliteiten van verschillende applicaties in een pakket aanbieden, bespaar je op verschillende ict kosten(beheer, licentie,tooling,infrastructuur etc) die aan applicaties gerelateerd zijn.
Een korte applicatielijst met de juiste en vernieuwde applicaties erop betekent meer flexibiliteit, wendbaarheid, besparing en ook lage drempel voor de innovatieve stappen zoals BYO, cloud of veel andere zaken in de toekomst.
Rekening houden met hardware en performance (vanuit gebruikersoogpunt) meenemen in bij realiseren van nieuwe software is inderdaad buitengewoon belangrijk.
Het is een beetje jammer dat de auteur afgeeft op Agile Software-ontwikkeling. Juist bij Agile software-ontwikkeling moet bruikbare software zo snel mogelijk ‘live’ komen voor gebruikers. Software met een slechte performace is niet bruikbaar.
Het is een best-practice performance mee te nemen in de definition of done van software. Functionaliteit is dan pas klaar als aangetoond kan worden dat de performance, van gebruikersoogpunt goed is. Hoe? B.v. met dagelijks, of vaker, automatisch performance te meten. Of door functionaliteit eerst aan een beperkte gebruikersgroep beschikbaar te stellen.
Tot slot, agile vereist samenwerking met alle partijen, waaronder ook beheer. Technisch opsplitsen van softwareproject en/of -team in b.v. backend, frontend, databasebeheer, systeembeheheer is uit den boze.
Reza,
Je haalt een goed punt aan door te stellen dat rationalisatie van applicatie portfolio voor een grotere homogeniteit met minder erfenissen en meer gelijke lifecycles zorgt. Maar helaas wordt in de praktijk nog weleens een andere ‘practice’ bedreven omdat er ook andere argumenten gebruikt worden voor de keuze van een SBC omgeving. Bijvoorbeeld als oplossing voor het continueren van applicaties welke niet compatible zijn met Windows 7 om maar iets te noemen.
Gerbrand,
Op papier is de wereld plat en natuurlijk dient bruikbare software rekening te houden met de prestatie maar wordt er ook rekening gehouden met multi-user mogelijkheden van de SBC omgevingen waar ik het in dit artikel over heb?
Niet zelden doet een opgeleverde applicatie het inderdaad prima op de desktop, met één gebruiker die alle rechten op de resources heeft of met een beperkte gebruikersgroep zoals je zelf aangeeft in reactie. Maar als dit veranderd beginnen soms de problemen zoals de voorbeelden van verschillende andere reacties al aangeven. En dan is er vooral behendigheid van beheer nodig – met de juiste instrumenten – om te voorkomen dat applicaties de resources excessief belasten.
Ik hoor wat over legacy die verplaats wordt naar een moderne virtualisatie omgeving, maar dat er dan wat problemen optreden mbt 32 bits processen en het lekken van geheugen.
Met andere woorden, “get rid of the legacy”. Maarja Legacy heeft zich bewezen en afstappen hiervan kan behoorlijk complex zijn. Cloud computing met moderne software bevat deze ballast uit het verleden niet. Maar sommige bedrijven kunnen gewoon nog niet over. Zoals ik al vaker heb verkondigd is dat geen probleem van je klant, die heeft wellicht wel toegang tot een leverancier die cloud computing aanbied.
Vasthouden aan legacy is geen optie. Je zult dus aan de rand kunnen beginnen om op een agile (hehe) manier bepaalde processen wel op een moderne manier op te pakken. Denk aan mail, samenwerken, documenten et cetera.
Ik geloof niet in het in stand houden van legacy daar kun je me ook niet voor inhuren. Het omzeep helpen van legacy kan ik wel (legacy van de toekomst). Rationaliseren is de sleutel.
Voor mij waren de reacties beter te lezen dan het artikel zelf, dank daarvoor.
@ Henri,
Als Cloud-evangelist zijnde is dit natuurlijk wel een beetje preken voor eigen parogie. En natuurlijk is het de meest ideale wereld om de legacy applicaties uit te bannen. Alleen gaat dat in de praktijk natuurlijk niet altijd op. Wat zou de wereld ideaal zijn als we alle legacy spullen altijd direct uit kunnen faseren. Alleen gaat die ballon niet voor iedere organisatie op. En zit er ook een zeer groot risico aan vast.
Is het ideaal en heeft het voordelen om van legacy applicaties af te stappen? Ik denk dat dit per organisatie verschilt. Kan de legacy applicatie de komende jaren nog doen wat de organisatie vraagt? En kan je er nog support / ondersteuning op krijgen? En welke risico’s komen er om de hoek kijken bij een mogelijke migratie? Last but not least wat kost het en wat levert het op? Dat zijn vragen die je je als organisatie zijnde zelf af moet vragen voor dat je zo’n complex migratie traject in gaat. De nieuwe omgeving zoals cloud is niet altijd per defenitie beter en goedkoper.
@Henri
Het lijkt me niet handig om aan de rand te beginnen door de client naar de cloud te brengen en de server ongewijzigd te laten. Tenslotte zijn veel desktop applicaties ooit ontwikkeld vanuit client-server concept. Voorzie in dat geval nog wel wat problemen met bandbreedte en latency als bijvoorbeeld ERP systeem vanuit de cloud benaderd moet worden. De legacy zit dus wat dieper omdat SBC omgevingen ook vaak gebruikt worden voor ontsluiten van omgevingen die gecentraliseerd zijn, zoals veel remote office oplossingen bijvoorbeeld.
@Ruud, @Ewout,
Evangelist is een jeukwoord wat ik onlosmakelijk zie van religie. Maar ja, ik geloof ik in cloud computing, maar zal de crux van mijn reactie nog maar herhalen: Jij als organisatie kunt wel getrouwd zijn met legacy, maar jouw klant is niet getrouwd met jou (behalve als je SAP of iets dergelijks heet). Dus als je diensten duur zijn danwel niet voldoet aan de verwachting van de klant zul je dus wel *moeten* schakelen. Als je bedrijf prima functioneert met Legacy en er geen dreiging is: Don’t change a winning team! Ik verkondig absoluut niet dat legacy slecht en vies is, het werkt bewezen.
Maar ik zal mijn gedachten hardop uitspreken: Ik ken veel mensen die ingehuurd worden voor hun expertise van legacy en daar heel goed in zijn. Zulke mensen zullen je echter nooit verder brengen.
Cloud computing heeft naast legacy nog een groot obstakel en dat is de vatbaarheid van (buitenlandse) overheden die zich toegang kunnen verschaffen tot jouw data.
Volg een keer een workshop bij me en ontdek de brute kracht achter cloud computing principes, waarom het bijna onvermijdelijk is en hoe je dat met deze uitdagingen omgaat.
Want *hell yeah* afscheid nemen van legacy is een weg vol risico’s & uitdagingen, maar in mijn ogen zeker op termijn onvermijdbaar.
De snelheid waarmee Amazon Webservices volwassen wordt vind ik erg bedreigend. Dan zie je dat vlieguren maken heel belangrijk is om een volwaardig cloud computing provider te worden.
Voor alles is wat te zeggen, tegenwoordig geloof ik zelfs dat je met de principes van cloud computing al een heel eind komt zonder echt een externe cloud provider in te schakelen. Maar dat is een verhaal voor een andere keer.
@Henri
Volgens mij gaan we langs elkaar heen want dat de cloud mogelijkheden biedt heb ik al eens gezegd in expertsessie. Daarbij maakte ik wel de kanttekening dat we er geen wonderen van mogen verwachten. Uiteindelijk is het gewoon een delivery model, aanvullend op de vele anderen die we al hebben. Zoals SBC, welke nog weleens als ‘stepping stone’ gebruikt wordt voor cloud(achtige) oplossingen waarbij back-end draait bij een externe partij.
Terugkomend op je eerste reactie valt er natuurlijk wel wat voor te zeggen als client applicatie al vanaf het ontwerp multi-user gemaakt wordt. Want misschien dat je artikel niet interessant vindt maar de titel geeft al aan dat legacy niet oneindig op te rekken is, niet zonder uitdagingen in elk geval. Maar zoals ik aangeef met meerkeuzen is er meer dan een enkeltje naar de cloud.
@Henri
Of de klant wel of niet met legacy “getrouwd” is, is sector afhankelijk.
In de “vluchtige” ICT, zoals web- en kantoorapplicaties zal dit veel minder vaak voorkomen dan in bijvoorbeeld de embedded sector. Medische apparaten, bagage-afhandelingssystemen, wafer steppers, electronen microscopen zijn typische voorbeelden van lange termijn (>10 jaar) investeringen. Wanneer een klant een apparaat koopt van €1M of meer, wil hij dit niet vervangen na 3 jaar omdat er legacy code inzit. Ook als leverancier wil je dit niet; vervangen is immers een kostbare operatie.
Op deze apparaten dient echter nog wel onderhoud gepleegd te worden, al is het maar een OS security patch of virusscanner update. Maar als hierdoor het gedrag van het systeem veranderd (denk aan performance wijzigingen door nieuwe virusscanner) is het nog steeds goedkoper om de legacy code in te duiken in plaats van de klant een nieuw apparaat aan te geven.