Een aantal Web 2.0 bedrijven, zoals Facebook en Google, hebben ietwat tegenvallende resultaten bekendgemaakt. Als belangrijskte oorzaak wordt opgegeven dat het moeilijk blijkt de groei van de inkomsten uit advertenties vast te houden. Ik vind dat niet verbazingwekkend, en in zekere zin zelfs goed nieuws, zeker voor SaaS.
Waarom is het niet verbazingwekkend? Bij de problemen in de advertentiemarkt wordt natuurlijk gewezen naar de economie. Dat is ongetwijfeld terecht, maar er is ook een meer fundamentele oorzaak: advertenties als primaire inkomstenbron voor "Web 2.0" is eenvoudigweg op langere termijn niet vol te houden.
Oorspronkelijk waren sites als Google, Yahoo, allerhande blogs, social networks zoals Facebook een dun schilletje om de appel van de "echte" economie waarin echt geld omging. En die "echte' economie wilde maar al te graag die dunne schil gebruiken als middel om te verkopen.
Maar inmiddels is de schil veel dikker geworden, onder andere doordat veel producten die eerst in de "echte" economie zaten, en echt geld opbrachten, inmiddels digitaal en virtueel zijn geworden. Helaas voor de producenten zijn de betalingen ook virtueel geworden. Een voorbeeld is natuurlijk de muziek-industrie. Die is hard bezig uit de "echte" economie (betalade CDs) te schuiven naar de virtuele Web 2.0-economie (gratis downloads of streams).
Met andere woorden: de schil wordt dikker, en de appel wordt kleiner. En ook nog eens minder relevant, want de produkten die in de oude "echte" economie blijven, zijn veelal niet zo geschikt voor channeling via het Web. Zijn advertenties voor huizen of auto's echt zinvol op een blog over SaaS? De conclusie is onontkoombaar: de Web-economie kan voor de inkomsten niet langer leunen op de "echte" economie, maar zal op eigen benen moeten gaan staan, en zelf tot de "echte" economie moeten gaan behoren.
De consument moet dus gaan betalen voor de diensten en informatie die hij via het Web gebruikt of krijgt. Op dit moment is daarvoor de gangbare oplossing een of andere vorm van abonnement. Ik betaal een bedrag per maand, en krijg daarvoor het recht om een bepaalde dienst of informatiebron te gebruiken. Tot nog toe is dit slechts matig succevol geweest. Daarvoor zijn veel redenen, maar de belangrijkste is dat je je zo als consument te vast verbindt aan een leverancier. Immers, hoeveel abonnementen op bijvoorbeeld een nieuwssite ga je afsluiten? Eén? Twee misschien? Meer niet. Maar dat is nogal een beperking, en bovendien maakt dit het leven voor kleinere of nieuwe aanbeiders veel moeilijker. En het afsluiten van zo'n abonnement is toch een Beslissing. En Beslissingen nemen we liever niet in de vloeibare wereld van het Web.
Veel interessanter is een vorm van microbetaling, waarbij je een klein bedrag betaalt per actie (ophalen bepaalde informatie, gebruik van een dienst). Echt pay-as-you-go dus. Maar er zijn twee hinderpalen.
De eerste hinderpaal is de onwennigheid van de klant. Hoe werkt het? Is het safe? Waarom zou ik betalen als het ook gratis kan? Enzovoort. Ik denk dat als de tweede hinderpaal uit de weg is geruimd, en de aanbieders steeds meer gaan naar betaalde diensten eenvoudig omdat het anders niet meer te doen is, deze onwennigheid vanzelf verdwijnt.
De tweede hinderpaal is het betaalsysteem. De gangbare vorm van betaling op het Web is door middel van de credit card. Die gebruikt men liever niet voor betalingen aan onbekende partijen, en bovendien: het is veel te duur. Er moet dus een systeem komen waarbij je betaalt via een vertrouwde partij, die ook de mogelijkheid geeft je betalingen in te zien of te maximeren, en die voor gegroepeerde betalingen in één keer afrekent met de credit card maatschappij en zodoende de kosten laag houdt. PayPal gaat in deze richting, en het voortreffelijke Flexible Payment System (FPS) van Amazon is een nog beter voorbeeld. En ongetwijfeld komen er alternatieven (een doorontwikkeling van Google Checkout bijvoorbeeld).
Het voordeel voor SaaS wordt zo duidelijk. Het grote voordeel van SaaS is het kostenmodel. Geen grote investering meer vantevoren, kosten die min of meer gelijk op gaan met het gebruik. Maar (over het algemeen) nog wel een abonnement, en daardoor toch een Beslissing, zij het een veel kleinere dan de BESLISSING om een ERP-pekket te kopen en te implementeren. En echt pay-as-you-go is een abonnement ook niet. Als je het nauwelijks gebruikt is het nog steeds duur, en opzeggen is ook weer een Beslissing. (Hoeveel tijdschriften die u niet leest krijgt u elke maand in de brievenbus?)
Deze stand van zaken hindert de verbreiding van SaaS. De beslissing om een bepaalde SaaS-toepassing te gaan gebruiken, wordt moeilijker gemaakt door het feit dat er toch een zekere mate van (economische) lockin is, en dat daardoor alternatieven geen optie meer zijn. (Er zijn daarnaast natuurlijk ook allerhande organisatorische en technische obstakels, maar die laat ik hier buiten beschouwing.) De salescycles voor SaaS-leveranciers zijn (mede) daardoor langer en zwaarder dan men aanvankelijk verwachtte, en in ieder geval duurder dan voor het SaaS-model gewenst is.
Als onder druk van het door de hoeven zakkende advertentiemodel er inderdaad een goed werkend en goedkoop systeem voor microbetalingen tot stand komt, heeft niet alleen de consumentenmarkt daarvan voordeel, maar ook B2B SaaS. Want het wordt zo mogelijk om SaaS niet alleen via het abonnementsmodel ook via een alternatief model aan te bieden. Dat zal de verkoop van meer fijn-granulaire services te mogelijk maken. En ook guerilla-marketing wordt daardoor makkelijker, en dat drukt weer de kosten van de verkoop.
Op dit moment zit SaaS nog tussen tafellaken en servet: SaaS is goedkoper en meer "pay-as-you-go" dan pakketsoftware, maar economisch eigenlijk niet flexibel genoeg om de beloften volledig waar te kunnen maken. Voor een deel heeft dat te maken met het betaalmodel. De komst van een echt pay-as-you-go-systeem in de consumentenmarkt gaat daarin verandering brengen, en daarom zijn de tegenvallende advertentie-inkomsten van Google, Facebook, c.s. goed nieuws.
dinsdag 29 juli 2008
vrijdag 25 juli 2008
For whom the bell tolls...., part 3
Eerder schreef ik (hier en hier) over de problemen die leveranciers van "oude" pakket-software gaan krijgen als ze de (prijs)concurrentie van SaaS-leveranciers gaan voelen.
SAP heeft kennelijk besloten naar voren te vluchten, en bestaande klanten vanaf 1 januari 2009 meer te laten betalen voor lopende contracten. Die zijn daar natuurlijk niet blij mee, en SAP zal dat ook best hebben voorzien. Maar die klanten kunnen voorlopig geen kant uit, dus: kassa.
Alleen: het zal de overstap naar goedkopere SaaS-alternatieven (misschien wel van SAP zelf) op iets langere termijn alleen maar versnellen, maar wie dan leeft, die dan zorgt. Denken ze blijkbaar in Walldorf.
SAP heeft kennelijk besloten naar voren te vluchten, en bestaande klanten vanaf 1 januari 2009 meer te laten betalen voor lopende contracten. Die zijn daar natuurlijk niet blij mee, en SAP zal dat ook best hebben voorzien. Maar die klanten kunnen voorlopig geen kant uit, dus: kassa.
Alleen: het zal de overstap naar goedkopere SaaS-alternatieven (misschien wel van SAP zelf) op iets langere termijn alleen maar versnellen, maar wie dan leeft, die dan zorgt. Denken ze blijkbaar in Walldorf.
dinsdag 22 juli 2008
Investeringen in cloud-computing
Volgens een rapport van Goldman Sachs, waarover ComputerWorld heeft gepubliceerd, zal de werkgelegenheid in de IT dalen. Althans, volgens de geinterviewde CIO's en business executives, want daarop is het verhaal gebaseerd. Bedrijven gaan minder besteden outsourcing en aan contractwerk, en kostenbesparing dmv virtualisatie e.d. krijgt veel aandacht.
Het is allemaal niet vreemd, en perfect logisch, zeker als het economisch wat minder gaat, al vloeit uit het mindere werk in de bedrijven van de "top CIOs" niet voort dat er elders niet werk kan bijkomen.
Interessanter is de opmerking aan het eind dat de interviewees geen grote investeringen in cloud-computing, SaaS, e.d. verwachten. Men vindt dat verrassend, maar in het stuk wordt opgemerkt dat hier wel eens sprake kan zijn van een "pointy-haired boss" probleem:
"One reason for the low priorities of grid computing, open-source software and cloud computing may be that CIOs and business executives don't understand their value. "They require a technical understanding to get to their importance. I don't think C-level executives and managers have that understanding," King said."
[King is Charles King, een aangehaalde analyst.]
Inderdaad, het zou heel goed kunnen. Dit soort toplieden loopt vaak wat achter de feiten aan.
Maar er zijn nog twee andere redenen denkbaar waarom ze cloudcomputing en SaaS niet erg zien, en het dus neit als prioriteit noemen.
1. de impact van SaaS en cloudcomputing vindt (nu nog) grotendeels buiten invloedssfeer van CIOs e.d. plaats. Het gaat hier om CIO's e.d. van grote bedrijven, terwijl voor SaaS en cloudcomputing geldt dat de winst juist voor kleinere bedrijven veel groter is. Binnen grote bedrijven wordt SaaS vooral toegepast bij afdelingen en voor systemen die nou net niet bediend worden door de IT-afdeling van de CIO.
Als dit waar is, dan zijn SaaS en cloudcomputing voor die CIOs topjes van ijsbergen waarvan zij denken dat ze nog ver weg zijn.
2. SaaS en cloudcomputing vergen gezien vanuit de klant domweg niet zoveel investeringen, en daarom wordt het niet als prioriteit genoemd.
Want dat blijft natuurlijk wel waar: SaaS en cloudcomputing kunnen de kosten van "corporate IT" aanzienlijk verlagen, en dat is ook hun belangrijkste voordeel. En inderdaad, voro de werkgelegenheid in de "corporate IT" heeft dat grote gevolgen.
Voor de IT als geheel kan dat best heel anders liggen.
Het is allemaal niet vreemd, en perfect logisch, zeker als het economisch wat minder gaat, al vloeit uit het mindere werk in de bedrijven van de "top CIOs" niet voort dat er elders niet werk kan bijkomen.
Interessanter is de opmerking aan het eind dat de interviewees geen grote investeringen in cloud-computing, SaaS, e.d. verwachten. Men vindt dat verrassend, maar in het stuk wordt opgemerkt dat hier wel eens sprake kan zijn van een "pointy-haired boss" probleem:
"One reason for the low priorities of grid computing, open-source software and cloud computing may be that CIOs and business executives don't understand their value. "They require a technical understanding to get to their importance. I don't think C-level executives and managers have that understanding," King said."
[King is Charles King, een aangehaalde analyst.]
Inderdaad, het zou heel goed kunnen. Dit soort toplieden loopt vaak wat achter de feiten aan.
Maar er zijn nog twee andere redenen denkbaar waarom ze cloudcomputing en SaaS niet erg zien, en het dus neit als prioriteit noemen.
1. de impact van SaaS en cloudcomputing vindt (nu nog) grotendeels buiten invloedssfeer van CIOs e.d. plaats. Het gaat hier om CIO's e.d. van grote bedrijven, terwijl voor SaaS en cloudcomputing geldt dat de winst juist voor kleinere bedrijven veel groter is. Binnen grote bedrijven wordt SaaS vooral toegepast bij afdelingen en voor systemen die nou net niet bediend worden door de IT-afdeling van de CIO.
Als dit waar is, dan zijn SaaS en cloudcomputing voor die CIOs topjes van ijsbergen waarvan zij denken dat ze nog ver weg zijn.
2. SaaS en cloudcomputing vergen gezien vanuit de klant domweg niet zoveel investeringen, en daarom wordt het niet als prioriteit genoemd.
Want dat blijft natuurlijk wel waar: SaaS en cloudcomputing kunnen de kosten van "corporate IT" aanzienlijk verlagen, en dat is ook hun belangrijkste voordeel. En inderdaad, voro de werkgelegenheid in de "corporate IT" heeft dat grote gevolgen.
Voor de IT als geheel kan dat best heel anders liggen.
vrijdag 18 juli 2008
For whom the bell tolls.... part 2
Aardig stuk van Sarah Lacy in BusinessWeek. Strekking: de grote mastodonten van de "oude" software, zoals SAP en Microsoft, hebben grote moeite om zich een plaats te verwerven in de SaaS/cloud-wereld. En zij schrijft dat (terecht denk ik) vooral toe aan het feit dat in SaaS nu eenmaal veel minder verdiend wordt dan wat de mastodonten gewend zijn.
Oracle volgt volgens haar een andere koers: nu zoveel mogelijk het oude model uitmelken, en dan later de succesvolle SaaS=-leveranciers "cherry-picken". Ongetwijfeld zal dit het plan van Oracle zijn, maar dan nog steeds: ook dan zal Oracle merken dat de marges in SaaS en in de cloud veel smaller zijn. En ik zie niet waarom Oracle daar zoveel beter tegen zou kunnen dan SAP of Microsoft.
Twee maanden geleden postte ik:
"Dat vereist een andere manier van verkopen, een andere benadering van de klanten, en vooral ook een veel goedkopere bedrijfsvoering. En juist daar hebben bedrijven die zeer succesvol waren in het licentie-pradigma, zoals SAP en Microsoft, een probleem. Want ze verdienden geld als water, en hebben de kostenstructuur daarop afgestemd. Die kostenstructuur (salarissen, bonussen, hoofdkantoren, enzovoort, enzovoort) veranderen is heel moeilijk, ook al weet je dat het nodig is."
Dat is het probleem van SAP en Microsoft, en het wordt het probleem van Oracle.
Oracle volgt volgens haar een andere koers: nu zoveel mogelijk het oude model uitmelken, en dan later de succesvolle SaaS=-leveranciers "cherry-picken". Ongetwijfeld zal dit het plan van Oracle zijn, maar dan nog steeds: ook dan zal Oracle merken dat de marges in SaaS en in de cloud veel smaller zijn. En ik zie niet waarom Oracle daar zoveel beter tegen zou kunnen dan SAP of Microsoft.
Twee maanden geleden postte ik:
"Dat vereist een andere manier van verkopen, een andere benadering van de klanten, en vooral ook een veel goedkopere bedrijfsvoering. En juist daar hebben bedrijven die zeer succesvol waren in het licentie-pradigma, zoals SAP en Microsoft, een probleem. Want ze verdienden geld als water, en hebben de kostenstructuur daarop afgestemd. Die kostenstructuur (salarissen, bonussen, hoofdkantoren, enzovoort, enzovoort) veranderen is heel moeilijk, ook al weet je dat het nodig is."
Dat is het probleem van SAP en Microsoft, en het wordt het probleem van Oracle.
woensdag 16 juli 2008
Mark van den Brand
Dit is zo te zien een samenvatting van de inaugurale rede die Mark van den Brand gaf op 3 juli j.l. in Eindhoven.
vrijdag 11 juli 2008
REST en gedistribueerde objecten
Ik heb wat lovende reacties gekregen voor een eerdere post over REST. Dank daarvoor.
Maar ik heb ook wat misverstanden geschapen, geloof ik.
Is REST de opvolger van Java voor zover het de implementatie van het object-model betreft? Nee. REST is wat mij betreft alleen de implementatie van de structuur van het object-model: de samenhang tussen de grof-granulaire domein-objecten, en voor de communicatie tussen die objecten.
Althans: voorzover ze op het Web zijn gedistribueerd.
Dus de "binnenkant" van de objecten zal met een andere taal, Java, of Python, of Ruby, of voor mijn part Cobol, C of Erlang, worden geimplementeerd. En als de de objecten niet gedistribueerd behoeven te zijn, maar alleen maar "lokaal" in een applicatie worden gebruikt, is REST ook overbodig.
Maar ik denk wel dat die grof-granulaire objecten steeds meer (ook) als zelfstandige entiteiten op het Web beschikbaar moeten zijn, dat wel.
En ik denk ook dat REST niet het eindpunt is. Daarvoor is REST te weinig passend op wat je echt wil. Niet alleen is de "fit" met object-modellen niet 100%, maar vooral ook het feit dat het communicatie-protocol HTTP is, levert beperkingen op.
Natuurlijk is volgens de REST-adepten juist het gebruik van plain HTTP het grote voordeel, en ze hebben in veel opzichten gelijk. Maar bijvoorbeeld asynchroniteit zit niet in HTTP. Dat betekent dat als asynchrone messages nodig zijn (en dat is bijna altijd zo), dat moet worden opgelost binnen de resources of althans binnen de server die de resources beheert.
Een gestandaardiseerde abstractielaag bovenop REST, waarbij de URI-structuur in stand blijft, prettig zou zijn. Komt zo dan toch weer WS-* via de achterdeur binnen? Nee, dat is niet de bedoeling. Veel WS-* standaarden hebben op zichzelf nut, alleen: de implementatie is zeer toolgebonden, en erg ondoorzichtig.
Ik vraag me af: zou het mogelijk zijn een Erlang-achtige taal te maken die asynchroniteit inbouwt, en gewoon op HTTP is gebaseerd? Of gaat dat toch weer een lekkende abstractie worden?
Maar ik heb ook wat misverstanden geschapen, geloof ik.
Is REST de opvolger van Java voor zover het de implementatie van het object-model betreft? Nee. REST is wat mij betreft alleen de implementatie van de structuur van het object-model: de samenhang tussen de grof-granulaire domein-objecten, en voor de communicatie tussen die objecten.
Althans: voorzover ze op het Web zijn gedistribueerd.
Dus de "binnenkant" van de objecten zal met een andere taal, Java, of Python, of Ruby, of voor mijn part Cobol, C of Erlang, worden geimplementeerd. En als de de objecten niet gedistribueerd behoeven te zijn, maar alleen maar "lokaal" in een applicatie worden gebruikt, is REST ook overbodig.
Maar ik denk wel dat die grof-granulaire objecten steeds meer (ook) als zelfstandige entiteiten op het Web beschikbaar moeten zijn, dat wel.
En ik denk ook dat REST niet het eindpunt is. Daarvoor is REST te weinig passend op wat je echt wil. Niet alleen is de "fit" met object-modellen niet 100%, maar vooral ook het feit dat het communicatie-protocol HTTP is, levert beperkingen op.
Natuurlijk is volgens de REST-adepten juist het gebruik van plain HTTP het grote voordeel, en ze hebben in veel opzichten gelijk. Maar bijvoorbeeld asynchroniteit zit niet in HTTP. Dat betekent dat als asynchrone messages nodig zijn (en dat is bijna altijd zo), dat moet worden opgelost binnen de resources of althans binnen de server die de resources beheert.
Een gestandaardiseerde abstractielaag bovenop REST, waarbij de URI-structuur in stand blijft, prettig zou zijn. Komt zo dan toch weer WS-* via de achterdeur binnen? Nee, dat is niet de bedoeling. Veel WS-* standaarden hebben op zichzelf nut, alleen: de implementatie is zeer toolgebonden, en erg ondoorzichtig.
Ik vraag me af: zou het mogelijk zijn een Erlang-achtige taal te maken die asynchroniteit inbouwt, en gewoon op HTTP is gebaseerd? Of gaat dat toch weer een lekkende abstractie worden?
Representaties
Kees schrijft over REST representaties:
"Goed, het is dus de inhoud (de data) van het object, in een bepaalde
weergave. In OO-talen kan dat meestal niet in één klap zonder
tussenkomst van methods, want daar vindt men dat een object z'n data
moet afschermen en alleen via methods toegankelijk moet maken. Het is
dus zoiets als de method toString van Java. Klopt dat?"
Min of meer.
Ja, een representatie is een weergave van de resource op een of andere manier. In HTML, met plaatjes, alleen een bepaald deel van de info geselecteerd, een bepaalde volgorde, enzovoort.
En inderdaad schermt het begrip "representatie" de resource af van de buitenwereld. Strikt genomen weet je van een resource niets anders dan welke representaties eruit kunnen komen, en weet je dus ook niets van de binnenkant. (Maar dit is inderdaad wel nogal strikte theorie, omdat een netwerk van resources zelf al een sterke semantiek heeft. Als je niet weet wat een bepaalde resource voorstelt, heeft RESTful werken niet zoveel zin.)
Als je om een representatie vraagt (via de GET), roep je inderdaad een method aan, nl de GET, met eventueel parameters in de URI. Wat dat betreft is de REST-implementatie minstens zo OO als de meeste OO talen.
Te vergelijken met toString? Ja, ik denk het wel. Maar de gemiddelde GET voegt wel veel meer semantiek toe.
"Goed, het is dus de inhoud (de data) van het object, in een bepaalde
weergave. In OO-talen kan dat meestal niet in één klap zonder
tussenkomst van methods, want daar vindt men dat een object z'n data
moet afschermen en alleen via methods toegankelijk moet maken. Het is
dus zoiets als de method toString van Java. Klopt dat?"
Min of meer.
Ja, een representatie is een weergave van de resource op een of andere manier. In HTML, met plaatjes, alleen een bepaald deel van de info geselecteerd, een bepaalde volgorde, enzovoort.
En inderdaad schermt het begrip "representatie" de resource af van de buitenwereld. Strikt genomen weet je van een resource niets anders dan welke representaties eruit kunnen komen, en weet je dus ook niets van de binnenkant. (Maar dit is inderdaad wel nogal strikte theorie, omdat een netwerk van resources zelf al een sterke semantiek heeft. Als je niet weet wat een bepaalde resource voorstelt, heeft RESTful werken niet zoveel zin.)
Als je om een representatie vraagt (via de GET), roep je inderdaad een method aan, nl de GET, met eventueel parameters in de URI. Wat dat betreft is de REST-implementatie minstens zo OO als de meeste OO talen.
Te vergelijken met toString? Ja, ik denk het wel. Maar de gemiddelde GET voegt wel veel meer semantiek toe.
woensdag 9 juli 2008
Fukuyama van de automatisering
In een reactie op het verhaal over REST en OO wordt gezegd dat ik zo de "Francis Fukuyama van de automatisering" word.
:)
dinsdag 8 juli 2008
Representaties
Kees schrijft:
"Wat is een "representation" van een object? Werkt het als een referentie naar dat object, kun je het bijvoorbeeld op die manier veranderen, of is het alleen data en niet het object zelf?"
Goede vraag. Het begrip "representation" binnen REST is inderdaad wat schimmig. Het is een view op een object, maw: een set gegevens, in een bepaalde formattering. Een weergave van iets in HTML is een representatie, de verzameling van orders gesorteerd op datum ook, enzovoort.
In feite is het begrip "representation" de afscherming van de inhoud van een object binnen de context van REST. Informatie vraag je aan een resource via de GET, en wat je krijgt is (per definitie) een representation.
De representation is dus alleen data, en niet het object/resource zelf. Daarvan, of althans: van de resource, heb je de URI. Je kunt de URI kopieren, maar niet de resource zelf.
Het is ook goed om in de gaten te houden dat de begrippen "object", "message", "reference", enzovoort eigenlijk vreemd zijn aan REST. Daar gaat het over "resources", "representations", "URIs". Je kunt (zie eerdere post) wel een zinnige projectie van de OO-begrippen naar de REST-begrippen maken, maar daarmee wordt het nog niet hetzelfde.
Wel denk ik dat het zinnig is de begrippensets wat beter op elkaar te laten passen. Bijvoorbeeld: in REST gebruik je de URI zowel voor resource-identificatie als voor (in OO-termen) parameter passing. Dat kan, het heeft voordelen, maar het zijn voor elk zinnig mens wel verschillende dingen. (Het is ook wel grappig om te zien in welke bochten de REST-puristen zich wringen om deze twee dingen in essentie toch wel hetzelfde te laten zijn.) Het zou helpen als er een duidelijke conventie of desnoods standaard was welk deel van de URI locatie is, en welk deel parameter passing.
"Wat is een "representation" van een object? Werkt het als een referentie naar dat object, kun je het bijvoorbeeld op die manier veranderen, of is het alleen data en niet het object zelf?"
Goede vraag. Het begrip "representation" binnen REST is inderdaad wat schimmig. Het is een view op een object, maw: een set gegevens, in een bepaalde formattering. Een weergave van iets in HTML is een representatie, de verzameling van orders gesorteerd op datum ook, enzovoort.
In feite is het begrip "representation" de afscherming van de inhoud van een object binnen de context van REST. Informatie vraag je aan een resource via de GET, en wat je krijgt is (per definitie) een representation.
De representation is dus alleen data, en niet het object/resource zelf. Daarvan, of althans: van de resource, heb je de URI. Je kunt de URI kopieren, maar niet de resource zelf.
Het is ook goed om in de gaten te houden dat de begrippen "object", "message", "reference", enzovoort eigenlijk vreemd zijn aan REST. Daar gaat het over "resources", "representations", "URIs". Je kunt (zie eerdere post) wel een zinnige projectie van de OO-begrippen naar de REST-begrippen maken, maar daarmee wordt het nog niet hetzelfde.
Wel denk ik dat het zinnig is de begrippensets wat beter op elkaar te laten passen. Bijvoorbeeld: in REST gebruik je de URI zowel voor resource-identificatie als voor (in OO-termen) parameter passing. Dat kan, het heeft voordelen, maar het zijn voor elk zinnig mens wel verschillende dingen. (Het is ook wel grappig om te zien in welke bochten de REST-puristen zich wringen om deze twee dingen in essentie toch wel hetzelfde te laten zijn.) Het zou helpen als er een duidelijke conventie of desnoods standaard was welk deel van de URI locatie is, en welk deel parameter passing.
vrijdag 4 juli 2008
Ik rest mijn case
In de zgn. REST-SOA-discussie lopen allerlei vragen door elkaar heen: hoe makkelijk moet een protocol zijn? hoe erg is het om ingewikkelde tools, zoals ESBs, nodig te hebben? heb je bijvoorbeeld transaction awareness nodig? enzovoort.
Dat zijn allemaal interessante en ook relevante vragen, maar ik denk dat het toch vooral om iets anders gaat, namelijk de manier waarop je objecten (en daarmee semantische modellen) kunt gebruiken op het Web.
Toen zo'n 20 jaar geleden OO doorbrak, werd hoog opgegeven van de voordelen: je maakte een model in objecten van het relevante domein, je implementeerde dat in een daartoe geëigende omgeving, en het werkte. Schaalbaarheid, onderhoudbaarheid, en wat niet al waren je deel.
En dat kon dankzij het feit dat goed ontworpen objecten een unieke identiteit hadden en vindbaar waren op een unieke lokatie, ze stelden functionaliteit beschikbaar via een interface, en de interne implementatie en gegevens waren afgeschermd van de buitenwereld. Objecten waren eigenlijk zelfstandige entiteiten die elkaar kennen en met elkaar samenwerken.
Natuurlijk bleek de werkelijkheid wat prozaïscher, en kon er erg veel misgaan. Maar desondanks: als eea goed werd aangepakt, konden de beloften worden ingelost. Althans: binnen de run-time omgeving van een OO-omgeving, bijvoorbeeld een SmallTalk-image. En dus: eigenlijk slechts binnen het geheugen van een applicatie en zolangs als die applicatie loopt.
Persistentie en distributie verstoorden dus de OO-droom, en maakten het nodig om ingewikkelde oplosssinngen te bedenken, waarmee verzekerd werd dat objecten bewaard en geditribueerd konden worden, en wel op een "transparante" wijze. En dus werd er heel wat afgemapt.
Het persistentie-probleem is min of meer opgelost. Er kwamen OO-databases die het applicatiegeheugen en de "echte" database naadloos ("transparant", jazeker) in elkaar over lieten lopen. Erg mooi, en vrijwel niemand gebruikte het. Maar ook de wat meer aardse oplossing via een ORM (object relational mapping) bleek na wat vijven en zessen goed werkend te krijgen.
Het distributie-probleem bleek persistenter. :) Hoe moest de "ruimte" van objecten in één applicatie op één machine worden uitgebreid naar andere ruimtes van andere applicaties op andere machines? Met andere woorden: hoe maken we van al die ruimtes één grote ruimte?
De meest voor de hand liggende oplossingsrichting was: maak bovenop het netwerk een protocol wat ervoor zorgt dat objecten war dan ook elkaar kunnen kennen en direct boodschappen sturen. Java RMI is van deze route een voorbeeld.
Dat werkte, althans tot op zekere hoogte. Binnen een closely-knitted LAN was het netwerk stabiel genoeg om van het netwerk te kunnen abstraheren. Maar daarbuiten bleek dat een fictie: het netwerk was niet stabiel genoeg, en dan kun je het ook niet transparant maken. Bovendien waren de RMI-objecten niet echt persistent, omdat ze in feite afhankelijk waren van de applicatie waarbinnen ze bestonden. En tenslotte was de bovenop het netwerk vereiste laag dusdanig ingewikkeld dat het nooit een algemene standaard kon worden. En dat is ook niet gebeurd: RMI kun je alleen binnen de Java-architectuur gebruiken, en die is niet universeel.
Men kon er niet onderuit: het was niet mogelijk om een werkend object-netwerk te maken volledig geabstraheerd van het netwerk. Dus werd het begrip "component" (opnieuw) ingevoerd. Componenten waren entiteiten die op het netwerk draaiden, en als zodanig bekend waren, en via een functioneel interface aangeroepen konden worden.
Maar hoe verhielden de componenten zich tot de objecten?
Een eerste schot was: laat elk object, althans elk zelfstandig domeinobject, een component zijn. Maar er zijn verschrikkelijk veel domeinobjecten. Die allemaal een echte zelfstandige component maken zou veel te veel resources vergen. Immers, de functionaliteit die nodig is om iets een zelfstandige, vindbare, persistente eintiteit op een netwerk (een component dus) te maken, is fors.Dus moest er een oplossing worden bedacht waarin de object-componenten weliswaar algemeen bekend en bereikbaar waren, maar voor de standaard-component functionaliteit gebruik maakten van een soort component voedingsbodem.
De J2EE-EntityBeans waren een poging in deze richting, maar al ras bleek dat zelfs in deze aanpak veel te veel componenten ontstonden om een acceptabele performance te halen. Bovendien konden J2EE-componenten alleen goed met J2EE-componenten praten, dus van een universele ruimte was sowieso geen sprake. En vergelijkbare nadelen golden voor andere pogingen in deze richting zoals COM/DCOM.
Goed, objecten konden dus niet allemaal componenten worden. Dan maar een hybride benadering: we hebben componenten, en daarbinnen leven objecten. En we gaan een standaard ontwikkelen volgens welke componenten met elkaar, in via die route gedistribueerde objecten met elkaar, kunnen praten. En dat niet gebonden aan één talomgeving (zoals bij RMI). Dat was Corba.
Ingewikkeld? Ja, en ook nog eens slechts een standaard, nog geen implementatie. En je had er meestal dure en in ieder geval moeilijk te begrijpen tools voor nodig.
Een andere variant was: laten we het niet te ingewikkeld maken. We zien de componenten gewoon als objecten (ze hebben tenslotte al een unieke lokatie, en een interface met mooie functies, en we proberen zo'n beetje de OO-ontwerp principes voor het ontwerp van die componenten te gebruiken. Daar is weinig op tegen, en als er goede standaarden zijn of komen voor de communicatie tussen de componenten, dan heeft dit een goede kans van slagen. O ja, en heel belangrijk: we noemen het anders, dan lijkt het nieuw.
Ziedaar SOA, en dankzij XML, SOAP en de WS-* standaarden is het inderdaad een behoorlijk succes. En dankzij het Web en HTTP is de ruimte van componenten nu ook universeel.
Maar het lost het oorspronkelijke probleem niet op. Want SOA-services of -componenten zijn geen domeinobjecten, al lijken ze er een beetje op. Eigenlijk zijn we weer terug bij af: we hebben componenten (services) die elkaar kunnen vinden en met elkaar kunnen praten. Objecten bestaan wel, maar zitten binnenin de componenten. En als ee object een boodschap wil sturen aan een object in een andere component, moet eerst worden uitgezocht waar het doelobject zich eigenlijk bevindt, moet de boodschap vervolgens worden vertaald naar een serviceaanroep, moet daarbij worden aangegeven voor welk object de boodschap eigenlijk is bedoeld, en kan daarna de service-aanroep worden gedaan. En aan de andere kant moet de booschap dan weer worden uitgepakt en ontcijferd, en worden doorgestuurd naar het doelobject. Het kan wel, maar het is erg omslachtig. (Al is dat bij gebruik van MDD-technieken midner bezwaarlijk.)
Stand van zaken: we hebben eindelijk een universele ruimte, maar alleen voor componenten. Die gebruiken om echte objecten direct aan elkaar te hangen is niet gelukt, vanwege gebrek aan eenvoud, gebrek aan standaardisatie, en gebrek aan persistentie.
En toen kwam REST.
De resources van REST vormen een universele ruimte, ze zijn (uiteraard) persistent, ze zijn vindbaar en uniek dankzij de URI, het is een bestaande en zeer wijdverbreide standaard (HTTP in feite), en hij is bewezen makkelijk te gebruiken: het hele Web is erop gebaseerd.
Zouden objecten dan te mappen zijn op HTTP-resources?
Op het eerste gezicht is de mapping lastiger dan op RPC-style componenten. Objecten hebben een unieke identificatie ne locatie nodig, en dat biedt de resource inderdaad dankzij de URI. Maar niet elke via een URI te identificeren resource is een echt object, sommige zijn een "representation" van een object, in OO-termen een returnwaarde van een method.
En de REST-methods passen ook niet zonder meer op de methods in een objectmodel. Immers, REST kent slechts een beperkt aantal methods (GET, PUT, POST, DELETE zijn relevant in dit verband). De eerste drie hebben een heel strikte betekenis, en de consequentie is dat extra informatie (parameters in een method van een object) in de URI wordt gestopt. En methods die niet kunnen worden gezien als een GET, PUT of DELETE moeten via POST worden "getruct".
Vanuit OO ziet het er dus op het eerste gezicht niet zo heel goed uit. Maar als je wat beter kijkt, lijkt dat erg mee te vallen. De object-methods uit een goed ontworpen OO-domeinmodel blijken vrijwel alle zonder veel problemen te kunnen worden vertaald naar HTTP-methods.
Maar dan nog steeds: het wringt. HTTP-resources zijn brokken informatie die aan elkaar zij gerelateerd, met verscheidene representaties. Het zijn geen objecten die potentieel een zeer specifiek hebben. Resources hebben juist zoveel mogelijk een standaard-interface.
De claim van REST-voorstanders is dat dat standaard-interface juist een voordeel is. Doordat bijvoorbeeld de betekenis van GET is gedefineerd als: een GET mag een resource niet wijzigen, kunnen HTTP-servers GET-resultaten cachen. En door de simpele method + URI structuur zouden hergerbuikers makkelijker in staat zijn te snappen wat er gebeurt dan als ze bv een WSDL-file moeten lezen voor een SOA-service. Bij REST is de structuur van de resources en de informatie binnen de resources (te verkrijgen als representatie) primair.
In OO is dat van oudsher anders: daar is het functionele interface primair, en de informatie is juist geëncapsuleerd. Althans: volgens de OO-puristen. Als je kijkt naar een goed domeinmodel, dan blijkt dat veel meer een "semantic web" achtig ding te zijn, waarbij het interface helemaal niet zo'n leidende rol speelt.
(Voor de duidelijkheid: voor OO-toepassingen op een ander nivo dan de implementatie van domeinmodellen ligt dat anders, maar die worden ook niet geraakt door deze problematiek.)
En dus is het verschil met de REST/resource-oriented denkwijze helemaal niet zo groot als het op het eerste gezicht lijkt. En het voordeel van REST, namelijk dat je een universele ruimte met dingen (resources, objecten) krijgt, met unieke locaties, met de mogelijkheid daar via een standaard protocol boodschappen aan te sturen, en dat zonder dat je last hebt van het begrip component, dat voordeel is immens.
Is REST dus de toekomst? Ja, ik denk het wel. Maar we moeten nog wel uitzoeken hoe goed die mapping van OO op REST nou echt werkt, en ik denk dat er toch soort REST-standaard bovenop HTTP (bij via een nadere uitwerking van POST) nodig blijkt. Ook al is dat tegen het zere been van de REST-puristen.
Betekent dit dat "gewone SOA" ten dode is opgeschreven? Dat weet ik niet zo zeker. Voor "semantic web" achtige webservices is REST de eerste keus, maar er zijn ook webservices die andere eisen stellen. In de beruchte WS-* stack zitten een aantal zaken (bijvoorbeeld op het gebied van reliability en security) die wat lastig zijn vorm te geven in een REST-context. Het zou kunnen dat we die veel minder vaak nodig hebben dat we nu denken, maar of dat echt waar is moet nog maar blijken.
Maar er zijn zeker een hoop SOA/SOAP-etc interfaces die makkelijk via REST zouden kunnen werken, en ik denk dat we REST-facades bovenop SOA-interfaces gaan zien. Dat zal de migratie ook makkelijker maken.
Dat zijn allemaal interessante en ook relevante vragen, maar ik denk dat het toch vooral om iets anders gaat, namelijk de manier waarop je objecten (en daarmee semantische modellen) kunt gebruiken op het Web.
Toen zo'n 20 jaar geleden OO doorbrak, werd hoog opgegeven van de voordelen: je maakte een model in objecten van het relevante domein, je implementeerde dat in een daartoe geëigende omgeving, en het werkte. Schaalbaarheid, onderhoudbaarheid, en wat niet al waren je deel.
En dat kon dankzij het feit dat goed ontworpen objecten een unieke identiteit hadden en vindbaar waren op een unieke lokatie, ze stelden functionaliteit beschikbaar via een interface, en de interne implementatie en gegevens waren afgeschermd van de buitenwereld. Objecten waren eigenlijk zelfstandige entiteiten die elkaar kennen en met elkaar samenwerken.
Natuurlijk bleek de werkelijkheid wat prozaïscher, en kon er erg veel misgaan. Maar desondanks: als eea goed werd aangepakt, konden de beloften worden ingelost. Althans: binnen de run-time omgeving van een OO-omgeving, bijvoorbeeld een SmallTalk-image. En dus: eigenlijk slechts binnen het geheugen van een applicatie en zolangs als die applicatie loopt.
Persistentie en distributie verstoorden dus de OO-droom, en maakten het nodig om ingewikkelde oplosssinngen te bedenken, waarmee verzekerd werd dat objecten bewaard en geditribueerd konden worden, en wel op een "transparante" wijze. En dus werd er heel wat afgemapt.
Het persistentie-probleem is min of meer opgelost. Er kwamen OO-databases die het applicatiegeheugen en de "echte" database naadloos ("transparant", jazeker) in elkaar over lieten lopen. Erg mooi, en vrijwel niemand gebruikte het. Maar ook de wat meer aardse oplossing via een ORM (object relational mapping) bleek na wat vijven en zessen goed werkend te krijgen.
Het distributie-probleem bleek persistenter. :) Hoe moest de "ruimte" van objecten in één applicatie op één machine worden uitgebreid naar andere ruimtes van andere applicaties op andere machines? Met andere woorden: hoe maken we van al die ruimtes één grote ruimte?
De meest voor de hand liggende oplossingsrichting was: maak bovenop het netwerk een protocol wat ervoor zorgt dat objecten war dan ook elkaar kunnen kennen en direct boodschappen sturen. Java RMI is van deze route een voorbeeld.
Dat werkte, althans tot op zekere hoogte. Binnen een closely-knitted LAN was het netwerk stabiel genoeg om van het netwerk te kunnen abstraheren. Maar daarbuiten bleek dat een fictie: het netwerk was niet stabiel genoeg, en dan kun je het ook niet transparant maken. Bovendien waren de RMI-objecten niet echt persistent, omdat ze in feite afhankelijk waren van de applicatie waarbinnen ze bestonden. En tenslotte was de bovenop het netwerk vereiste laag dusdanig ingewikkeld dat het nooit een algemene standaard kon worden. En dat is ook niet gebeurd: RMI kun je alleen binnen de Java-architectuur gebruiken, en die is niet universeel.
Men kon er niet onderuit: het was niet mogelijk om een werkend object-netwerk te maken volledig geabstraheerd van het netwerk. Dus werd het begrip "component" (opnieuw) ingevoerd. Componenten waren entiteiten die op het netwerk draaiden, en als zodanig bekend waren, en via een functioneel interface aangeroepen konden worden.
Maar hoe verhielden de componenten zich tot de objecten?
Een eerste schot was: laat elk object, althans elk zelfstandig domeinobject, een component zijn. Maar er zijn verschrikkelijk veel domeinobjecten. Die allemaal een echte zelfstandige component maken zou veel te veel resources vergen. Immers, de functionaliteit die nodig is om iets een zelfstandige, vindbare, persistente eintiteit op een netwerk (een component dus) te maken, is fors.Dus moest er een oplossing worden bedacht waarin de object-componenten weliswaar algemeen bekend en bereikbaar waren, maar voor de standaard-component functionaliteit gebruik maakten van een soort component voedingsbodem.
De J2EE-EntityBeans waren een poging in deze richting, maar al ras bleek dat zelfs in deze aanpak veel te veel componenten ontstonden om een acceptabele performance te halen. Bovendien konden J2EE-componenten alleen goed met J2EE-componenten praten, dus van een universele ruimte was sowieso geen sprake. En vergelijkbare nadelen golden voor andere pogingen in deze richting zoals COM/DCOM.
Goed, objecten konden dus niet allemaal componenten worden. Dan maar een hybride benadering: we hebben componenten, en daarbinnen leven objecten. En we gaan een standaard ontwikkelen volgens welke componenten met elkaar, in via die route gedistribueerde objecten met elkaar, kunnen praten. En dat niet gebonden aan één talomgeving (zoals bij RMI). Dat was Corba.
Ingewikkeld? Ja, en ook nog eens slechts een standaard, nog geen implementatie. En je had er meestal dure en in ieder geval moeilijk te begrijpen tools voor nodig.
Een andere variant was: laten we het niet te ingewikkeld maken. We zien de componenten gewoon als objecten (ze hebben tenslotte al een unieke lokatie, en een interface met mooie functies, en we proberen zo'n beetje de OO-ontwerp principes voor het ontwerp van die componenten te gebruiken. Daar is weinig op tegen, en als er goede standaarden zijn of komen voor de communicatie tussen de componenten, dan heeft dit een goede kans van slagen. O ja, en heel belangrijk: we noemen het anders, dan lijkt het nieuw.
Ziedaar SOA, en dankzij XML, SOAP en de WS-* standaarden is het inderdaad een behoorlijk succes. En dankzij het Web en HTTP is de ruimte van componenten nu ook universeel.
Maar het lost het oorspronkelijke probleem niet op. Want SOA-services of -componenten zijn geen domeinobjecten, al lijken ze er een beetje op. Eigenlijk zijn we weer terug bij af: we hebben componenten (services) die elkaar kunnen vinden en met elkaar kunnen praten. Objecten bestaan wel, maar zitten binnenin de componenten. En als ee object een boodschap wil sturen aan een object in een andere component, moet eerst worden uitgezocht waar het doelobject zich eigenlijk bevindt, moet de boodschap vervolgens worden vertaald naar een serviceaanroep, moet daarbij worden aangegeven voor welk object de boodschap eigenlijk is bedoeld, en kan daarna de service-aanroep worden gedaan. En aan de andere kant moet de booschap dan weer worden uitgepakt en ontcijferd, en worden doorgestuurd naar het doelobject. Het kan wel, maar het is erg omslachtig. (Al is dat bij gebruik van MDD-technieken midner bezwaarlijk.)
Stand van zaken: we hebben eindelijk een universele ruimte, maar alleen voor componenten. Die gebruiken om echte objecten direct aan elkaar te hangen is niet gelukt, vanwege gebrek aan eenvoud, gebrek aan standaardisatie, en gebrek aan persistentie.
En toen kwam REST.
De resources van REST vormen een universele ruimte, ze zijn (uiteraard) persistent, ze zijn vindbaar en uniek dankzij de URI, het is een bestaande en zeer wijdverbreide standaard (HTTP in feite), en hij is bewezen makkelijk te gebruiken: het hele Web is erop gebaseerd.
Zouden objecten dan te mappen zijn op HTTP-resources?
Op het eerste gezicht is de mapping lastiger dan op RPC-style componenten. Objecten hebben een unieke identificatie ne locatie nodig, en dat biedt de resource inderdaad dankzij de URI. Maar niet elke via een URI te identificeren resource is een echt object, sommige zijn een "representation" van een object, in OO-termen een returnwaarde van een method.
En de REST-methods passen ook niet zonder meer op de methods in een objectmodel. Immers, REST kent slechts een beperkt aantal methods (GET, PUT, POST, DELETE zijn relevant in dit verband). De eerste drie hebben een heel strikte betekenis, en de consequentie is dat extra informatie (parameters in een method van een object) in de URI wordt gestopt. En methods die niet kunnen worden gezien als een GET, PUT of DELETE moeten via POST worden "getruct".
Vanuit OO ziet het er dus op het eerste gezicht niet zo heel goed uit. Maar als je wat beter kijkt, lijkt dat erg mee te vallen. De object-methods uit een goed ontworpen OO-domeinmodel blijken vrijwel alle zonder veel problemen te kunnen worden vertaald naar HTTP-methods.
Maar dan nog steeds: het wringt. HTTP-resources zijn brokken informatie die aan elkaar zij gerelateerd, met verscheidene representaties. Het zijn geen objecten die potentieel een zeer specifiek hebben. Resources hebben juist zoveel mogelijk een standaard-interface.
De claim van REST-voorstanders is dat dat standaard-interface juist een voordeel is. Doordat bijvoorbeeld de betekenis van GET is gedefineerd als: een GET mag een resource niet wijzigen, kunnen HTTP-servers GET-resultaten cachen. En door de simpele method + URI structuur zouden hergerbuikers makkelijker in staat zijn te snappen wat er gebeurt dan als ze bv een WSDL-file moeten lezen voor een SOA-service. Bij REST is de structuur van de resources en de informatie binnen de resources (te verkrijgen als representatie) primair.
In OO is dat van oudsher anders: daar is het functionele interface primair, en de informatie is juist geëncapsuleerd. Althans: volgens de OO-puristen. Als je kijkt naar een goed domeinmodel, dan blijkt dat veel meer een "semantic web" achtig ding te zijn, waarbij het interface helemaal niet zo'n leidende rol speelt.
(Voor de duidelijkheid: voor OO-toepassingen op een ander nivo dan de implementatie van domeinmodellen ligt dat anders, maar die worden ook niet geraakt door deze problematiek.)
En dus is het verschil met de REST/resource-oriented denkwijze helemaal niet zo groot als het op het eerste gezicht lijkt. En het voordeel van REST, namelijk dat je een universele ruimte met dingen (resources, objecten) krijgt, met unieke locaties, met de mogelijkheid daar via een standaard protocol boodschappen aan te sturen, en dat zonder dat je last hebt van het begrip component, dat voordeel is immens.
Is REST dus de toekomst? Ja, ik denk het wel. Maar we moeten nog wel uitzoeken hoe goed die mapping van OO op REST nou echt werkt, en ik denk dat er toch soort REST-standaard bovenop HTTP (bij via een nadere uitwerking van POST) nodig blijkt. Ook al is dat tegen het zere been van de REST-puristen.
Betekent dit dat "gewone SOA" ten dode is opgeschreven? Dat weet ik niet zo zeker. Voor "semantic web" achtige webservices is REST de eerste keus, maar er zijn ook webservices die andere eisen stellen. In de beruchte WS-* stack zitten een aantal zaken (bijvoorbeeld op het gebied van reliability en security) die wat lastig zijn vorm te geven in een REST-context. Het zou kunnen dat we die veel minder vaak nodig hebben dat we nu denken, maar of dat echt waar is moet nog maar blijken.
Maar er zijn zeker een hoop SOA/SOAP-etc interfaces die makkelijk via REST zouden kunnen werken, en ik denk dat we REST-facades bovenop SOA-interfaces gaan zien. Dat zal de migratie ook makkelijker maken.
woensdag 2 juli 2008
10 redenen om niet in cloud computing te gaan
Stacey Higginbotham geeft 10 bezwaren voor grote bedrijven om wantrouwend te zijn tov cloud computing. Ik zal ze hieronder groeperen.
1. Juridisch: security, compliance, juridische issues. Zijn de data wel veilig, waar zijn ze opgeslagen, mag dat wel, etc.
Dit zijn natuurlijk reële bezwaren, al heb ik de indruk dat ze oplosbaar zijn. Er zijn legio bedrijven die van cloud computing en SaaS gebruik maken, zonder dat de accountant, de rechter of Tjibbe Joustra een spaak in het wiel steekt. Bovendien heeft iedere mogelijke klant dezelfde vragen, en hebben de serieuzere aanbieders hier dan ook antwoorden op.
2. Technisch: betrouwbaarheid, performance.
Performance kan inderdaad een punt zijn. De latency van de cloud is hoger dan van lokale servers, dat kan niet anders. Of dat voor administratieve toepassingen een groot bezwaar is betwijfel ik, maar het punt blijft.
Betrouwbaarheid: de outage van AWS wordt steeds weer als voorbeeld gegeven, maar redelijkerwijs moet dan ook worden gekeken naar de downtime van "eigen" systemen. Is de cloud in dit opzicht minder betrouwbaar? Ik denk dat de meeste cloudservices een betrouwbaarheid halen die tenminste vergelijkbaar is met de eigen systemen.
Iets anders is de betrouwbaarheid van het netwerk. Dat is wel een bottleneck. Gedeeltelijk is dit te ondervangen door "dual carrier" te gaan, dat wil zeggen: twee zo verschillend mogelijke netwerken te gebruiken voor de verbinding met het internet. Het is opvallend dat nog zo weinig bedrijven deze voor de hand liggende voorziening gebruiken.
Maar dan nog steeds: het haalt niet alle risico's weg. Als men de cloud gaat gebruiken, moet men dan ook goed inschatten hoe lang men de cloudservice kan missen, en hoe betrouwbaar het netwerk is. Een optie is natuurlijk lokale caching (een eigen noodaggregaat als hetware), maar dat kost uiteraard geld en resources, en haalt dus een deel van het voordeel van cloud computing weg.
3. Platform en integratie: cloudplatforms zijn onderling niet zonder meer compatibel, data kunnen niet zonder meer van het ene naar het andere platform worden gebracht, enzovoort. kortom: lockin.
Dit is zeker een probleem. Hoe groot hangt af van de omvang en diversiteit van de "ecosystemen", maar het is zeker een zorg.
Er zijn wel oplossingen voor, bijvoorbeeld door een cloud platform onafhankelijk business model te gebruiken. Dat kan vervolgens worden geprojecteerd op verscheidene platforms of services. Daarmee is een data-conversie automatisch beschreven, en zijn ook de service-mismatches makkelijk te overzien. Maar het blijft makkelijker om binnen één ecosysteem te blijven.
En dan een paar rare argumenten:
4. clouds slurpen energie. Een vreemd bezwaar. Ja, datacenters vreten energie, maar ze besparen ook veel energie. De claim to fame van cloudcomputing is een grotere efficientie als het om PU-cycles en HDs gaat, en het is aannemelijk dat dat ook betekent dat ze energie-efficienter zijn. Maar in hoeverre dat zo is, is onduidelijk. En daarbij: het transport kost ook energie.
Hoe de balans is, is moeilijk te zeggen. Stacey H. verwijst naar een artikel in The Economist, maar in dat artikel wordt niets anders gezegd dan dat datacenters veel energie gebruiken. Hoe dat gebruik zich verhudt tot de besparing blijft onbesproken.
5. grote bedrijven hebben al een eigen cloud.
Als dat zo is, en ze zijn even goedkoop als externe clouds, dan moeten ze daar vooral mee doorgaan. (Al vraag ik me af of er veel bedrijven zijn met een efficiente eigen cloud.) Wel gelden voor die eigen clouds natuurlijk grotendeels dezelfde bezwaren als voor de externe clouds: betrouwbaarheid, performance, etc.
6. grote bedrijven beslissen traag, hebben een enorme bureaucratie, en de IT afdeling ligt dwars.
Ongetwijfeld, al is dit meer de vaststelling van een feit dan een bezwaar tegen cloud computing.
Het rare van het lijstje van Stacey H. is dat rijp (echte bezwaren en risico's, zoals betrouwbaarheid en platform lockin) op dezelfde lijn staan als gelegenheidsargumenten (ze slurpen energie) en onzinargumenten (IT is ertegen).
Het lijkt mij toch dat juist door al deze bezwaren, het eerste grote bedrijf in een bepaalde sector dat erin slaagt cloud computing voor zich te laten werken, waarschijnlijk een enorme voorsprong pakt op zijn concurrenten.
Eerder een reden voor de aanval dan voor de verdediging, zou je zeggen.
1. Juridisch: security, compliance, juridische issues. Zijn de data wel veilig, waar zijn ze opgeslagen, mag dat wel, etc.
Dit zijn natuurlijk reële bezwaren, al heb ik de indruk dat ze oplosbaar zijn. Er zijn legio bedrijven die van cloud computing en SaaS gebruik maken, zonder dat de accountant, de rechter of Tjibbe Joustra een spaak in het wiel steekt. Bovendien heeft iedere mogelijke klant dezelfde vragen, en hebben de serieuzere aanbieders hier dan ook antwoorden op.
2. Technisch: betrouwbaarheid, performance.
Performance kan inderdaad een punt zijn. De latency van de cloud is hoger dan van lokale servers, dat kan niet anders. Of dat voor administratieve toepassingen een groot bezwaar is betwijfel ik, maar het punt blijft.
Betrouwbaarheid: de outage van AWS wordt steeds weer als voorbeeld gegeven, maar redelijkerwijs moet dan ook worden gekeken naar de downtime van "eigen" systemen. Is de cloud in dit opzicht minder betrouwbaar? Ik denk dat de meeste cloudservices een betrouwbaarheid halen die tenminste vergelijkbaar is met de eigen systemen.
Iets anders is de betrouwbaarheid van het netwerk. Dat is wel een bottleneck. Gedeeltelijk is dit te ondervangen door "dual carrier" te gaan, dat wil zeggen: twee zo verschillend mogelijke netwerken te gebruiken voor de verbinding met het internet. Het is opvallend dat nog zo weinig bedrijven deze voor de hand liggende voorziening gebruiken.
Maar dan nog steeds: het haalt niet alle risico's weg. Als men de cloud gaat gebruiken, moet men dan ook goed inschatten hoe lang men de cloudservice kan missen, en hoe betrouwbaar het netwerk is. Een optie is natuurlijk lokale caching (een eigen noodaggregaat als hetware), maar dat kost uiteraard geld en resources, en haalt dus een deel van het voordeel van cloud computing weg.
3. Platform en integratie: cloudplatforms zijn onderling niet zonder meer compatibel, data kunnen niet zonder meer van het ene naar het andere platform worden gebracht, enzovoort. kortom: lockin.
Dit is zeker een probleem. Hoe groot hangt af van de omvang en diversiteit van de "ecosystemen", maar het is zeker een zorg.
Er zijn wel oplossingen voor, bijvoorbeeld door een cloud platform onafhankelijk business model te gebruiken. Dat kan vervolgens worden geprojecteerd op verscheidene platforms of services. Daarmee is een data-conversie automatisch beschreven, en zijn ook de service-mismatches makkelijk te overzien. Maar het blijft makkelijker om binnen één ecosysteem te blijven.
En dan een paar rare argumenten:
4. clouds slurpen energie. Een vreemd bezwaar. Ja, datacenters vreten energie, maar ze besparen ook veel energie. De claim to fame van cloudcomputing is een grotere efficientie als het om PU-cycles en HDs gaat, en het is aannemelijk dat dat ook betekent dat ze energie-efficienter zijn. Maar in hoeverre dat zo is, is onduidelijk. En daarbij: het transport kost ook energie.
Hoe de balans is, is moeilijk te zeggen. Stacey H. verwijst naar een artikel in The Economist, maar in dat artikel wordt niets anders gezegd dan dat datacenters veel energie gebruiken. Hoe dat gebruik zich verhudt tot de besparing blijft onbesproken.
5. grote bedrijven hebben al een eigen cloud.
Als dat zo is, en ze zijn even goedkoop als externe clouds, dan moeten ze daar vooral mee doorgaan. (Al vraag ik me af of er veel bedrijven zijn met een efficiente eigen cloud.) Wel gelden voor die eigen clouds natuurlijk grotendeels dezelfde bezwaren als voor de externe clouds: betrouwbaarheid, performance, etc.
6. grote bedrijven beslissen traag, hebben een enorme bureaucratie, en de IT afdeling ligt dwars.
Ongetwijfeld, al is dit meer de vaststelling van een feit dan een bezwaar tegen cloud computing.
Het rare van het lijstje van Stacey H. is dat rijp (echte bezwaren en risico's, zoals betrouwbaarheid en platform lockin) op dezelfde lijn staan als gelegenheidsargumenten (ze slurpen energie) en onzinargumenten (IT is ertegen).
Het lijkt mij toch dat juist door al deze bezwaren, het eerste grote bedrijf in een bepaalde sector dat erin slaagt cloud computing voor zich te laten werken, waarschijnlijk een enorme voorsprong pakt op zijn concurrenten.
Eerder een reden voor de aanval dan voor de verdediging, zou je zeggen.
SaaS en ERP
Vorige week reageerde Rik op mijn post over Ecosystemen als volgt:
"Je stelling over eco-systemen en integratie services (integratie out-of-the-box) kan alleen werken als bedrijven (afnemers van IT) zich conformeren aan best practices en standaard processen. En laat dat nu juist het terrein zijn waar de SAP-en van dienst groot zijn geworden!
Indien wat jij stelt juist is, is dat niet bepaald een argument voor het verdwijnen van de standaard pakketten waarmee organisaties deze dagen zijn vergeven. Waarom een orderverkingsproces van SAP vervangen door iets SaaS-erigs als dit prima werkt in SAP? Vanwege de kosten? Voor m.n. grote organisaties lijkt me dit nog onvoldoende argument."
Rik heeft natuurlijk volkomen gelijk als hij zegt dat ERP-pakket-leveranciers als SAP en verkopers van SaaS-functionaliteit op ERP-gebied te vergelijken zijn. De functionaliteit is hetzelfde, het verschil zit in de leveringsvorm en in het business-model.
Waarom zou een bedrijf willen overstappen van een pakket naar een SaaS-oplossing, als de functionaliteit toch ongeveer hetzelfde is?
Het belangrijkste argument: prijs. SaaS is in potentie veel geodkoper. Het gaat daarbij niet alleen om de kosten van de services vs. de kosten van de licentie, maar ook om de bijkomende kosten van on-premise computing: hardware, beheer, stroom, etc, etc.
Voor een bedrijf dat al een ERP-oplossing heeft draaien, zal dit niet onmiddellijk interessant zijn. Immers, een groot deel van de kosten van het pakket zijn al gemaakt, en overschakelen naar een SaaS-oplossing kost ook weer geld en energie.
Maar dat is anders voor bedrijven die nog niet een ERP systeem hebben (in het MKB bv), en bedrijven die voor een grote upgrade of vervanging van hun huidige ERP-pakket staan. Dan wordt SaaS wel een serieus alternatief.
Daar komt nog iets bij.
Waarom zijn grote bedrijven groot? Vooral mdat ze schaalvoordelen hebben. Een van de belangrijkste is dat een groot bedrijf zich inderdaad een SAP-implementatie kan veroorloven, en daarmee allerlei efficiency-effecten kan bereiken die voor kleinere concurrenten niet zijn weggelegd.
Maar als een SaaS-oplossing voor veel minder geld, veel minder risico en meer flexibiliteit vrijwel dezelfde functionaliteit levert, is dat voordeel weg. Er zal voor de grotere bedrijven opeens een reeks van (veel) kleinere concurrenten ontstaan, die vergelijkbare produkten en diensten leveren tegen een lagere prijs.
Als dat gebeurt, zullen veel bedrijven moeten kiezen: het model van hun nieuwe concurrenten overnemen (zelfde kostenstructuur, zelfde SaaS-oplossingen), of de extra mogelijkheden van het bestaande ERP-systeem uitnutten, en zodoende een voorsprong op de nieuwe concurrenten scheppen.
In het eerste geval zie je de ERP-functionaliteit als een commodity. Standaard, bij gelijke lwaliteit zo goedkoop mogelijk inkopen. In het tweede geval zie je in de ERP-toepassing iets wat een strategisch voordeel kan bieden.
Maar ik vraag me af of dat laatste vaak gaat lukken, zeker met een standaardpakket. Ik denk dat ERP-functionaliteit een commodity is of wordt, en dan komt het neer op de goedkoopste oplossing. En dat zal SaaS blijken te zijn.
"Je stelling over eco-systemen en integratie services (integratie out-of-the-box) kan alleen werken als bedrijven (afnemers van IT) zich conformeren aan best practices en standaard processen. En laat dat nu juist het terrein zijn waar de SAP-en van dienst groot zijn geworden!
Indien wat jij stelt juist is, is dat niet bepaald een argument voor het verdwijnen van de standaard pakketten waarmee organisaties deze dagen zijn vergeven. Waarom een orderverkingsproces van SAP vervangen door iets SaaS-erigs als dit prima werkt in SAP? Vanwege de kosten? Voor m.n. grote organisaties lijkt me dit nog onvoldoende argument."
Rik heeft natuurlijk volkomen gelijk als hij zegt dat ERP-pakket-leveranciers als SAP en verkopers van SaaS-functionaliteit op ERP-gebied te vergelijken zijn. De functionaliteit is hetzelfde, het verschil zit in de leveringsvorm en in het business-model.
Waarom zou een bedrijf willen overstappen van een pakket naar een SaaS-oplossing, als de functionaliteit toch ongeveer hetzelfde is?
Het belangrijkste argument: prijs. SaaS is in potentie veel geodkoper. Het gaat daarbij niet alleen om de kosten van de services vs. de kosten van de licentie, maar ook om de bijkomende kosten van on-premise computing: hardware, beheer, stroom, etc, etc.
Voor een bedrijf dat al een ERP-oplossing heeft draaien, zal dit niet onmiddellijk interessant zijn. Immers, een groot deel van de kosten van het pakket zijn al gemaakt, en overschakelen naar een SaaS-oplossing kost ook weer geld en energie.
Maar dat is anders voor bedrijven die nog niet een ERP systeem hebben (in het MKB bv), en bedrijven die voor een grote upgrade of vervanging van hun huidige ERP-pakket staan. Dan wordt SaaS wel een serieus alternatief.
Daar komt nog iets bij.
Waarom zijn grote bedrijven groot? Vooral mdat ze schaalvoordelen hebben. Een van de belangrijkste is dat een groot bedrijf zich inderdaad een SAP-implementatie kan veroorloven, en daarmee allerlei efficiency-effecten kan bereiken die voor kleinere concurrenten niet zijn weggelegd.
Maar als een SaaS-oplossing voor veel minder geld, veel minder risico en meer flexibiliteit vrijwel dezelfde functionaliteit levert, is dat voordeel weg. Er zal voor de grotere bedrijven opeens een reeks van (veel) kleinere concurrenten ontstaan, die vergelijkbare produkten en diensten leveren tegen een lagere prijs.
Als dat gebeurt, zullen veel bedrijven moeten kiezen: het model van hun nieuwe concurrenten overnemen (zelfde kostenstructuur, zelfde SaaS-oplossingen), of de extra mogelijkheden van het bestaande ERP-systeem uitnutten, en zodoende een voorsprong op de nieuwe concurrenten scheppen.
In het eerste geval zie je de ERP-functionaliteit als een commodity. Standaard, bij gelijke lwaliteit zo goedkoop mogelijk inkopen. In het tweede geval zie je in de ERP-toepassing iets wat een strategisch voordeel kan bieden.
Maar ik vraag me af of dat laatste vaak gaat lukken, zeker met een standaardpakket. Ik denk dat ERP-functionaliteit een commodity is of wordt, en dan komt het neer op de goedkoopste oplossing. En dat zal SaaS blijken te zijn.
Abonneren op:
Posts (Atom)