Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

De wederopstanding van de Fat Client

 

Channelweb Expert

Mark Slooff
Regional Sales Director, OutSystems voor Agile Webapplications. Expert van Channelweb voor de topics Business Analytics, Cloud Computing en Infrastructuur.

De jaren tachtig staan bekend om onrust in het Midden Oosten, ongelooflijk slechte kapsels en vreselijke muziek. Maar natuurlijk vooral om het client/server-model voor applicaties. Zoals alles in de cultuur komt al het oude vroeg of laat weer terug in het straatbeeld. Met het stempel ‘retro’ erop zijn de muziek, de mode en de kapsels uit de jaren tachtig ineens weer in de mode. Hetzelfde geldt voor mobiele applicaties en het client/server-model.

De mobiele applicaties van vandaag binden de strijd aan met de uitdagingen die client server computing in de jaren tachtig om zeep hebben geholpen. Het complexe distributiemodel om client-software bij te werken, de gedistribueerde architectuur en de noodzaak om voor verschillende platformen te ontwikkelen door gebrek aan overdraagbaarheid, zorgen voor extra kosten en vertraging. De vraag is of mobiele applicaties kunnen winnen van de jarenoude plaag die client/server tergt, nu er een sterk verbeterde architectuur beschikbaar is en er betere distributiemodellen zijn. Of zullen enterprise mobile apps net zo eindigen als de thin clients?

Ik ben vast niet de enige die weet dat er soms veranderingen niet werden doorgevoerd, puur omdat het te moeilijk was en teveel kostte. Met de opkomst van app stores is dit probleem aanzienlijk verminderd. Maar een nieuwe uitdaging dient zich aan: bij de meeste applicaties controleert de eindgebruiker de updates. Dit is vergelijkbaar met de situatie waarin het IT-team er geen controle over had welk werkstation werd in- of uitgeschakeld en zo het risico liep dat gebruikers de nachtelijke update misliepen. In de mobiele wereld zijn ontwikkelaars ervan afhankelijk of gebruikers de update daadwerkelijk uitvoeren. Hoewel dit beter is dan de werkwijze in de jaren tachtig is het nog steeds een potentieel probleem, vooral als er kritieke updates moeten worden uitgevoerd. Vergeet niet dat ontwikkelaars nog steeds alle oude api’s moeten handhaven tot alle gebruikers hun (fat) clients hebben geüpdate. Problemen met de api’s zijn echte maintenance uitdagingen en dat leidt tot het tweede probleem, de complexiteit van gedistribueerde architecturen.

Je kunt je afvragen of een gedistribueerde architectuur echt een probleem is. Iedere architectuur heeft uiteraard zowel voor- als nadelen. Ik doel vooral op de cyclus van verandering. Complexiteit is zonder twijfel de Magere Hein van applicaties. Mijn ervaring is dat een gedistribueerde architectuur, zoals je die ziet in de huidige golf van mobiele applicaties, complex wordt door twee drie vragen. Waar moet de functionaliteit geplaatst worden? Hierbij is het vinden, debuggen en uiteindelijke oplossen van het probleem het meest complex. En wat gebeurt er als er geen 3G-netwerkverbinding is? Hoe gaan we om met security issues van een mobiele applicatie? Normaal gesproken zou het een oplossing zijn om ervoor te zorgen dat mensen op afstand kunnen werken, maar dit vraagt uiteraard meer van de applicatie. Niet alleen moet er worden geïnvesteerd in lokale dataopslag voor ieder apparaat, maar het zorgt ook voor een complex geheel van dataconnectiviteit en synchronisatiekwesties. Los van het feit dat niet iedere applicatie zijn minimale dataset lokaal op een device kan plaatsen, simpelweg omdat de dataset te groot is voor het device.

In de mobiele wereld blijven deze complexiteitsfactoren ontwikkelaars achtervolgen, terwijl de toenemende vraag naar functionaliteit en beschikbaarheid een angstaanjagend tempo vereist. Dit is een nieuw paradigma. Omdat toestellen en applicaties vervangbaar zijn, is het cruciaal om de vraag te kunnen bijbenen. Wie daar niet in slaagt, moet met lede ogen toezien dat er simpelweg voor een andere applicatie wordt gekozen.

Tot slot de uitdaging van het gebrek aan draagbaarheid, die bij velen herinneringen zal oproepen aan de oude OS/2- en Windows-compatibiliteitsoorlogen. Vandaag de dag moeten applicaties kunnen draaien op alle mogelijke soorten hardware en software zoals verschillende edities van Windows, Mac OS en Android. Bedenk eens hoeveel verschillende mobiele apparaten je de afgelopen zeven jaar gebruikt hebt en reken daarbij de levensduur van de gemiddelde zakelijke applicatie mee. Eng toch? Het snelle tempo van veranderingen in relatie tot mobiele apparaten onderstrepen dit probleem voor alle ontwikkelaars van mobiele applicaties die werken binnen het client-server paradigma. Bijblijven kost veel geld en tijd en dat leidt in de mobiele wereld vrijwel altijd tot een afgeschreven applicatie.

Met de komst van HTLM5 en 4G netwerken denk ik dat de geschiedenis zich zal herhalen. Het huidige mobiele computing-paradigma zal snel worden vervangen door thin client applicaties, net als client-server met de ondersteuning van HTML en RIA. Deze toepassingen krijgen misschien een bepaald omhulsel om beter te integreren met een specifiek apparaat, maar zijn in de kern gewoon browsers die toegang hebben tot webapplicaties. En gezien het tempo van de mobiele wereld denk ik dat deze verschuiving veel sneller plaatsvindt dan in de client-server. Samenvattend: 'Thin is in, vooral voor enterprise mobile toepassingen.'

Belangrijke voetnoot bij deze ontwikkeling is dat het, net als bij andere keuzes in relatie tot de business en haar processen, er niet altijd een zwart-wit antwoord uit komt. Er zijn veel aspecten die van invloed zijn op het afwegingsproces voor een native client-applicatie versus een webgebaseerde app. De keuze voor laatstgenoemde biedt aantoonbare voordelen als het gaat om bedrijfsmatige applicaties. Soms kun je echter in specifieke situaties toch beter rekenen op native applicaties. Wanneer je bijvoorbeeld als vertegenwoordiger een catalogus-/pricing-applicatie gebruikt op locatie, wil je niet afhankelijk zijn van de 3G-verbinding. Die vormt, zeker binnen een modern pand, een behoorlijk operationeel risico. Zo zijn er nog meerdere voorbeelden te bedenken waarom ‘fat clients’ voorlopig nog relevant blijven. Het is hoe dan ook belangrijk om als bedrijf stil te staan bij de benodigde functionaliteit en toegankelijkheid bij het bepalen van de mobiele strategie en de juiste keuzes te maken met betrekking tot beheersbaarheid, functionaliteit en beschikbaarheid van applicaties.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4409093). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

IP heeft alles afstandsonafhankelijk gemaakt, het WAN is een groot LAN geworden
ICT is megaschaalbaar geworden, en vrijwel hw/sw onafhankelijk
er is meer dan 3 G, mobiel, Wi-Fi: semimobiel, maar high speed
uiteindelijk is het de wedstrijd tussen:
* infrastructuur versus randapparatuur, of
* cloud versus zelf doen, of
* diensten aanbieder of eigen beheer, of
* exploitatie model versus investeringsmodel

inderdaad, wel eens met de strekking: eerst denken dan doen.....


Mark,

Leuk artikel maar om te beginnen bij de voetnoot is het niet dat we direct onze oude schoenen weggooien voordat de nieuwe lekker ingelopen zijn. In de jaren 80 was client/server hip door opkomst PC, in de jaren 90 de web enabled applicaties door populariteit Internet en nu de mobiele applicaties door succes van tablets en smartphones. Omdat er telkens geen sprake is van complete vervanging wordt de schoenenkast niet alleen maar voller maar worden soms ook oude schoenen van nieuwe zolen voorzien. Zoals we eerder al de (iPaq) pocketpc en netbooks hadden welke ook niet de desktop vervingen maar waren vooral aanvullend gebruikt werden. Fat clients zullen dus nog wel even de lekker zittende pantoffels blijven.

Als bij de opkomst van het nieuwe de nadelen ervan duidelijker worden, wordt de heimwee naar de voordelen van het oude aangewakkerd. Niks mis mee, omdat de gecombineerde plus een verbeterde versie zal opleveren. Vroeger zeiden we de de PC wel wat handzamer mocht. Dat het beeldscherm wat scherper kon en in kleur. En dat het handig zou zijn om makkelijk bestanden te delen en informatie uit te wisselen en nog veel meer. Hebben we allemaal gekregen. En nu zien we dat al die mogelijkheden ook nadelen hebben die je vroeger dus niet had toen het allemaal niet kon. Dus is er voor elk wat wils: eigen PC, eigen Tablet, eigen smart Phone, eigen netbook, notebook of laptop, eigen pen en papier… want op dit soort sentimenten kun je ook inspelen zodat iedereen het op zijn eigen manier kan doen en oude diensten worden verkocht als nieuwe services. Girootje schrijven? Geen probleem! Internetbankieren? Geen probl… ehh.

Beste Mark,

Een goede analyse van de huidige uitdagingen. Gelijktijdig zien we ook nog de behoefte om de server en losse bestanden zoals excelsheets naar de cloud te verplaatsen. Zodra we de cloud voor de server gebruiken zijn we weer afhankelijk van verbindingen. De betriuwbaarheid en beschikbaarheid van de verbinding kan onze nieuwe Magere Hein worden.

De toekomst zal het leren.

In de jaren 80 had ik juist voornamelijk te maken met coax-gekoppelde 5250 schermen. Niets mis mee, later kwamen de PCs met terminal applicaties... niets mis mee. Het probleem begon toen de terminal erg grafisch ging worden, veel gegevens die door de server moesten worden samengesteld en vertaald naar een grafisch plaatje, voor elke gekoppelde client. Dus schakelde men over naar het patroon waarbij de server alleen de gegevens leverde en de client ging het grafisch maken en de fat client was geboren. Ook niets mis mee.

Waar het om draait is dat er elke keer een afweging moet worden gemaakt van de behoeften (requirements), en dat voor zowel de server kant als de client kant. Alles heeft z'n voordelen en z'n nadelen en de kunst is juist om een optimum te vinden. Dat is nu de taak van de enterprise, solution en application architect.

Je ziet vaak een op en neer beweging tussen centraal en de-centraal. Toch geloof ik dat centraal de toekomst heeft. Dit gezegd hebbende worden mobiele devices steeds krachtiger. Hoe kun je dan nog spreken van een thin client? Mijn iPhone is in feite net zo krachtig als een fat client van vijf jaar geleden.

Wat een belangrijk aspect is (voor bedrijven) zijn de IT kosten. De hardware is maar een klein aspect van de totale IT gerelateerde kosten. De enige manier, ik herhaal, de enige manier om dit op te lossen is met verregaande automatisering en dat betekent: centraal geregeld.

Je device mag best een fat processorkracht bevatten, zolang hij zijn input maar krijgt vanuit de centrale plek (of gedistribueerde centrale plekken).

Servers handmatig inrichten = fail
Computers niet centraal beheren = fail

Dus afhankelijk hoe je een fat client ziet, denk ik dat de fat client geschiedenis is.

Heren,

Hartelijk dank voor de feedback op mijn artikel. Ben het geheel eens met de voor- en nadelen van elke setup en inderdaad vandaar dat een Enterprise Architect daarin een belangrijke rol heeft.

Toch zie ik veel bedrijven nog weinig innoveren en teveel projecten mislukken. Als je kijkt naar nieuwe technologieen is er tegenwoordig zoveel meer mogelijk met gemiddeld gezien veel betere resultaten. Neem bijvoorbeeld de native app. Stel je wilt een webapplicatie ontwikkelen en deze zowel op de pc als smarthone ontsluiten, zul je deze applicatie met de native strategie vier tot vijf keer moeten bouwen omdat je immers te maken hebt met verschillende platformen voor iOS / Android / Win7 en Blackberry. Allemaal verschillende uitdagingen, wijzigingen 5x doorvoeren tijdens het onderhoud en daarna via alle kanalen laten updaten. Terwijl dat niet meer hoeft. Met de huidige ontwikkelingen zijn er ontwikkelplatformen waarmee je 1 applicatie ontwikkeld en deze op drie verschillende manieren kunt ontsluiten pc / tablet en smartphone. Kijk eens wat dat doet voor je wendbaarheid en TCO!

Nogmaals, daarmee zeg ik niet dat Native geen functie heeft.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×