MVC Workshop: Een controller ontwerpen

"Wie een MVC controller ontwerpt, begint door simpel te denken."
                                                                                                  — Sam Rain

Wie een software oplossing wilt ontwerpen, zal vaak de voorkeur hebben aan de MVC strategie: Model-View-Controller ontwerpen zijn populair omdat ze structuur geven aan een applicatie. De 'C' uit MVC staat voor controller — het deel van een oplossing dat verantwoordelijk is voor de communicatie en de verwerking van informatie van en naar de applicatie. In dit artikel leggen we de loep over het ontwerpen van een 'controller'.

Applicaties hebben meerdere models, views en dus ook controllers. Iedere 'feature' werkt op zijn eigen manier met de informatie want de distributie en verwerking van informatie is waar het immers om draait. Een controller zoals deze bedoeld is in MVC dient als de besturing van informatie, maar vooral om de 'routing' — wie heeft het nodig, wat is er nodig en hoe dient het te worden geleverd?

Een 'controller' is daarom eigenlijk het beste te omschrijven als een centrale punt - het is de 'interface' en werkt als een soort 'lijm' tussen de models en views; de controller werkt met de menselijke koppelingen (views) en de gegevensbronnen (models). Wie een controller ontwerpt zal dus moeten beginnen met een inventarisatie van de volgende punten:

• Voor welke informatie distributie dient de controller?
• Welke informatie zullen de views nodig hebben?
• Welke informatie is beschikbaar vanuit de modellen?
• Hoe dient de informatie te worden gecirculeerd?

Stel, we nemen een simpel ontwerp voor een controller die ontworpen moet worden voor het invoeren van artikelen. We noemen daarom dit ontwerp de 'Artikelen Controller'. De 'Artikelen Controller' moet artikelen kunnen opvragen, toevoegen, aanpassen, verwijderen. Omdat de Artikelen Controller werkt voor een website, is het handig om de artikelen in uniforme gegevens te verspreiden (zoals XML). We hebben eigenlijk de basis van het controllerontwerp nu al gelegd. Wanneer we de controller het verzoek doen voor een artikel ‘opvragen', dient de controller dit verzoek te honoreren door deze in XML formaat terug te geven. Wanneer we de controller vragen om het artikel te verwijderen, dan moet het artikel verwijderd worden waar deze ook opgeslagen zou mogen zijn.

Maar hoe weet een controller dan welk artikel verwijderd moet worden? Hier gaat het ontwerp vervolgens verder — wat is het ontwerp van een artikel? Heeft een artikel een eigen nummer? Heeft een artikel een unieke naam? Met parameters kunnen het ontwerp uitbreiden. Laten we op dit moment uitgaan dat ieder artikel een uniek nummer heeft. Dan wordt het ontwerp uitgebreid met de parameter 'id' (staat voor: identificatie). Er is geen limiet aan de hoeveelheid parameters die nodig zijn. Zo zal een zoekfunctie binnen een view artikelen willen opvragen op naam of inhoud.

Natuurlijk is dit verreweg een voorbeeld van dat gelijk staat binnen de industrie. Echter is het de bedoeling van een ontwerp dat het vooral duidelijk is wat er verwacht wordt van de handelingen die de controller moet uitvoeren.

©SamRain
Controller

MVC Workshop: Een model ontwerpen

"Wie een MVC model ontwerpt, denkt aan informatiestromen."
                                                                                      — Sam Rain

Wie een software oplossing wilt ontwerpen, zal vaak de voorkeur hebben aan de MVC strategie: Model-View-Controller ontwerpen zijn populair omdat ze structuur geven aan een applicatie. De 'M’ uit MVC staat voor model — het deel van een oplossing dat verantwoordelijk is als de abstracte laag tussen de databanken van informatie en de applicatie. In dit artikel leggen we de loep over het ontwerpen van een 'model'.

Applicaties hebben meerdere controllers, views en dus ook models. Informatie is losgekoppeld in industriële toepassingen — ze is beschikbaar via de 'database'. Echter is de ene database de andere niet en is databasespecialisme een expertise die zeer afhankelijk is van de omgeving waarin informatie wordt opgeslagen. Een model hoeft niet perse een reflectie te zijn van de tabellen in de database — ze wordt ontworpen voor de informatie die de applicatie nodig heeft.

Wanneer een controller het verzoek doet aan een model om een artikel op te vragen, voert het model de nodige werk uit dat speciaal gericht is aan de database. Daarom is een model ook een abstractie — het transformeert gegevens van en naar de database, zodat de controller niet hoeft te worden aangepast wanneer er 'onder de motorkap' veranderingen plaatsvinden in de database.

Een 'model' is daarom eigenlijk het beste te omschrijven als een mal — het is de 'gegevensstructuur' die werkt als een container voor controllers; een model werkt met de technische onderdelen van een applicatie. Wie een model ontwerpt zal dus moeten beginnen met een inventarisatie van de volgende punten:

• Welke informatie is aanwezig in de database?
• Welke informatie heeft de applicatie nodig?
• Zijn er speciale bewerkingen nodig voor de informatie gebruikt kan worden?
• Hoe dient de informatie te worden aangeleverd?

 Stel, we nemen een simpel ontwerp voor een model die ontworpen moet worden voor artikelen. We noemen daarom dit ontwerp het 'Artikel Model'. Het 'Artikel Model' moet artikelen kunnen opvragen, toevoegen, aanpassen, verwijderen. Omdat het Artikel Model werkt met een database, is het handig om te weten hoe de artikelen in de database worden opgeslagen. Databases werken met CRUD bewerkingen — dit zijn de Create, Read, Update en Delete opdrachten waarmee databases tabellen beheren. Echter zijn deze vanzelfsprekend voor modellen. In het ontwerp is het belangrijk om een duidelijk onderscheid te maken van de types informatie. Een model ontwerpen in de diepte vereist dus de nodige ervaring met databases en datatypes.

Natuurlijk is dit een voorbeeld wat niet gelijk staat aan de industrie. Echter is het de bedoeling van een ontwerp dat het vooral duidelijk is wat er qua informatie beschikbaar is dat een model moet 'aanleveren'.

©SamRain
Model Ontwerpen

Ontwerpen als vaardigheid: Van hobbyist naar professional 1

"Ontwerp als een architect die het huis van de toekomst maakt, zonder te dromen."       
                                                                                                                          - Sam Rain

Wie van zijn of haar hobby een baan wilt maken, heeft ervaring nodig. Het is vaak een lange lijdensweg welke gepaard gaat met vooral vallen en opstaan. Ook in de informatie technologie sector gaat dit op — een thuisnetwerkje beheren maakt nog geen beheerder en een programmaatje in elkaar flansen maakt zeker geen software architect in de wereld van industrie. Tegenwoordig is het hebben van meerdere disciplines binnen een vakgebied meer de regel dan de norm. Toch is een specialisme het talent onder de professionals — het onderscheid maakt dat men kan concurreren met andere gegadigden binnen een project.

In de industriële toepassingen is de simpliciteit ver te zoeken — er komt naast creativiteit ook nog eens de nodige verantwoordelijkheid bij kijken. Veiligheid, robuustheid, schaalbaarheid, flexibiliteit, beheren en inzicht zijn maar enkele aspecten die ieder project met zich meebrengen. Vergissen is menselijk, maar in de industrie een kostbare blunder — hoewel software vaak gepresenteerd wordt als het populair kinderspeelgoed van Deense origine, is het eerder te vergelijken als metselwerk met specie. Eenmaal uitgehard, wordt het bikken en vaak hardhandig vervangen door andere bakstenen.

Het proces vóór de tekentafel wordt vaak niet gezien door de beginnende professional. Denkwerk, kennis en de nodige methodologie lijken vaak ideaal totdat men een frontale botsing maakt tien processen verder op — die soms ook nog eens pas opgemerkt worden op een paar weken voor de 'deadline'. Het ontwerp lijkt als een kaartenhuis in elkaar te zakken en de paniek springt erin. Wie oplossingen ontwerpt zal de processen moeten begrijpen, de industrie van toepassing moeten begrijpen en het inzicht hebben dat 'business logic', ondanks de modulaire opbouw, zo flexibel is als een loden kubieke meter.

Veiligheid is een onderschatting van vele ontwerpers — dat is voor de 'beheerder' en het onderliggend systeem. Inderdaad zijn deze de eerste linie, maar het is de toepassing waarin de vele gaten ontdekt worden en voor een risico zorgen. Authenticiteit van gebruikers, maar ook van het systeem zelf, dienen in het ontwerp te worden opgenomen. De toegangspunten tot het systeem moeten voor de ontwerper duidelijk zijn, evenals de cruciale koppelingen naar externe gegevensbronnen.

Robuustheid in de industriële software gaat verreweg om hoe de oplossing 'omgaat' met fouten en problemen. Robuuste oplossingen moeten dus tegen een stootje kunnen — het zijn vaak ontwerpers die weinig ervaring hebben met de 'knulligheid' van de menselijke gebruikers waardoor de verwachtingen bij de levering ernstig tegenvallen. Het 'testen' gaat daarom vaak in de vorm van 'happy paths', welke de meest ideale manieren van gebruik binnen de oplossing zijn. Zonder een aantal doemscenario's, worden fouten vaak te laat ontdekt - en nog vaker in situaties waar dan geen reddingsplan aanwezig is.

Schaalbaarheid wordt vaak verward met een modulaire strategie. Schalen betekent dat men zowel kan uitbreiden als inperken. Een ontwerp dat niet kan schalen limiteert zichzelf op de bekende 'levenscyclus' van de oplossing. Schaalbare ontwerpen zijn niet moeilijk — het is een kwestie van gebruikers te anonimiseren en onder te verdelen in rollen. Daarnaast bestaat 'data' enkel in persistente vorm binnen een gegevensbron en zijn toegangspunten en externe koppelingen configureerbaar — zodat er meerdere oplossingen co-existent ingezet kunnen worden.

Beheren van de oplossing is anders dan het 'onderhouden' ervan. Ten alle tijde moet een industriële toepassing toegang verlenen aan één of meer beheerders, zodat er handelingen verricht kunnen worden zoals het tijdelijk stoppen of terugdraaien van lopende processen. Omdat de industrie in grote hoeveelheid cruciale gegevens transporteert, kan een enkele fout grote impact hebben op de resultaten van zelfs meerdere processen. Een ontwerp dat geen rekening houdt met beheer van de oplossing is een onpraktisch ontwerp — immers heeft ook een auto een stuur, een gaspedaal en een rem nodig.

Inzicht creëren is vaak een onderschatting — waar beheerders voldoende hebben aan overzicht, zijn rapportages een "must-have" in industriële oplossingen. Uiteindelijk gaat het om resultaten en deze cruciale informatie dient terug te halen zijn, zonder dat daar een trukendoos voor opengemaakt hoeft te worden. Een ontwerper die niet beseft wat managers willen weten, kan ook geen degelijke oplossing ontwerpen met mogelijkheden tot inzicht. Rapportages moeten dus altijd opgevraagd kunnen worden en 'vanzelf gegeneerd kunnen.

Industriële toepassingen ontwerpen vraagt meer dan een probleemstelling op te lossen — het is een oplossing ontwerpen, rekeninghoudend met risico's en uitbreidingsplannen rondom het meest onvoorstelbare eisenpakket.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave van alle artikelen!

©SamRain
Ontwerpen

Praktische informatica: De basisvaardigheden voor database ontwerpers - deel 4

“Koppelen betekent aansluiten als één geheel.”
                                                            - Sam Rain

Queries en tabellen zijn natuurlijk prachtig, maar wat nu als je een paar tabellen hebt voor een boel formulieren of de behoefte hebt aan een enkel rapport? De oplossing is het leggen van een relatie tussen de tabellen, waardoor je met een query een super informatiebalk kunt genereren.

Relaties zijn hèèl simpel, er zijn 2 gangbare relaties:

-       de 1-op-1 relatie

-       de 1-op-veel relatie.

De 1-op-1 relatie vertelt dat een rij tot maar één andere rij mag toebehoren. De 1-op-veel relatie vertelt dat een rij kan behoren tot meerdere andere rijen. Echt waar, dat is het!

De relaties zijn mogelijk door de ‘id’ kolom (zie deel 2); omdat alle rijen (records) een uniek nummer hebben zijn ze rekenkundig gemakkelijk te koppelen door een rij te ontwerpen met een ‘relatie kolom’. Dit klinkt moeilijker dan het is.

Stel, we nemen de tabel Tijgers (zie deel 2) en maken een extra tabel ‘Verzorgers’:

Id (reeks) – naam (tekst) – aanwezig (ja/nee)

Iedere tijger heeft 1 verzorger, dus koppelen we de tabel Tijgers aan Verzorgers door een kolom ‘verzorger_id’ toe te voegen aan het ontwerp van ‘Tijgers’:

Id (reeks) – naam (tekst) – leeftijd (datum) – gewicht (numeriek) – agressiviteit (numeriek) – verzorger_id (numeriek).

Als we 10 verzorgers zouden toevoegen, hadden we zonder relaties de Tabel Tijgers moeten uitbreiden en voor iedere tijger de verzorger handmatig moeten invullen. Met tabellen zoals puma’s, leeuwen en panters zou het een ramp worden en bij een geval van ziekte of ontslag zouden de dieren verhongeren, omdat de verzorgers de database moeten aanpassen. In plaats daarvan kan met de ‘id’ van de verzorger meteen alle informatie van de verzorger worden opgehaald aan de hand van de tijger! Ook kan dezelfde truuk gebruikt worden voor de andere dieren – en weet je hoeveel verzorgers er vandaag werken!

Relaties teken je als ontwerper in diagrammen:

Verzorgers

Id naam aanwezig

Tijgers

Id naam leeftijd gewicht agressiviteit verzorger_id

Leeuwen

Id naam leeftijd gewicht agressiviteit verzorger_id

                                   

Koppelen heet een ‘join’ in queries; het combineert een rij met een andere rij; wat ook kan is de simpele ‘waar’ (where):

Selecteer Tijgers.naam, Verzorgers.naam
waar Tijgers.Verzorger_id gelijk is aan Verzorgers.id
sorteer aflopend
uit Tabel Tijgers, Verzorgers.

Ook kun je als ontwerper de relatie definiëren voor de ontwikkelaar als volgt:

·      Tijgers hebben 1 verzorger

·      Verzorgers hebben meerdere tijgers.

Als ontwerper is het belangrijk om duidelijk te zijn over wat je wilt bereiken!

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave van alle artikelen!

©SamRain

Database ontwerpen

Praktische informatica: De basisvaardigheden voor database ontwerpers - Deel 3

“De kunst van zoeken is weten wat je wilt vinden.”
                                                                        - Sam Rain

In deel 1 besprak ik de vier zuilen van een database vluchtig; in dit deel ga ik dieper in op de Queries die de tabellen praktisch maken.

Zoeken in tabellen is veel gemakkelijker dan men doet voorkomen. Feitelijk is de zoekopdracht een selectie van rijen, waarbij de criteria bepaalt hoeveel rijen er geselecteerd worden om door een filter te gaan die kolommen teruggeven. Ontwerpers zullen minder vaak zich bezig houden met supercomplexe instructies en meer met de praktische kant.

Een zoekopdracht is eigenlijk een samengestelde formule, die losgelaten wordt op de tabellen in de database om een collectie van gegevens ‘terug te geven’. Een query bedenken is makkelijk; met het volgende stappenplan:

1)    Welke informatie heb ik nodig?

2)    In welke tabel(len) staat deze informatie?

3)    Met welke criteria wil ik de informatie selecteren?

4)    Welke informatie wil ik laten zien?

Alleen stap 3 is ‘wennen’ voor non-techneuten; toch blijft het een kwestie van kijken en vergelijken. Bijna alle database applicaties hebben een methode om queries te ontwerpen – sommigen zelfs een simpele interface met knopjes waardoor je queries in seconden maakt. De meesten ondersteunen ook SQL, een programmeertaal speciaal voor databases. Als ontwerper is belangrijker om vast te leggen wat de query zou moeten doen dan het typografisch vast te leggen in een technische taal – dit eerste is helemaal geen moeilijk karwei!

Criteria in een query zijn niets meer dan vergelijkingen, die door sleutelwoorden worden aangegeven:

Waar (where)            :   vergelijk de ‘waarde’ van een veld met een andere veld of een
                                      opgegeven ‘waarde’;
Of (or)                       :  vergelijk twee ‘waarden’ óf kies een andere vergelijking met
                                       twee ‘waarden’;
En (and)                   :    vergelijk twee vergelijkingen;

Dit zijn de ‘logische’ operatoren; andere operatoren vergelijken de rekenkundige gelijkwaardigheid, terwijl de logische operatoren de ‘Boolean’ gebruiken (waar/onwaar, ja/nee, true/false).

=                        :            Gelijk aan de waarde aan de linkerzijde
>,<                     :            Groter of kleiner dan de waarde aan de linkerzijde.

Als we de ‘Tijgers’ tabel nemen uit deel 2, en we willen een query ontwerpen voor ons nieuwe rapport genaamd ‘Agressieve Tijgers’ dan weten we dat we top-10 tijgers gaan selecteren, met de criteria dat we sorteren op de kolom ‘agressiviteit’ en dat we alleen de waarde van 4 of hoger zien als agressief. We gaan de query dan zo ‘ontwerpen’ en geven het de naam TopTienAgressieveTijgers.

Selecteer 10 rijen            -> Selecteer / bepaal hoeveelheid rijen
waar agressiviteit > 4      -> bepaal criteria
sorteer aflopend              -> bepaal ordening
uit tabel Tijgers               -> definieer tabel

Met queries kun je ook invoergegevens, hele gedetailleerde zoekopdrachten en zelfs beheerfuncties knutselen – uiteindelijk komt het neer op selecteren, aanpassen, verwijderen en aanmaken van rijen. Hoe vaker je een oplossing bedenkt, hoe meer je wilt gaan leren over queries in de diepte; laat voor serieuze toepassingen een techneut met je meedenken!

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave van alle artikelen!

©SamRain
Database Ontwerpen

Praktische informatica: De basisvaardigheden voor database ontwerpers - Deel 2

“Zoek naar niets, vind ook niets – letterlijk.”
                                                            - Sam Rain

In deel 1 besprak ik de vier zuilen van een database vluchtig; in dit deel ga ik dieper in op de tabellen.

Een tabel, in het geval van een database, dient als functie door een grote collectie van individuele informatiegroepen te beheren. Een ‘informatiegroep’ bepaal je door de typische eigenschappen te identificeren naar het ‘soort’ eigenschap. De ‘informatiegroep’ is een ‘rij’ (row) en het ‘soort’ eigenschap een kolom (column).

Stel we willen ‘tijgers’ beheren (nou ja – de informatie over tijgers). Iedere afzonderlijke tijger hoort thuis in een ‘rij’ en we kunnen de specifieke informatie ontwerpen in de kolommen. Sam’s Zoo heeft 100 tijgers, waarvan elk een eigen naam, een leeftijd, een gewicht en een ‘gedragscijfer’ (hoe hoger hoe agressiever). De eigenschappen worden ieder een kolom in de tabel ‘Tijgers’ (het meervoud van de rij dat het object weergeeft – een tijger). Omdat tabellen gebruikt worden om te zoeken (en zoals later duidelijk wordt voor andere handige truukjes) kun je iedere rij voorzien van een ‘speciale’ kolom, genaamd ‘id’. Dit staat ook voor identificatie, zodat iedere tijger óók gezocht kan worden op ‘nummer’. Het ontwerp van de rij bestaat dan uit 5 kolommen:

Id – naam – leeftijd – gewicht – agressiviteit

We zouden aan de hand van deze groep informatie o.a. het volgende kunnen vinden: a) alle tijgers tussen een bepaalde leeftijd, b) tijgers die zeer agressief zijn, c) een alfabetische volgorde van alle namen, d) het gemiddeld gewicht en e) het totaal aan tijgers. Juist voor de berekeningen zal iedere kolom specifiek ontworpen moeten worden naar een ‘datatype’ – informatie waardoor een computer begrijpt waar de informatie voor bedoeld is. Zonder al te moeilijk te gaan doen, zijn dit de algemene types in de databases.

·      numeriek (cijfers en getallen)

·      tekst (letters en woorden)

·      datum (tijdsnotering)

·      ja/nee (de Boolean)

·      reeks (de automatische nummering)

Als we deze toepassen op ons ontwerp:

Id (reeks) – naam (tekst) – leeftijd (datum) – gewicht (numeriek) – agressiviteit (numeriek)

Hebben we een functioneel tabel ontwerpen, waarop we naar hartenlust queries (zoekopdrachten) op los kunnen laten. We kunnen zoveel kolommen (eigenschappen) toevoegen als we willen; echter wil je geen ‘onnodige’ informatie toevoegen dan noodzakelijk. Een ‘rij’ toevoegen kost schijfruimte en over een bepaalde tijd zal de collectie dus groeien.

Na een tijdje belt de verzorger van Sam’s Zoo; alle tijgers zijn wel opgeslagen, maar ze overlijden ook zo nu en dan. Dòh! Weer wat geleerd, want door de rij te voorzien van een kolom ‘levend’ van het datatype ‘Boolean’ kunnen de levende tijgers snel gevonden worden en het aantal doden ook. Of was het slimmer om een geboortedatum en sterftedatum te gebruiken? En dat zijn dus de dilemma’s voor ontwerpers – alle tijgers moeten gecontroleerd worden en de nieuwe informatie worden toegevoegd. Oefening baart kunst!

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave van alle artikelen!

©SamRain
Database ontwerpers

Private Cloud Computing

“Oude wijn in nieuwe zakken verkocht als Champagne.”
                                                                                    - Sam Rain

Cloud Computing is wel een beetje volwassen geworden in de Nederlandse industrie – men praat dan ook graag over schalen en de voordelen. Zoals alle goede IT-ontwikkelingen, zijn er ook vele varianten die een nieuwe ‘hype’ gebruiken om hun oude foldertjes even te verversen om innovatief te lijken. Eén daarvan is private cloud computing.

Laat ik eerst de ware innovatie blootleggen: de “Cloud”. Feitelijk is de technologie om netwerkapplicaties te verdelen over meerdere machines maar deze te beheren alsof ze één grote computer zijn, én het gemak om nieuwe machines aan te koppelen zonder dat de boel ‘plat’ gaat. De voordelen zijn vooral in hele kleine ondernemingen of hele grote bedrijven; de kleine hoeven niet meteen tonnen aan apparatuur en bijbehorende vakmensen te betalen om puur de boel draaiende te houden en de grote jongens hoeven geen tonnen vooruit te investeren voor de toenemende informatieopslag. Voor de IT-ers betekent het verdere specialisatie; Cloud-techneuten zijn het grondpersoneel en er komen naast de piloten ook stewards bij (in de vorm van een applicatiebeheerder). Cloud Computing betekent voor ondernemers dan ook ‘uitbesteden’; in plaats van experts huur je de grote machines – een lease plan dus.

Private Cloud Computing is het beste te vertalen als ‘zelf’ doen. Ondernemers zijn van nature wantrouwig en ware ‘control-freaks’; je database bij zo’n gezichtsloze firma plaatsen is voor de medior ondernemer een durfal taak. Want Private Cloud Computing heette anno 2000 gewoon simpelweg ‘Centralisatie’; alleen kreeg je dan een extra boek vol techie-termen kado zodat je wist waar die miljoenen investering ook al weer voor was. Cloud-baptisten en vooral de fanatieke ‘open source’ sekten zullen allerlei tegens opwerpen. Echter verkoopt zelden de techneut iets aan de Directie.

De kracht van Cloud Computing zit in efficiëntie; hoe groter een cloud, hoe efficiënter – hoe raar dat ook klinkt. Een grote Cloud bestaat namelijk uit meerdere componenten en is dus relatief veel complexer. Een complexe cloud kan niet zonder vakmensen werken; Google, Apple en Microsoft zijn niet voor niets permanent bezig met het werven van ‘the best and brightest’. Iedere redelijke techneut kan een Cloud gemakkelijk opzetten; niet iedere techneut heeft dé kennis, dé ervaring én een team van mensen én de middelen om bij een probleem te reageren – hackers, hardware, performance en ga zo maar door. De klant merkt er niets van – die wilt gewoon aan de slag.

Een private cloud is dan een speciaal opgezette omgeving dat functioneert als een cloud, maar het qua ‘community’ cloud aan expertise moeten gaan inleveren; koop dan nog liever een kleine cloud leverancier op in zijn geheel – dan heb je nog iets van de expertise ‘inhouse’.

Bij een top 5 tour operator begon het goed; de visie op een cloud en alles erop overzetten – maar als ‘tijdelijke’ infrastructuur. Vooral IT-managers zijn gedreven op zo’n controle en dat is iets wat heel logisch is. Want ergens zijn deze dienstverleners bang dat ze van ‘hardcore IT’ naar klik-en-sleep niveau moeten overstappen óf dat ze geen beheersing hebben over onverwachte calamiteiten.

Centralisatie is helemaal niets mee; sterker nog, bepaalde industrieën zoals het bankwezen vereisen nu eenmaal een hogere standaard dan de huis-tuin-en-keuken ondernemer. Deze komen dan ook met hun zeer uitgebreide afdelingen met hun eigen vakmensen van zo’n grootte dat deze met recht een ‘private cloud’ genoemd mag worden. Echter wordt de private cloud nu gepresenteerd als de thuisbioscoop voor hen die de IMAX-ervaring willen hebben – misleidend dus.

Meer lezen hierover? Klik dan hier voor de inhoudsopgave van alle artikelen!

©SamRain
Private Cloud Computing