maandag 11 januari 2010

Waarom geen Azure?

Ik ben de laatste tijd meer en meer bezig met het Azure Services Platform. En waar het hart vol van is, loopt de mond van over... Ook ik praat met diverse mensen om mij heen over Azure. Helaas blijkt niet iedereen even enthousiast te zijn als ik. Eerst dacht ik dat dit kwam door het "onbekende", of onwetendheid. Dit is zeker voor een aantal mensen het geval, maar er is ook een duidelijke lijn te herkennen in de bezwaren. Langzaam maar zeker begint het ook bij mij door te dringen dat er mogelijke blokkades zijn om het Azure Services Platform te gaan gebruiken. De meest gehoorde blokkades heb ik op een rijtje gezet.

  1. Vertrouwen. Alles valt of staat met vertrouwen. Van wie is mijn applicatie die in the cloud draait? Wie mag er aan mijn data in de cloud komen? Waar staat mijn data, in de USA of in Nederland? Vertrouw ik Microsoft met mijn applicatie en mijn data? Kortom, vertrouwen is een zeer belangrijk aspect.
  2. Beschikbaarheid. Kan Azure een 7x 24 uur operatie ondersteunen met een beschikbaarheid van 99,99%? Hoe gaat Microsoft dit garanderen? Wat is het fallback scenario? Op dit punt is er natuurlijk nog nauwelijks informatie beschikbaar. Ik heb ergens gehoord dat er voor betrouwbaarheid moet worden betaald. Hoe meer je betaald, des te hoger de gegarandeerde beschikbaarheid. Voor het vertrouwen zou het goed zijn wanneer Microsoft en flink aantal serieuze eigen services in the cloud gaat draaien, zoals Amazon bijvoorbeeld doet.
  3. Vendor lock in. Wanneer je eenmaal hebt gekozen voor het Azure Services Platform dan zit je eraan vast. Je kunt niet eenvoudig overstappen naar een concurrent platform van bijvoorbeeld Google of Amazon. Ik zie dit niet als een groot probleem, volgens mij is dit niet anders dan de problemen die wie nu hebben? Daarnaast steunt Azure op diverse open standaarden zodat integratie goed mogelijk is.
  4. Nieuwe API. Microsoft doet haar best om software ontwikkeling voor het Azure Services Platform hetzelfde te laten lijken als "normale" .NET ontwikkeling. Voor een deel is dit ook werkelijk zo, je maakt bijvoorbeeld gewoon gebruik van Visual Studio. Maar er zijn ook aspecten anders, hiervoor is een nieuwe API. Deze API moet je leren kennen en gebruiken voordat er succesvolle Azure applicaties kunnen worden ontwikkeld. Verder moeten applicaties op een andere manier worden ontworpen. Persoonlijk vind ik dit niet erg omdat de design principes 1 : 1 toepasbaar zijn voor je normale applicatie ontwikkeling.
  5. Geen lokale cloud beschikbaar. Het platform is alleen in de cloud beschikbaar. Een organisatie kan er niet voor kiezen om het platform op een eigen infrastructuur te draaien. Microsoft claimt dat het platform op zeer complexe schaalbaarheids principes leunt die niet eenvoudig te realiseren zijn in je eigen infrastructuur. Waarschijnlijk is dit ook zo voor de meeste organisaties. Daarnaast is het hele idee gebaseerd op utility computing, je betaald voor wat je gebruikt zodat je niet zelf een complete infrastructuur hoeft in te richten. Overigens kan het ook anders, IBM kiest voor het model van hybrid cloud computing...

Moet je het Azure Services Platform dan maar niet gebruiken? Ik denk dat er heel veel mogelijkheden en kansen zijn om wel degelijk gebruik te maken van het platform. Natuurlijk is het niet geschikt voor iedere vorm van software ontwikkeling, maar wel voor veel vormen. Wanneer je eenmaal per jaar een pensioenberekening moet doen, dan kan het best interessant zijn om gebruik te maken van de Azure cloud. Of wanneer je een leuk , nieuw "web" idee ontwikkeld (twitter 2.0) is het best interessant om klein te beginnen en daarna mateloos populair te worden op dezelfde infrastructuur: Azure Services Platform. Zo zijn er nog veel meer voorbeelden denkbaar die interessant zijn om the combineren met het Azure Services Platform.

Doen de concurrenten het beter met betrekking tot de beschreven blokkades? Nee, het volledige lijstje is toepasbaar op de concurrenten van het Azure Services Platform. Op het laatste punt (5) doet IBM het anders, maar is dit ook beter?






Geen opmerkingen:

Een reactie posten