Oud maar nog niet vervangen

21-12-2012 14:15 | Door Ewout Dekkinga | Lees meer artikelen over: Agile | Er zijn 23 reacties op dit artikel | Permalink
Computable Expert
Ewout Dekkinga
Ewout Dekkinga

IT Architect Unisys

Expert van Computable voor de topics: Datacenters, Cloud Computing en Systeembeheer

Meer

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.
Reacties op dit artikel
De redactie vindt deze reactie: GoedPaVaKe, 21-12-2012 22:13
Een leuk, en heel herkenbaar artikel ... althans, voor de wat oudere rotten (no offense!) in het vak.
 
De oudere jongeren in ons vakgebied komen nog uit een tijd dat je het moest doen met een beperkte hoeveelheid geheugen, waar je afgerekend werd op het aantal klokcycli dat je programma verstookte op het mainframe, en waar opslagruimte nog een klein kapitaal kostte.
Vandaag de dag is het (relatief) makkelijk om er wat meer cpu power, disk- of memory bij te plaatsen. Men wordt nagenoeg niet meer beperkt in mogelijkheden.
Keerzijde hiervan is, mijns inziens, dat een stukje vakmanschap uit het verleden aan het verdwijnen is.
 
Binnen de embedded sector kom je dit stukje vakmanschap nog wel tegen, vooral gedreven door limitaties in hardware enerzijds, en het vereiste real-time gedrag anderzijds.
 
Overigens reikt het verder dan alleen efficiënt programmeren. Ook aan systeemkennis schort het nog wel eens. Een mooi voorbeeld (volgens mij heb ik het al eens genoemd) is de applicatieprogrammeur die het overzicht van een helpdeskapplicatie gemaakt had. Dit overzicht werd weergegeven in een matrix-vorm van 10 kolommen x 20 rijen (200 cellen dus)
Voor iedere cel werd eerst de data overgestuurd, en vervolgens werd aan het systeem gevraag of de data goed aangekomen was. Per cel werd dus 3 keer de afstand server-client afgelegd (sturen data, vragen bevestiging, bevestiging).
Tijdens het testen werkte dit goed. Met een responsetijd van 1ms duurde het opbouwen ongeveer 3x200x1ms, dus lekker snel.
De redactie vindt deze reactie: OKEwout Dekkinga, 22-12-2012 0:25
@PaVaKe
 
Dat het herkenbaar is voor jouw vermoedde ik al, ervaring verkrijg je namelijk niet uit boeken hoewel sommige het herlezen ondanks alle 'vernieuwingen'die we hebben waard zijn. Bijvoorbeeld over processor architecturen, protocollen, geheugenbeheer en schijven om er een paar te noemen. En zoals ik al aangaf is het inderdaad makkelijk om resources bij te plaatsen via horizontale schaling maar dat hiermee vaak ook weer nieuwe uitdagingen geïntroduceerd worden. Welke we uiteindelijk weer oplossen met nog meer techniek omdat de applicaties 'untouchable' zijn en we dus niet alleen de architectuur maar ook het beheer stapelen. En alle hulpmiddelen hebben natuurlijk ook weer resources nodig waardoor soms wel 20% van de beschikbare capaciteit hiervoor gebruikt wordt.
 
En je voorbeeld met testen is weer herkenbaar voor mij en was de reden om dit stuk te schrijven. Want omgevingen worden vaak theoretisch gedimensioneerd terwijl dit dus beter empirisch gedaan kan worden. Maar helaas wordt dit dus nog vaak achteraf gedaan als blijkt dat de lengte geen rek meer biedt.
 
De redactie vindt deze reactie: OKPaVaKe, 22-12-2012 12:16
op één of andere manier is er een stuk tekst weggevallen:
 
(binnen de seconde)
 
Echter, toen de applicatie in gebruik werd genomen klaagden de gebruikers in Engeland steen en been over de performance. De programmeur wees direct naar het netwerk, daar waar wij als netwerkbeheer niets vreemds zagen in de performance. Waar meneer de programmeur echter geen rekening mee had gehouden is dat de afstand Nederland-Engeland een wat grotere roundtrip delay heeft dan de afstend client-server in een lokale testopstelling.
Met een roundtrip delay van 20ms kom je al snel op responstijden van boven de 12 seconden.
 
Toen we hem dat uitgelegd hadden, vroeg hij of we dat niet op konden lossen. Met enig cynisme hebben we hem toen gevraagd hoe hij gedacht dat te doen, door de fysieke afstand Engeland - Nederland te verkleinen?
 
Je kunt het proberen in de lengte of in de breedte op te lossen, maar de toegevoegde waarde van een goede IT-er zit in de derde dimensie: de diepte, ofwel ervaring.
De redactie vindt deze reactie: OKJan van Leeuwen, 22-12-2012 13:26
Wat opvalt in dit artikel is dat beschreven wordt hoe belangrijk een systembeheerder is. Die zelfde beheerder die door "cloudfans" als overbodig beschreven wordt.
Om te kunnen overzien wat tot ongewenste resultaten bij de eindgebruiker leidt is mijns inziens nog steeds een beheerder nodig die een integraal beeld heeft van de gebruikte harware/software/netwerk en daardoor bottlenecks tijdig kan waarnemen.
Maar ja ook ik ben ook al wat langer in de IT . . . .
De redactie vindt deze reactie: OKPascal, 22-12-2012 20:20
Aardig en herkenbaar verhaal, en de reacties van PaVaKe en JanVanLeeuwen kan ik dan ook onderschrijven.
Sprak vandaag uitvoering met een student technische automatisering die geheel volgens verwachting had vastgesteld dat zijn opleiding eigenlijk voornamelijk apentruukjes leert maar dat de basis niet echt doorkomt. Tja waar herken ik dat dan weer van he...
 
Een bijkomend probleem met de door Ewout genoemde voorbeelden is dat je de applicatie vaak aan een bepaalde versie van de ontwikkelomgeving vast hangt.
 
@Jan,
Wel eens een verhaal gehoord van een database waar steeds weer een snelle SUN nodig was totdat het echt helemaal uit de klauwen liep.
Bleek dat de programeur een select * from table had gedaan en zelf maar eens op selectiekriterium ging filteren en bijhorende tabellen er vervolgens op de zelfde manier aan knoopte.
Als ik computers moest verkopen zou ik zo'n vent meteen inhuren.
De redactie vindt deze reactie: OKEwout Dekkinga, 22-12-2012 23:32
@Jan van Leeuwen
 
Helemaal met je eens maar er is ook een organisatorisch uitdaging want met gemaakte opdelingen in beheer blijft het eigenaarschap van problemen vaak diffuus. Dus worden deze niet altijd opgelost maar gewoon doorgeschoven naar het volgende loket, zoals met applicaties die soms met de beste wil niet te beheren zijn. En de eigenaar van die applicaties is toch nog vaak de business die conservatiever is dan de techniek hoewel daar soms ook een reden voor is door specifieke functionaliteiten.
 
Want betreffende het zicht op de keten weten we wel dat resources belast worden maar niet door wie (of waarom) waardoor misschien wel de bottleneck bekend is maar dus nog niet de dader, voorbeelden van Pascal en PaVaKe zijn daarin sprekend. En ik kan zelf ook nog wel een lijstje van dit soort voorbeelden toevoegen maar wil me in dit geval beperken tot de SBC omgevingen. De reden daarvoor is dat deze 'intelligentie' soms in applicaties is gebouwd om de intellectuele eigendom te beschermen, de specifieke functionaliteit die vaak voorkomt dat er een alternatief gekozen kan worden.
De redactie vindt deze reactie: OKWill Moonen, 23-12-2012 18:12
Kortom - alles draait om meten!
Want meten is weten en gissen is missen.
 
Dit soort ketenvraagstukken is vandaag de dag eenvoudig op te lossen.
Dan heb ik het over het applicatie-inzicht van een keten: wie gebruikt wat, wanneer en met welke prestaties.
 
Een praktisch voorbeeld - in de afgelopen week waren er per uur de volgende gemiddelden:
(1) 23 Exchange-gebruikers
(2) gelijktijdigheid van 5 gebruikers
(3) transactietijd van 3 seconden
(4) per transactie 3 MB aan netwerkverkeer
 
Gemiddelden alleen zijn natuurlijk niet voldoende. Daar horen percentielen bij om erachter te komen waar de uitschieters zitten - positief of negatief. En in welke mate die voorkomen.
 
Sommige van dit soort monitoringtools zijn ook in staat om dat te combineren met resourcebelasting (CPU, disk IO en wat dies meer zij). En dat zowel virtueel als fysiek (ESX of Hyper-V). Alhoewel ik mijn twijfels heb over het praktisch nut van resource monitoring binnen een virtuele server.
 
Nogmaals - er zijn vandaag de dag voldoende betaalbare instrumenten/tools beschikbaar. Het is daarbij wel zaak dat ook de 'consumenten' van die keteninformatie betrokken worden bij de selectie en invoering.
En niet alleen de technische mensen zoals netwerk en systeem beheerders. Want die worden gemeten op device beschikbaarheid ('bij mij is alles groen'). En niet op de bijdrage aan een (applicatie) keten - laat staan de gebruikersbeleving. Waarbij gebruikersbeleving gedefinieerd is als 'de wachttijd tussen een klik en het bijbehorende antwoord op het scherm'.
De redactie vindt deze reactie: OKEwout Dekkinga, 23-12-2012 23:51
@Will
 
Je hebt gelijk maar helaas ten dele want het meten is niet voor alle applicaties zo eenvoudig zoals de voorbeelden van PaVaKe en Pascal ook al duidelijk maken. Zoals de wachttijd tussen een klik en het antwoord welke dus niet alleen helemaal door de keten moet, die door alle stapelingen eerder een web is maar dus ook nog verwerkt moeten worden.
 
Want in een specifieke oplossing als SBC waar meerdere applicaties met verschillende karakteristieken op draaien worden hierdoor vertragingen nog weleens versterkt. En natuurlijk kunnen we aan de achterkant wel bepalen dat verzoeken snel beantwoord worden maar dat zegt nog niets over het eindresultaat. Tenslotte geef jezelf ook al aan dat als de dashboard lampjes die op groen staan, zoals een belasting aan de achterkant nog niet zoveel zegt over de prestatie aan de voorkant.
 
Deze is namelijk vooral afhankelijk van allerlei koppelingen waar nog weleens erfenissen in zitten uit het verleden, bijvoorbeeld met Domino of andere groupware om maar wat te noemen. Betreffende keuze van instrumenten is er ook niet altijd zoveel vrijheid omdat de business uiteindelijk de applicaties kiest welke IT dan weer mag integreren in de architectuur. En hier wordt niet altijd naar aspecten gekeken zoals onderhoudbaarheid waardoor er dus nogal wat puntoplossingen in het beheer van de platformen, middleware en databases zijn om maar wat te noemen.
 
Misschien dat je betoog over de eenvoud van ketenbeheer op gaat voor een architectuur welke gebouwd is op de oplossing van één leverancier maar ik ben bang dat praktijk weerbarstiger is. En hierdoor lijkt het ketenbeheer in SBC omgevingen soms net op het spelletje 'touwtje-trek' van de kermis waar je nooit weet wat er omhoog komt als je een wijziging aanbrengt.
De redactie vindt deze reactie: OKJan, 24-12-2012 9:57
Ooit eens aan een project gewerkt waarbij in de aanbesteding een forse boete clausule was opgenomen binnen hoeveel tijd de gebruiker een respons kreeg. Dit werd natuurlijk gecontroleerd met een stopwatch.
 
Maar dit valt natuurlijk allemaal onder technisch vakmanschap van de betrokkenen en de juiste aansturing en gebruik van dit vakmanschap. En aangezien de jongere generaties die helaas niet meer of te weinig tijdens hun opleiding meekrijgt zullen ze het dan maar van de oude rotten moeten leren. (Of zelf het wiel opnieuw moeten uitvinden.)
De redactie vindt deze reactie: OKWill Moonen, 24-12-2012 10:46
@Ewout:
De kritische noot kan ik me goed voorstellen. Toch meen ik te moeten concluderen dat je teveel gehinderd bent door ter zake doende kennis.
 
:-)
 
Even kijkend naar mijn eigen ervaring:
Ik heb in het verleden gewerkt aan het in kaart brengen en oplossen van problemen in applicatie ketens met (gebruikers)transacties die 8-11 servers raakten - afhankelijk van een lees of schrijf actie!
Daar zaten technieken in als web & Citrix voor de front-end, .Net (IIS) & Java (Tomcat) voor de business logic, Websphere als integratie laag, AIX/Oracle & mainframe/DB2 als database server.
De front-ends waren Windows systemen. En de integratielaag was gebaseerd op RedHat.
En dat alles ook nog eens in meerdere of mindere mate gevirtualiseerd.
 
In dergelijke situaties heb ik nooit meer dan 2 monitoring tools nodig gehad om te begrijpen hoe de keten in elkaar zit. En om me het inzicht te geven rondom het gebruik - wie gebruikt wat en wanneer.
 
Anders gezegd: laat me weten als je weer eens tegen zo een touwtje-trek situatie aanloopt! Het moet al raar lopen wil ik geen oplossing hebben.
De redactie vindt deze reactie: OKReza Sarshar, 24-12-2012 15:36
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.
De redactie vindt deze reactie: OKGerbrand van Dieijen, 24-12-2012 16:53
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.
De redactie vindt deze reactie: OKEwout Dekkinga, 24-12-2012 18:55
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.
De redactie vindt deze reactie: OKEwout Dekkinga, 24-12-2012 19:37
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.
De redactie vindt deze reactie: OKHenri Koppen, 25-12-2012 9:55
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.
De redactie vindt deze reactie: OKRuud Mulder, 25-12-2012 13:28
@ 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.
De redactie vindt deze reactie: OKEwout Dekkinga, 25-12-2012 16:42
@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.
 
De redactie vindt deze reactie: OKHenri Koppen, 25-12-2012 17:02
@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.
 
De redactie vindt deze reactie: OKEwout Dekkinga, 25-12-2012 19:42
@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.
De redactie vindt deze reactie: OKPaVaKe, 25-12-2012 21:35
@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.
De redactie vindt deze reactie: OKReza Sarshar, 26-12-2012 1:29
In een reis naar verre oosten kwam ik een keer een oude kruidendokter tegen. Hij beweerde dat zijn spul alle ziektes en kwalen kon genezen!
 
Hetzelfde verschijnsel doet zich op deze site voor! Heb je probleem met je applicaties, is de efficiëntie van je ict afdeling laag, heb je behoefte aan BYO of andere nieuwe technologieën, zijn de kosten van je ict te hoog, loopt je business achter op je concurrenten etc etc, daar hebben we een oplossing voor: “ CLOUD ”
De redactie vindt deze reactie: OKHenri Koppen, 26-12-2012 8:53
@Ewout: Vandaag wordt nog steeds de legacy van morgen gemaakt, legacy is een cyclus en elke applicatie heeft zijn "herfst". Virtualisatie is momenteel een belangrijke peiler van cloud computing en ik weet dat je veel kan en weet van virtualisatie en ook van cloud computing.
 
En je artikel is wel goed, maar door al die woordspelingen en dubbelzinnigheden maakt dat de leesbaarheid slechter.
 
Cloud computing is geen delivery model, saas, paas en iaas zijn delivery modellen.
 
Cloud computing is geen oplossing in zichzelf. Je kunt niet vragen; zullen we voor ERP pakket kiezen of voor cloud?
 
Uiteindelijk draait het om de applicaties en om data.
 
@PaVaKe: Software op specifieke apparaten vallen in mijn ogen buiten deze discussie. Een apparaat is een onderdeel in een ecosysteem en ontlenen hun waarde uit hun functie. Dat daar legacy op draait is logisch, net als dat de space shuttle zeer oude spullen gebruikte. Hier is cloud ook totaal niet relevant.
 
@Reza: Touché!
Al zal ieder zelf moeten besluiten wat goed voor hem/haar is.
De redactie vindt deze reactie: OKEwout Dekkinga, 27-12-2012 0:57
@Henri,
 
Stellen dat vandaag de legacy van morgen gemaakt wordt is inderdaad waar, nog een practice waar moeilijk mee te breken valt door commerciele belangen en erg weinig applicaties zijn dus OS agnostisch. Een euvel wat je trouwens ook ziet met Cloud Computing hoewel door webtechnologie de service zelf wel naar meerdere verschillende client devices gebracht kan worden, net als met applicatie streaming maar dat terzijde. En over de definitie van Cloud Computing kunnen we eindeloos discusseren maar vanuit mijn perspectief is het evengoed een delivery model, van computer resource in dit geval welke (vaak) gevirtualiseerd zijn.
 
Maar daar ging het artikel dan ook niet over, wel over applicaties die min of meer ongewijzigd van delivery model wijzigen en daarmee misschien een parallel hebben met cloud computing. Tenslotte wordt hier ook nog weleens alleen getest op functionaliteit waarbij er geen rekening gehouden wordt met de belasting van resources. En hier wordt ook nog weleens geprobeerd in de breedte te schalen om iets op te lossen wat er in de lengte soms niet in zit, zoals bijvoorbeeld netwerk bandbreedte of non-routable protocollen.
 
Want zoals jezelf aangeeft gaat het namelijk helemaal niet om systemen of applicaties omdat deze vervangbaar zijn en van eigenaarschap kunnen wisselen maar vooral om de data. En misschien dat ik de volgende keer eens een artikel moet schrijven over zowel het eigenaarschap hiervan als de lifecycle omdat hier de grootste legacy ligt. Zeg maar een deel 2 van: 'De winst van Cloud Computing' welke je wel goed leesbaar vond maar waar je het ook niet geheel mee eens was:-)
14 vacatures
Integratie Architect

NS , Utrecht

Sharepoint Architect

FastFlex , 's-Gravenhage

Junior Software Engineer ETL

Achmea , Tilburg

IOS/Android app developer

Technolution , Gouda

Technical Innovator

Ordina , Nieuwegein

Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1568 6.2
Klik voor meer info2 1305 6.0
Klik voor meer info3 1268 6.2
Klik voor meer info4 1070 6.2
Klik voor meer info5 979 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 524 6.1
Klik voor meer info9 405 6.2
Klik voor meer info10 398 6.0