Cloud is goedkoop, vervang de ict-afdeling door de cloud! Dit horen en lezen we vaak in de media. De folderprijzen zijn zeer interessant, de opties en mogelijkheden zijn ook best aantrekkelijk. Maar hoe ga je de transformatie van je huidige ict-organisatie en diensten naar deze nieuwe vorm realiseren?
Verschillende redenen worden benoemd waarom je naar de cloud zou moeten gaan, zoals financiële voordelen, meer effectiviteit, veel flexibiliteit en hoge betrouwbaarheid. De realisatie van deze voordelen is afhankelijk van zaken die misschien niet direct bij het vermarkten van cloud computing worden benoemd.
Wanneer je je business op strategisch niveau herijkt, dan zie je dat het digitaliseren van je bedrijfsvoering vereist is om in je bedrijfstak met je concurrenten te kunnen concurreren. De stap naar digitalisering is een groot verandertraject waarin je cloud computing als middel kan inzetten. Onbekend zijn met een aantal zaken in dit traject kan desastreus zijn voor je organisatie.
IaaS
Cloud computing kent verschillende modellen: losse applicatiemodellen (SaaS) en complete platformmodellen (IaaS/PaaS) Om misverstanden te voorkomen richt ik me in dit artikel op infrastructure as a service (IaaS).
Geschikt of ongeschikt?
De eerste stap in deze verandering is het extraheren van je vertrekpunt. Wanneer je cloud-strategie verder is ontwikkeld en uitgewerkt, dan kun je het effect hiervan op je vertrekpunt toetsen om de geschiktheid te beoordelen voor de ict-organisatie, de totale organisatie en de huidige inrichting van ict.
Binnen de ict-organisatie krijgt de ict-afdeling een andere rol. In dit geval ga je eerst conceptioneel het eindplaatje van de nieuwe inrichting creëren. Hierna kijk je welke effecten deze verandering op het ict-personeel heeft, hoe de afdeling moet worden ingericht, welke nieuwe functies ontstaan zijn en welke functies overbodig gaan worden. Gebaseerd hierop stel je samen met je personeel een ontwikkelplan op om de transformatie van hun huidige functies naar de nieuwe indeling te realiseren. Let wel dat de overgang naar cloud een geleidelijk proces is! Afhankelijk van je keuzes wordt dit een traject met een aantal stappen en fases waar je voldoende tijd voor vrij moet maken. Stel het ontwikkelplan voor de start op zodat het personeel tijdig opgeleid is om de transformatie efficiënt en effectief mee te maken.
Het effect van cloud beperkt zich niet tot alleen de ict-afdeling, het raakt de totale organisatie. Je werkprocessen en de huidige ict-inrichting (applicaties, koppelingen, afhankelijkheden, et cetera) zijn op elkaar afgestemd. Afhankelijk van de keuzes die je maakt en de uiteindelijke inrichting zul je zien dat voor het benutten van de nieuwe mogelijkheden, het herinrichten van bepaalde processen en ook afdelingen noodzakelijk is. Wanneer het digitaliseren van je business de reden van dit verandertraject is, dan zie je dat deze verandering zich niet beperkt tot alleen het afdelingsniveau maar de hele organisatie treft.
Een andere aspect van het geschiktheidsonderzoek is de huidige ict-inrichting. Niet elke architectuur is geschikt voor transitie naar de cloud. De technische geschiktheid wordt bepaald aan de hand van een aantal criteria, zoals je huidige diensten en applicaties. Classificeer eerst je workloads, applicaties en ook andere componenten in je architectuur.
Zes categorieën
In dit kader, afhankelijk van de eigenschap van je applicaties kun je hen in zes categorieën onderverdelen: cloud native, generiek, enterprise, test en dev, high performance en webapplicaties.
De meeste bestaande bedrijfsapplicaties zijn niet geschreven voor de cloud-technologie. Je hebt daarom de keuze om je applicaties te (laten) herschrijven (renew), of te laten vervangen door een nieuwe cloud-ready (replace) of hem behouden (keep). Stel een applicatieplan op: keep/replace/renew. Sommige cloud providers zullen meer geld vragen voor het hosten van je ‘ongeschikte’ applicaties, omdat deze verouderde applicaties meer resources vragen. Ze bieden je ook de optie om samen met hen je applicaties te herschrijven en cloud-ready te maken. Dit is een stap die wat kosten met zich meebrengt, waarna de prijs van hun dienstverlening wordt verlaagd omdat de nieuwe applicaties cloud-ready zijn en dus minder resources verbruiken.
Hoezo herschrijven en extra kosten maken? We nemen een software as a service (SaaS)-dienst af! Wolken aan elkaar knoppen, dat kan! Een SaaS-dienst heeft ook voor- en nadelen. Kan deze vorm van dienst goed aangesloten worden op je bedrijfsprocessen en overige bedrijfsapplicaties? SaaS-diensten krijgen in hoog tempo nieuwe updates die centraal worden doorgevoerd. Heeft dit geen effect op de overige applicaties bij jou in de keten? Er zijn een aantal consequenties (technisch en juridisch) die aan SaaS-diensten gebonden zijn. Raadpleeg je cloud-architect hierover.
Welke keuze je ook maakt, je zult worden geconfronteerd met een aantal kosten om ‘cloud-ready’ te worden. Aan elke keuze zijn zekere subprojecten verbonden die allemaal in een cloud-programma moeten worden gepositioneerd. Denk naast je cloud-strategie ook aan je cloud-programma waar al deze projecten onder vallen.
Hoge beschikbaarheid
High availability is een optie die je integraal in bijna elke cloud-dienst kunt krijgen. Hoezo bijna? De hoge beschikbaarheid kan pas worden gerealiseerd als je de omgeving in twee regio’s dupliceert. In dit kader moet je de beschikking hebben over applicaties die in deze vorm kunnen werken. Terug naar het eerste punt, de applicaties moeten geschikt zijn voor de inrichting in een high availability-model over twee regio’s ‘cloud-ready’. Heb je dat niet dan moet je of van deze optie afzien of je (traditionele) applicatielandschap laten herschrijven/vernieuwen naar een cloud-ready-vorm. Uiteraard mag je meer kosten maken om deze legacy in een vorm mee te nemen naar je nieuwe omgeving. Let wel dat de high availability-keuze effecten heeft op de financiële kanten van de business case. Je heb te maken met kosten van twee keer meer virtuele servers, twee keer load balancer, extra dataverkeer, monitoring et cetera.
Supermarktoorlog in cloud
Vechten om de klanten met scherpe prijzen zien we niet alleen bij de supermarkten. Vooral grote cloud-leveranciers komen met scherpe prijsmodellen om klanten aan te trekken. Wie ga je kiezen? Je kunt een leverancier beoordelen op applicaties, service level agreement (SLA) en tooling.
Niet iedere cloud-leverancier ondersteunt elk soort applicatie. Inventariseer welke applicaties je hebt en stel je applicatieplan op (keep/replace/renew). Kijk dan tot hoeverre je leverancier je applicatieplan ondersteunt, wat het kost en wat de voorwaarden zijn.
Je ‘huwelijksvoorwaarden’ binnen de SLA kun je voor de scheiding toetsen op een aantal onderwerpen als wie de eigenaar van de data is en de ‘voorwaarden’ hiervan (lees goed de voorwaarden van dit onderwerp). Hoe is het formaat van data die je terug kan/mag halen? Wat zijn de voorwaarden van ‘service credit’ (geld terug)? Welke zaken zijn benoemd onder exit en opzegging? Wat staat benoemd onder ‘exclusions’? Denk bij het opstellen/lezen van je SLA aan het liedje Hotel California van The Eagles: ‘You can check-out any time you like, but you can never leave!’.
In een cloud-architectuur heb je voor tooling een ‘orchestration platform’ nodig om dit landschap centraal te beheren. Elke provider heeft een eigen tool met verschillende mogelijkheden. Afhankelijk van hoe je je architectuur inricht kun je soms met meer beheer-interfaces bij verschillende cloudleveranciers te maken krijgen. De kracht en mogelijkheden van deze tools zijn belangrijk voor je omgeving. Sommige providers bieden bijvoorbeeld een tool aan waarmee je je gebruik en capaciteit niet alleen nauwkeurig kan meten maar ook proactief kan beheren. Dit heeft effect op de prijs die je betaalt als je contract gebaseerd is op een pay per use-constructie.
Ik hou van Holland
Infrastructuur as a service (IaaS) van de bekende en grote cloud-leveranciers zijn uitgebreid en compleet en worden ook constant ontwikkeld. Daar tegenover staan de Europese of Nederlandse cloud-leveranciers die op technisch niveau wellicht niet beter zijn maar wel beter kunnen inspelen op bepaalde behoeftes. Vind je directe contacten en het gezamenlijk opstellen van een SLA belangrijk, dan heb je bij veel Nederlandse leveranciers de ruimte en mogelijkheid om dit te realiseren.
Je verbinding naar grote spelers zoals Amazon Web Services of Microsoft loopt via internet. Heb je vanwege je business een private verbinding met het datacenter van je cloud-leverancier nodig, dan kun je dit eenvoudig met je Nederlandse cloud-leverancier realiseren. Grote leveranciers voldoen aan verschillende ISO-normen en certificeringen, maar de deuren van deze leveranciers staan niet open voor de auditing die voor jouw business moet worden verricht. Deze is wel mogelijk bij je Nederlandse cloud-leveranciers.
Cloud is niks meer dan ‘software defined computing’ die door middel van een orchestration-laag elastisch wordt aangeboden. Afhankelijk van ondermeer je plannen, strategie en business kun je deze omgeving als dienst bij een leverancier afnemen (IaaS) of bij een (Nederlandse) cloud-leverancier laten ‘bouwen’ (private IaaS). Let wel, aan deze keuze zijn wel voor- en nadelen verbonden.
De twee mannen
Cloud kan voordelen en mogelijkheden voor je bedrijfsvoering opleveren. Baseer je business case op de toegevoegde waarde van cloud en niet op de financiële voordelen. Want het is een illusie om te denken dat je met cloud goedkoper uit bent dan in je huidige situatie.
Het inzetten van deze mogelijkheden, de transitie en transformatie die je onderneming in dit verandertraject mee gaat maken en nog veel andere onderwerpen zijn zaken waar je niet dagelijks mee te maken hebt. Begin met het onderzoeken van de cloud, beperkingen, valkuilen, voorwaarden en nog andere zaken. Blijf nuchter en verbreed je gezichtsveld, laat je niet in deze fase beïnvloeden door aanbieders die hun diensten alleen op een (grote) cloud-leverancier hebben gebaseerd. Stel vanaf het begin een team samen. Een cloud-architect en een (technisch) projectmanager met kennis van dit soort verandertrajecten zijn zeker twee mannen die je nodig hebt voor het onderzoek en ook later, bij de start van dit traject en bij de veranderingen die de organisatie ondergaat in de overgang naar de cloud.
Dit artikel is eerder verschenen in Computable magazine jaargang 48, nummer 6, zomer 2015.
@Will,
Top reactie en mooie aanvulling, bedankt!
Het is een artikel en hieraan zijn beperkingen qua lengte en te bespreken onderwerpen gebonden. In dat kader heb ik gekozen voor een aantal aspecten en korte en beperkte benadering daarvan.
– In je reactie verwijs je naar een aspect binnen de ict trajecten: Verandermanagement. Onder “Geschikt/ongeschikt” heb ik niet alles van dit soort trajecten kunnen/willen benoemen. Verandermanagement is inderdaad een deel van dit soort “verandertrajecten”. De geschetste organisatie is misschien te mooi en komt misschien niet overeen met wat we in de praktijk tegenkomen. Ik koos voor het benoemen van een aantal onderwerpen. Een (project)manager met wat ervaring weet snel dat de uitdaging met de organisatie meer is dan wat ik hierboven benoemd heb 🙂
– Wat betreft de applicaties en wat je ermee wilt doen heb ik geprobeerd aandacht aan twee zaken te besteden:
1) Je applicatie bepalen heel sterk welk prijskaartje aan je offerte hangt.
2) Je applicatie hebben invloed op het behalen van je (business)doelstellingen in een cloudtraject.
M.b.t. je opmerking omtrent SaaS kan ik niet goed plaatsen, sorry.
– Kort door de bocht…..ik vind cloud niks meer dan software defined computing. Uiteraard zitten er nog andere dingen in maar het was niet de bedoeling om al die aspecten ook nog te bespreken 🙂
Nogmaals bedankt voor je mooie reactie, zeer mee eens. Leuke aanvulling!
@Reza:
De opmerking over SaaS:
Boven het kopje “Geschikt of ongeschikt” staat in een kader de volgende zin: “Om misverstanden te voorkomen richt ik me in dit artikel op infrastructure as a service (IaaS).”. Terwijl de inhoud onder het kopje “Zes categorieën” alleen maar over SaaS en dito diensten gaat.
Vanuit een SaaS context kan ik de 6 categorieën begrijpen. Vanuit een IaaS context lijkt me dat niet relevant omdat, afhankelijk van de invulling van externe koppelingen, elke applicatie op een of andere manier wel in een IaaS-dienst te gieten is. Vandaar de vraag: “Hoe zie je dat?”.
Will,
Ik bleef toch bij mijn onderwerp IaaS en ik probeerde te verduidelijken welke zaken dit onderwerp beïnvloeden. In dit kader heb ik onder dat kopje geprobeerd:
A) applicaties te categoriseren volgens 6 eigenschappen,
B) bewustwording te creëren door de link te leggen tussen de eigenschappen van applicaties en de keuze van je IaaS leverancier en IaaS oplossing. Want veel klanten weten niet dat hun applicatielandschap (en dus ook hun bedrijfsprocessen) niet altijd geschikt is/zijn voor een Cloudmodel.
C) de inhoud onder het kopje “Zes categorieën” gaat niet alleen maar over SaaS en dito diensten (lees punt B)
SaaS is daarin benoemd omdat ik het over vernieuwen en rationaliseren van je applicaties had. In dat kader heb ik snel een zijstap naar SaaS gemaakt om het gezichtsveld te verruimen.
[…] Vanuit een SaaS context kan ik de 6 categorieën begrijpen. Vanuit een IaaS context lijkt me dat niet relevant […]
Mijn vertrekpunt in dit artikel is applicaties in een on premises omgeving die vervolgens naar een cloud-omgeving gaan. De zijstap naar SaaS was maar kort als een doordenkertje. Ik bleef in de “conversiefase” van deze applicatievormen naar een geschikte vorm voor een cloudmodel zoals IaaS. En je hebt het over SaaS in een IaaS model,iets wat mij betreft een aantal stappen na conversiefase is.
Of deze move (overstap naar SaaS) in een IaaS relevant is kan ik er in een ander artikel op ingaan. Ik blijf nog even in dit artikel bij de eerste stap, transitie en conversie van je on premises applicaties naar een geschikte vorm voor een cloudmodel.
Dag Reza,
Je hebt een mooi artikel geschreven waarin het heel redelijk lijkt van wat je schrijft, toch kan ik me maar matig in je artikel vinden. Ik zal onderbouwen waarom ik dat vind.
“vervang de ict-afdeling door de cloud!” lees je vaak schrijf je. Dat is een uitspraak die ik wil toetsen. Ik heb deze uitspraak ergens nergens terug kunnen vinden. Nu snap ik wel dat je waarschijnlijk bedoeld dat veel leveranciers je willen “ontzorgen” echter zelden gaat dit over het overstappen naar de cloud. Het is meer in het kader van outsourcen en dat de andere partij ook je ijzer wellicht onder brengt. Het is echter kenmerkend van onzorgvuldigheid om dit soort uitspraken te doen.
Zo schrijf je “Binnen de ict-organisatie krijgt de ict-afdeling een andere rol.” en verder “elke nieuwe functies ontstaan zijn en welke functies overbodig gaan worden.” Maar je geeft niet één voorbeeld hiervan. Je schrijft nadrukkelijk dat de scope IaaS is, maar ik zie zelf niet één voorbeeld van welke functies nu verdwijnen doordat Iaas omarmt gaat worden. Want je gaat niet zeggen “email administrator”, die hou je namelijk als je de spullenboel verhuisd en hier ga ik zometeen verder op in. Daarnaast ken ik niet één bedrijf wat hardisken vervangen of hardware plaatsen als FTE opvoert. De vraag dan is dan ook: Wat zijn de voordelen van IaaS? Zoals Will terecht opmerkt grijp je dan zelf weer behoorlijk terug op SaaS.
Waar het curieuzer wordt is bij “Niet elke architectuur is geschikt voor transitie naar de cloud.”
En daarmee leg je in mijn oog een zenuw bloot welke zijn weerslag later krijgt op “twee mannen”. Waarom zou je een architectuur willen verplaatsen naar de cloud? Dan krijg je een typisch gevalletje “same shit, different town”. Ik zie dit vaker. Architecten die naar de cloud willen verhuizen capriolen uithalen en aan het eind roepen dat de cloud niet goedkoper is. Duh, je hebt de essentie van cloud computing gemist. Daar doe je namelijk de dingen *anders*. Wat zijn de mogelijk voordelen om de spullen die je hebt te verplaatsen naar iemand ander zijn ijzer?
Veel IT mensen hebben geen clue wat cloud computing eigenlijk inhoud. Ze kunnen die switch niet maken en als ik eerlijk ben zie ik in je artikel niets terug komen waarom cloud computing nu uniek is. Je hebt het wel over de schijnbare noodzaak om iets met cloud computing te doen, maar kunt eigenlijk niet benoemen waar nu de voordelen zitten. Dat is logisch want als je in traditioneel hosting blijft denken is dat voordeel er ook niet. Waar zit het financiële voordeel? Waar zit de flexibiliteit? Waar zit de effectiviteit? Je geeft domweg geen voorbeelden en eigenlijk geloof je helemaal niet in cloud computing.
Op zich snijdt je een paar interessante onderwerpen aan maar vervolgens kom je meer met een anti-cloud argument in deze quote: “Let wel dat de high availability-keuze effecten heeft op de financiële kanten van de business case. Je heb te maken met kosten van twee keer meer virtuele servers, twee keer load balancer, extra dataverkeer, monitoring et cetera.” – Dit is niet waar! Of zeer beperkt waar, maar juist het punt die de kosten hoger maakt – de kosten van opslag” die noem je niet. Nu is fail-over een netelig ding. Maar je kunt wel degelijk een fail-over realiseren zonder dubbele lasten of servers. Dit gaat uiteraard niet om traditionele applicatie hosting, maar nogmaals daar zit ook weinig toegevoegde waarde in. Ik weet in ieder geval zeker dat je fail-over in zowel AWS als Azure kunt realiseren zonder dat je daar een mirror architectuur voor over hebt.
SLA zijn geen huwelijks voorwaarden. Huwelijkse voorwaarden worden pas van kracht als je gaat scheiden, niet als je huwelijk niet lekker loopt. De essentie van cloud computing is juist dat je bouwt voor veerkracht en beschikbaarheid. Als je afhankelijk wordt van je SLA ben je sowieso als kansloos. Dat is roepen dat je verzekerd ben net nadat je aangereden bent door een auto. Een verzekering bestaat om je helpen bij onmogelijk te dragen kosten bij ongevallen. Er is geen SLA ter wereld die werkt als een verzekering, maar nu raak ik off-topic.
En daarmee valt ook het “ik hou van Holland¨ argument in het water. Overigens maak je daar wederom de fout door te stellen dat verbinding naar Azure en AWS over het internet loopt zoek maar eens op ExpressRoute: “ExpressRoute connections do not go over the public Internet,
and offer more reliability, faster speeds, lower latencies and
higher security than typical connections over the Internet.”
Sorry, maar dit geeft gewoon aan dat je niet werkelijk verdiept hebt in de materie.
En de aap komt daadwerkelijk uit de mouw met deze uitspraak “Cloud is niks meer dan ‘software defined computing’”
Dit is namelijk typisch de “ik ben IT-er en ben tegen de cloud” mentaliteit die ik bij veel bedrijven tegen kom.
Virtualisatie en software defined network en storage (vallen die laatste twee bij jou ook onder computing?) zijn slechts een onderdeel van IaaS. Dashboard, monitoring, security en juiste de provider “extra’s” tillen IaaS naar een daadwerkelijk hoger niveau. Het is ook juist de specifieke dienst die de waarde toevoegd en niet de label “cloud”. Cloud is niets, zegt niets en kun je gewoon direct in de prullenbak gooien. Je hebt diensten die dingen aanbieden. Die bepalen de waarde, niet of het al dan niet “cloud” is.
Zeker met bijvoorbeeld de trend dat je Azure ook lokaal kunt realiseren maakt cloud het zand van Klaas Vaak.
Voordelen van IT zijn niet om je huidige spullenboek te verplaatsen naar de omgeving van een ander. Wat kun je daar mee oplossen?
Dan bij de laatste alinea vind ik gewoon “twee mannen” ongepast. Hiermee sluit je vrouwen expliciet uit en dat is per definitie onverstandig. Eerst zeg je dat verander traject impact op de organisatie heeft, maar vervolgens geef je aan dit met twee mannen op te lossen. Hiermee zit je in mijn ogen echt op het verkeerde spoor.
De vraag is niet “to cloud or not to cloud” en de business case die daarbij komt en al helemaal niet door het dan te beperken met een IaaS scope.
Nu lijkt het alsof ik louter negatief ben. Laat ik dat verzachten met de woorden dat ik je capabel vind, je stap niet in zeven sloten tegelijk hebt een brede kennis ook van IAM (één van de kernzaken als je alleen maar denkt aan het woord cloud) en ik ook geloof dat je als project manager prima uit de voeten kan.
Maar als je over cloud schrijft zal ik je artikelen lezen en kritisch zijn. En wat hier staat ben ik het gewoon grotendeels niet eens terwijl er wel dingen in staan die zinvol zijn (rationalisatie) alleen blijf je veel te traditioneel waardoor de essentie verloren gaat.
@Henri,
Dank dat je de tijd nam voor deze uitgebreide reactie. Altijd mooi om het artikel te verrijken met ideeën, ervaring en aanvullingen van anderen.
Schrijven, lezen en reageren op opinies zijn allemaal een soort eenrichtingscommunicaties met veel kans op misverstanden en andere bijwerkingen 😉
De discussie is verder zinvol als de uitgangspunten en de scope waarin onderwerpen besproken worden, in opinie en reacties overeen komen. in dit kader zie ik veel punten in je reactie die vanuit mijn kant of anders bedoeld waren of niet binnen de scope vallen.
Om te beginnen dit is een artikel met veel verschillende onderwerpen die ik probeer onder aandacht te brengen. Als ik elk onderwerp dat ik benoemd heb moet onderbouwen, bewijzen en met voorbeelden komen dan moet ik een Deel 2, 3, 4, 5 van dit artikel maken. Dat was niet mijn uitgangspunt bij het schrijven van dit artikel.
“vervang de ict-afdeling door de cloud!” is misschien beetje kort door de bocht maar je weet heel goed dat de boodschap van veel marketeers en opportunistische leveranciers hierop aankomen. Kijk bijvoorbeeld naar de woorden van iemand zoals Marco Gianotten in zijn artikelen over ICT afdeling.
“Binnen de ict-organisatie krijgt de ict-afdeling een andere rol” en ik geef geen voorbeel….Dat klopt! Nogmaals, ik was niet van plan bij elk onderwerp een voorbeeld te geven. Als iemand beetje bekend is met Cloud, outsourcing of verandertrajecten dan weet hij/zij waar ik het over heb. En ook het effect van dit fenomeen is verschillend op elke organisatie. Hoe de afdeling opgebouwd is en hoe ze naar cloud gaan en wat ze naar cloud willen brengen etc zijn zaken die eerst moeten bekend zijn om daarna iets over het effect te kunnen noemen. Nogmaals, hoe jij je opinie schrijft en voor wie je dat schrijft zijn anders dan hoe ik dat doe (scope en aanvliegroute) M.b.t. SaaS en wat Will zei verwijs ik je naar mijn reactie hierop aan Will in mijn post hierboven.
Grote misverstand van je als je denkt dat ik bedoelde dat de huidige architectuur naar cloud moeten brengen! Helemaal niet. Wat mij betreft moet je beter afscheid nemen van de oude zooi en de nieuwe omgeving baseren op de nieuwe diensten en inrichting.
Als iemand iets over onzichtbare of onbekende kanten van cloud roept dan zou ik niet snel zeggen dat dit een “anti-cloud argument” is. Als je goed in mijn geheel opinie kijkt dan zie ik dat ik vaak geroepen heb dat de mogelijkheden van cloud nuttig kunnen zijn voor je bedrijfsvoering.
In dit kader blijf ik de Cloud niks meer dan ‘software defined computing’ vinden en ik vind je reactie opmerkelijk als je zegt, dit is namelijk typisch de “ik ben IT-er en ben tegen de cloud” mentaliteit. Beste Henri, Cloud is geen geloof en ik ben ook geen gelovige iemand!
Je opmerking over “twee mannen” vind ik grappig. Je neemt soms de zaken echt letterlijk. Ik zal vervolgens M/V noemen dan is de verhouding 50 / 50
Wat betreft SLA, daar verschillen we ook van mening. Kan ik er vanuit gaan dat je niet weet wat je verzekerd hebt en onder welke voorwaarden en je laat je verrassen door de verzekeraar nadat je een ongeluk hebt gekregen? Of ga je eerst kijken wat je daarmee veilig heb gesteld en ook tot hoeverre?
@Henri:
Als het gaat om de mogelijkheden en het gebruik van cloud-achtigen heb je voor mij de rol van evangelist en super deskundoloog. Zonder afbreuk te willen doen aan Reza zijn artikel denk ik dat niet iedereen de ruimte (interesse?) heeft om op een dergelijk hoog nivo te denken en te werken. Laat staan daar een artikel over te schrijven met de “juiste” diepgang in een medium als de Computable wat toch een paar “harde” limieten kent.
Dus als er op enig moment iemand is die zich dan toch waagt aan een dergelijk artikel, en je diskwalificeert zo iemand meerdere keren op zijn/haar inhoudelijke kennis, dan lijkt het me iets constructiever om zelf het “goede” voorbeeld te geven. Bijvoorbeeld door de opsomming van inhoudelijke tekortkomingen te beperken tot 2 of 3 onderdelen. Om vervolgens voor die onderdelen een voorbeeld te geven van wat je verwacht had cq. hoe het wel zit.
Om af te sluiten met een challenge naar de schrijver om in reactie hetzelfde te doen. Vanuit de optiek “kennisoverdracht” lijkt me dat op zijn minst een ietwat handigere aanpak – we leven immers in een kennismaatschappij – toch? 😉
Tot slot inhoudelijk nog een tweetal vragen/opmerkingen:
(1) – Afgaande op de product beschrijvingen van de ExpressRoute connectie achtigen van Azure en AWS zijn deze enkel beschikbaar voor een verbinding naar het bedrijfseigen data center / netwerk center (of hoe je het verder ook wil noemen). Een connectie naar een andere XaaS-dienstverlener gaat per definitie over het publieke internet – al dan niet via een VPN. Waarschijnlijk zie ik iets over het hoofd – maar hoe zie je een dergelijke verbinding werken als je je complete applicatie landschap “ergens” op twee of meer wolken hebt draaien?
(2) – Vanuit de IaaS gedachte: als je in een Azure of AWS omgeving een “server” opstart om een eigen ontwikkelde applicatie in bedrijf te nemen heb je volgens mij toch echt wel een tweede nodig om op applicatie nivo (en onderliggende software stack) enige vorm van HA te verkrijgen; ondanks dat het ijzer en een seperaat draaiende database al een vorm van HA ondersteunen. Ook hier – misschien heb ik iets gemist – maar welke mogelijkheden zijn er in dergelijke gevallen om zonder een tweede “server” toch een vorm van HA te kunnen gebruiken?
Will, om mijn vervolg reacties niet langer te laten worden dan het artikel zelf, hier even kort.
Opinie is opinie en dat is goed, je geeft een mening en licht deze toe en ik snap dat het altijd niet helemaal technisch kan en hoeft. Wat ik bewaak is dat feitelijke uitspraken wel getoetst worden of aan de kaak gesteld worden.
Reza zijn artikel is best goed en lijkt zinnig -veel traditionele IT-ers zullen het vooral eens zijn met Reza- geef ik tegengas omdat niet alleen de term cloud heel vaak niet goed gebruikt wordt, maar dat ook inhoudelijk door de algemene term en een hoop -in mijn ogen- onzin de wereld in geslingerd word.
En vooral als er gewoon iets staat wat pertinent niet klopt “Je verbinding naar grote spelers zoals Amazon Web Services of Microsoft loopt via internet.” Dan is het toch logisch dat ik hierop reageer. Overigens kan ik heel goed opschieten met Reza en heb ik zijn capaciteiten ook hoog zitten maar op bepaalde vlakken schuurt het wel eens. Da’s prima en maakt het wellicht ook aantrekkelijk om te lezen.
Dan je twee vragen:
1) Regel gewoon met je huidige hoster / provider / data center dat je die verbinding naar AWS krijgt, dat is geen probleem. Een klant van me heeft zo’n verbinding van Terremark naar AWS en dat werkt prima. Wees je wel bewust dat er in sommige gevallen een lock-down plaats vind. Sommige dure lijnen neem je voor een paar jaar af en dan is verplaatsen weer een stapje moeilijker / duurder geworden.
2) Lees als voorbeeld: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html
Sure, bij een 1 op 1 (database) server betaal je voor 2 instances voor HA, maar je hoeft daarvoor geen enkele extra kosten te maken, ook met load balancers en dat soort zaken is geen extra inspanning nodig. Als het gaat om applicaties die als cloud applicatie over meerdere servers draaien hoef je slechts 1 instance paraat te hebben in een andere regio welk na fail-over op kan schalen. De kosten van HA zijn dus veel lager als je dat je de gehele omgeving dubbel uit moet voeren. Juist hier komt het elastische, schaalbare en betaal alleen voor wat je gebruikt heel mooi naar voren. Hierin blinkt cloud computing dus uit. Voor “gewone” of disaster failover waarbij een downtime van meer dan een paar minuten geen probleem is heb je nog veel meer krachtige -doch goedkoop ten opzicht van traditionele IT mogelijkheden-.
De crux blijft dat IT verplaatsen of alleen denken in termen van IaaS versus SaaS inderdaad weinig voordelen biedt.
@Will,
Weer bedankt voor je mooie aanvulling!
Wat betreft Henri…….zoals hij aangeeft we kennen elkaar en inmiddels weet ik dat hij op 1 punt op mijn ex-vriendin lijkt: reageren vanuit emotie 🙂 Vooral als de naam Cloud geroepen wordt 🙂
Ik was ook verbaasd over zijn reacties op sommige punten maar ….even tot 10 tellen…oh ja, het is Henri 🙂
De keuze voor de inhoud, opbouw en aanvliegroute van dit artikel waren bewust. Er zijn genoeg artikelen op deze site die verder ingegaan zijn op technische aspecten van Cloud Computing. Wat ik zelf al een tijd miste was een artikel met overkoepelende zaken om een totaal overzicht te geven van belangrijkste onderdelen en stappen binnen dit fenomeen en een Cloud-traject. Daarom zijn er technisch en niet technisch (zoals organisatorische aspecten) in mijn artikel benoemd.
In dit artikel heb ik geprobeerd dit overzicht te creëren. Als je als verantwoordelijke manager deze kennis hebt dan weet je (ongeveer) waar je aan moet beginnen en hoe je dit traject kunt opzetten.
De informatie uit dit artikel kun je toepassen om de structuur op te zetten voor Cloud-Programma management —-> Projecten management —-> Deel projecten.
Is de Computable de juiste plek voor dit artikel? Ik zou zeggen ….waarom niet? Ik zie veel techneuten en ook niet techneuten (managers en overige non-tech functies ) op verschillende onderwerpen op deze site reageren.
M.b.t. je 1e vraag, ExpressRoute is de oplossing van MS en het antwoord op AWS (ik kom zo hierop terug Henri) Als ik me niet vergis heb je er 2 opties in:
1- direct contact met AWS of Azure
2- Contact via een broker(Exchange) zoals BT of andere leveranciers.
Deze connectie is alleen voor het uitbreiden/verbinden van je LAN naar het DC van MS of AWS. Vanuit DC AWS of Azure als je van een SaaS gebruik wil maken (die buiten DC of AWS/MS zit) dan ga je weer via internet naar je SaaS. Dit heb ik begrepen toen ik begin dit jaar een presentatie over de oplossing heb gekregen.
IAM is verkeersregelaar die een belangrijke functie heeft in deze architectuur.
Ik hoop dat ik je vraag juist begrepen heb en nogmaals bedankt voor je reactie.
Henri,
Misschien is het handiger om onverschillig voorbij wat mensen over Cloud roepen te gaan! Je felheid, omdat je hoort wat je niet wilt horen, werkt zeker averechts. En zoals ik je eerder gezegd heb, reageren vanuit je enthousiasme en overtuiging heeft pas nut en kracht als dat gedragen wordt.
Terug naar een onderwerp dat ik vergeten was te benoemen…..dit artikel had eerst 4 conceptversies. In het concept waren omtrent directe verbinding met DC, een aantal namen van grote IaaS leveranciers benoemd zoals MS, AWS, IBM, Google en nog twee. In een conceptversie en na review waren de namen van AWS en MS weggehaald want de oplossing van hen was al bekend. Helaas is iets in de afronding van laatste versie misgegaan waardoor deze correctie omgekeerd gecommuniceerd is. En jij maakt er inmiddels een feest van 🙂
Ik heb wat twijfels over wat je over de kosten van HA zegt. Misschien heb je andere uitgangspunten waar je reactie op gebaseerd is.
Ik heb in een tech.sessie van kort geleden, iets anders van architecten vernomen. Verspreiden van je sites over twee regio`s en de inrichting hiervan zijn zeker zaken waar een prijskaartje aan hangt. Voor niks gaat de zon op Henri!
– Denk aan je verbinding en data transfer voor replicatie en nog wat andere zaken.
– Wanneer betaal je iets niet? Als je server uit staat of als je server aan staat en niet gebruikt word?
– En hoe verhoud dit zich tot een actief/passief inrichting voor HA waar de servers in andere regio aan staan maar niet connectie ontvangen? Of worden de servers als off-line gerepliceerd?
– Wat is je definitie van “niet gebruikt worden” ? Aan staan zonder connectie of letterlijk uitstaan?
– Kun je alleen 1 dienst in andere regio aanzetten en de rest intact houden of moet je je hele site failover doen?
Reza,
in een aantal zaken moet je ik zeker gelijk geven, zo reageer ik inderdaad als je ex 😉 Point taken.
Overigens heeft HA een prijskaartje, alleen geloof ik dat deze -mits je de juiste “cloud” gebruikt- serieus lager zijn dan in een niet cloud omgeving, ook hoe je applicatie is opgebouwd is dan van belang.
De andere vragen vergen langere antwoorden.
Basisprincipe van AWS / Azure is: Als het een probleem is wordt er hard gewerkt aan een oplossing. Dat roept iedere leverancier, maar de snelheid waarmee zij het doen is ongekend. En het is niet dat ik verliefd ben op de cloud of liefde voel voor zoiets abstracts als een bedrijf, maar ik ben wel heel erg onder de indruk wat ze te bieden hebben en hun waarde propositie is ongekend. Het wordt afgeschilderd als een evolutie, maar dit is wel degelijk een revolutie. Het is innovatie, maar de weerstand hiertegen is enorm groot en misschien dat ik daarom zo primair reageer op iedereen die het probeert te downplayen.
Niettemin vind ik de reacties weer goed en leerzaam dus dank daarvoor.