Afgelopen weken kromden mijn tenen zich weer eens over de contentmarketing die als opinie gebracht werd. De gebruikelijke gouden bergen werden weer beloofd met zoiets abstracts als cloud computing. Voordat ik Henri Koppen weer in mijn nek heb, ik geloof best wel in cloud computing alleen niet als de Haarlemmerolie voor alle problemen omdat het enkel techniek is, meer een delivery model dan een oplossing.
Stellen dat cloud computing organisaties lean maakt is onzin want cloud computing is alleen maar de evolutie van Enterprise computing, het delivery model dat antwoord moest geven op een behoefte die ontstaan was met het idee van de service oriented architecture. Cloud evangelisten blijken opmerkelijk vaan een liefde te hebben voor het vergiftigde idee van soa wat organisaties dus verre van lean maakt doordat alle ongestructureerde en verspreid liggende data bedrijfsprocessen dus juist stroperig maakt.
Vaarwel soa
In elk geval is met de introductie van het soa idee de liefde tussen de business en it-afdeling behoorlijk bekoeld. Dat mede omdat er een ‘flawness’ in het service georiënteerde denken zit doordat soa het bestaan van data negeert. En verder richt het zich misschien wel op het hergebruik van software maar dus op het hergebruik van resources. Hierdoor kregen organisaties niet alleen steeds meer data maar ook rekken vol met servers die mede door de wet van Moore wel krachtiger werden maar dus niet beter benut. Cloudpredikers die beheerders voor server knuffelaars uitmaken hebben ook niet zoveel van data management begrepen. Maar Moore stelde dan ook dat it een gigantische industrietak is geworden die je niet zomaar vervangt. En met de wildgroei aan ‘-aaS’ termen lijken de wolven inderdaad wel hun haren te verliezen maar niet hun streken.
Tenslotte was de service delivery nimmer het probleem, de uitdaging zat al vanaf het begin in het beheer van alle data en de vele koppelvlakken. Met laatste bedoel ik niet de logische die door Enterprise Architecten in architectuur platen vastgelegd worden maar dus alle ongedocumenteerde connecties. Ik zal vast een geheim vertellen door te zeggen dat Internet zeker geen Enterprise Service Bus is. Zeker bij publieke oplossingen ligt er dan ook een uitdaging in de beveiliging van informatie. En wie bij cloud computing nog vasthoudt aan het idee van soa heeft gewoon een nieuwe trend gemist, de information oriented architecture.
Hallo Alice in wonderland
Zoals ik al aangaf in de introductie geloof ik in cloud computing maar dan alleen op basis van de principes als delivery model. Dat geloof komt voort uit het simpele feit dat het allemaal niet zo revolutionair is als de industrie ons wil doen geloven. Want als ik me niet vergis vulden we met Enterprise Computing al veel van de geldende principes van cloud computing in:
1.Lage initiële kosten om te implementeren (standaardisatie)
2.Meerkosten in rekening brengen als belasting groeit (kostenmodel)
3.Een geautomatiseerde implementatie (job scheduler)
4.Het beheer ingebouwd met daarbij:
a. Zelfbediening (rollen)
b. Best Practices (referenties)
5.Hergebruik (lifecycles)
Cloud computing voegt met virtualisatie dus alleen gedeeld resource gebruik toe en maakt van het netwerk de backplane voor de horizontale schaalbaarheid. Aangezien we dat netwerk na introductie van Windows NT 4.0 al voor unintended install clustering gebruikten weten we dus al een tijdje waar de bottleneck ligt. In Enterprise omgevingen gebruikten we daarom lokale distributiepunten welk principe dus ook in de cloud gebruikt wordt.
Kortom, cloud computing op zich zelf maakt een organisatie niet lean, want dat zijn de processen welke, zoals Theory of Contraints stelt, erop gericht moeten zijn om de bottlenecks weg te nemen. En bij de publieke cloudoplossingen voeg je naar mijn opinie er dus juist één toe in de vorm van het netwerk.
Van grottekening naar infographic
Bij de publieke cloudoplossingen is het ook moeilijk om te bepalen waarvoor je betaalt en wat je uiteindelijk krijgt. Aangezien veel providers met vaste kostenmodellen werken is het goed om ook eens naar punt 1 en 5 te kijken. Tenslotte werken veel providers met vaste prijzen in hun kostenmodellen en een nieuwe prijs voor een tweedehands server is dus vooral goed voor de marges van aanbieders. Verder hebben veel virtuele servers de specificaties van een eenvoudige pc waardoor beweringen over te behalen kostenreducties nogal factfree zijn.
Nu roepen cloudevangelisten dat het bezit van servers achterhaald waar ik wel mee kan instemmen, vaak was de business unit de eigenaar. Maar zoals ik al gezegd had negeert soa het bestaan van data welke juridisch geen heldere status heeft en waarvan veiligstellen meestal ten laste komt van de it-afdeling. Tel daarbij op dat organisaties door de wet aan het ‘verkeerstorenmodel’ gebonden zijn voor wat betreft de bedrijfsinformatie. Want het ging nimmer niet om de lifecycle van services maar dus om de informatie en -drager. En cloud computing kan als deliverymodel alleen maar een middel want de sleutel tot succes zit in een geïntegreerde vorm van it-servicemanagement voor met name capaciteitsmanagement van de business services.
Bedrijfsprocessen steeds stroperiger
Helaas weet de business dus meestal geen goede forecast te maken waardoor de roi van veel oplossingen gewoon natte vingerwerk is. Bedrijfsprocessen worden tenslotte steeds stroperiger door de toenemende volumes aan ongestructureerde en verspreid liggende data. Maar ik had meen ik al wat gezegd over de onveranderlijke it-industrie.
Betreffende een eerdere uitspraak van wederom Henri Koppen dat marketing met cloud computing op jacht kan gaan wil ik er op wijzen dat succesvolle jagers de buit meestal weer terug naar de grot sleepten. Minder succesvolle jagers werden voer voor de wilde beesten en zo is het natuurlijk ook met cloud computing waarvan dynamiek je ook tegen kan werken.
Sorry Ewout, dat je geen cloud- en soa-fan bent maak je goed duidelijk. Maar de onderbouwing blijft wat mij betreft warrig. Laat ik de TFM gaan lezen of zo.
@Ad
*zucht*
1. Ik zie cloud computing als een delivery model, één van de vele die we hebben, en niet als wondermiddel.
2. SOA zijn business georïenteerde principes, geen klant of IT georïenteerde principes zoals ik duidelijk stel.
Betreffende je opmerking over wel of geen fan aangaande SOA: “When the shit hits the fan, it’s all get messy” Vergeet niet dat service level agreements inspanningsverplichtingen zijn en nog geen garantie voor resultaten.
Misschien ben ik warrig maar kijkend naar de realiteit ligt er nog een behoorlijke uitdaging in de optimalisatie van processen, met name binnen Enterprises. Horizontale processen over vertikale structuren levert als ik me niet vergis ook nog flink wat problemen op binnen de decentrale overheid.
Ewout,
Je beide punten lijken mij niet correct.
1) Cloud computing is meer dan alleen een leveringsmodel. SaaS, PaaS en IaaS zijn leveringsmodellen, cloud computing zelf is niet alleen een business model, maar ook een stuk techniek.
2) SOA is Software georiënteerd ontwerp “patroon” (design pattern), dus wel degelijk IT georiënteerd.
Als je al met foutieve aannames begint kan de rest al bijna niet meer kloppen.
Daarnaast ontwijk je mijn vraag over hoe het wel moet, gooi je er weer een paar afkortingen tegenaan. En kom je weer met hoe het niet moet.
SOA is geen cloud computing en kan ook prima zonder cloud computing. Dus dat je SOA een zwaartepunt maakt doet afbreuk aan je artikel die zou moeten gaan over de kwaaltjes van cloud computing.
Ik zeg; terug naar de tekentafel!
@Henri
SOA is TCP zonder IP, IT is meer dan infrastructuur.
Ewout,
De laatste bijdrage in deze boeiende discussie, voortgekomen uit jouw al even boeiende opiniestuk, is van een week geleden, dus de hoogste tijd om deze weer op gang te brengen.
In een eerdere reactie stelde ik:
“SOA als procestechnologie (al of niet in combinatie met BPM) is terecht doodverklaard;
SOA als kennistechnologie is springlevend en heeft dus de toekomst”,
dus je zult begrijpen dat ik het slechts ten dele met je eens ben.
Ik onderschrijf je aversie tegen SOA, voor zover deze de procesgeoriënteerde variant betreft.
Daarmee is de discussie rond SOA wel urgent, gezien het feit dat deze procesgeoriënteerde visie op SOA de literatuur, de markt en de uiteindelijke toepassing in bedrijfsapplicaties voor 100% domineert.
Het heeft dus niet zoveel zin om TFM te lezen 🙂
Met andere woorden; SOA als kennistechnologie (wat ik ook wel aanduid met 5GL/SOA) bestaat vooral nog op de tekentafel (en gezien de bijval die ik op dit forum krijg moet ik concluderen: mijn tekentafel).
Als je stelt dat SOA het bestaan van data negeert, dan zet ik daar in eerste instantie vraagtekens bij, omdat uitgerekend de procesgeoriënteerde visie op SOA (vanaf nu kortweg aangeduid met SOA/BPM) beschouwd kan worden als een data-gedreven (en ook wel event-gedreven) aanpak.
SOA abstraheert inderdaad van de fysieke opslag van gegevens; het zal SOA (en dus zowel de interne businessklant als de externe klant) een biet zijn of gegevens hiërarchisch, relationeel, object-georiënteerd of anderszins zijn vastgelegd in databases. Maar abstraheren is niet hetzelfde als negeren.
Hier zit wel een gemene adder onder het gras: object-relational impedance mismatch; het verschijnsel dat gegevens uit relationele databases nogal moeizaam zijn te mappen op objecten (en dus ook op services!). Mogelijk moet het gebruik van relationele databases binnen SOA dus worden afgeraden.
Je stelling dat SOA het bestaan van data negeert is terug te vinden in het volgende document:
http://www.insideanalysis.com/wp-content/uploads/2012/04/TheIOA-WP-Final-0419.pdf ;
het past ook bij mijn stelling dat de hedendaagse SOA’s procesgeoriënteerd zijn.
Nu wordt in dit (overigens zeer toegankelijke) document wel terecht gesteld dat SOA een volgende stap is in een evolutie van programmeertechnieken die valt onder het objectgeoriënteerde paradigma; het lijkt mij echter niet terecht om de OO-aanpak een vorm van procesoriëntatie te noemen. OO was al voorbij de proces-data dichotomie, en datzelfde zou dus voor SOA in nog sterkere mate moeten gelden; ware het niet dat SOA ten onrechte toch weer in de proces-pool van deze dichotomie wordt geduwd. Om Information Oriented Architecture (IOA) vervolgens aan de data-kant binnen deze dichotomie op te zetten; blijkbaar als een verdere abstractie van het relationele model. 5GL/SOA is echter ver voorbij de tegenstelling tussen IOA en procesgeoriënteerde SOA!
Blijft dus de vraag in hoeverre (je terecht stelt dat) de procesgeoriënteerde visie op SOA verweten kan worden dat het data negeert (een verwijt dat 5GL/SOA uiteraard niet valt te maken). Mijns inziens gaat het vooral (en uitgerekend) mis in de bedrijfsproceslaag; de laag die precies wordt vormgegeven met BPM-tools en met kretologie als “orkestratie”. In eerdere reacties heb ik het 5GL/SOA-alternatief voor deze laag al voorgesteld: Flow-services.
Samenvattend: Henri Koppen slaat de plank mis door vast te blijven houden aan SOA/BPM (en bovendien door SOA geen punt van discussie te noemen); jij slaat de plank mis door afscheid te nemen van alle vormen van SOA en anno 2014 nog eens aan te komen met IOA.
@Jack
Dat we het eens zijn dat SOA al dan niet met BPM de data zelf nog steeds negeert is mooi meegenomen, dat we van mening verschillen over IOA heeft misschien te maken met het feit dat ik er vanuit beheer naar kijk. Misschien sla ik de plank mis maar er zijn nog planken vol met archiefdozen al dan niet digitaal. Dat code en techniek sneller evolueren dan organisaties probeerde ik duidelijk te maken met de wet van Moore, residu van alle ontwikkelingen is data waarvan de ongestructureerde volumes steeds groter worden doordat we niet alleen steeds meer digitaliseren maar ook niets weggooien. Of de rap groeiende databerg het gevolg is van SOA klutsers 1.0 of een organisatie die niet de laatste versie ervan geadopteerd heeft maakt voor het resultaat niet uit. Service richt zich (nu) teveel op de business wat een gevolg kan zijn van de proces- in plaats van klantorientatie maar dat is lood om oud ijzer.
Ik durf in 2014 dus best aan te komen met IOA als ik overweeg dat veel organisaties nog werken met systemen uit de vorige eeuw
Jack, beetje pretensieus om SOA zoals dit door 90% van de wereld blijkbaar wordt gezien af te schrijven en iets op jouw tekentafel als de waarheid te verkondigen en vanuit die redenatie te schrijven dat ik de plank mis sla.
Je probeert inhoudt te geven aan de *toepassing* van SOA. Maar dat is in mijn ogen niet terecht. De essentie is dat applicaties (data) met elkaar kunnen praten door middel van services / API’s en dat je dit als architectuur principe hanteert. Dat is de scope van SOA. Niets meer, niets minder. Punt.
Dat je een SOA gebruikt voor 5GL / BPM / IOA, sure. Je doet het tegenovergestelde van Ewout, die probeert cloud computing plat te slaan naar een leveringsmodel. Terwijl cloud computing veel meer is. Jij probeert SOA veel meer te maken dan het is.
In onze huidige wereld van cloud computing, virtualisatie, API’s en diensten die met elkaar kunnen praten is SOA gewoon een feit. Het wordt alleen niet zo genoemg, muy bien.
Tegenwoordig wordt BI als Big Data verkocht, sure. Dat is marketing.
“het verschijnsel dat gegevens uit relationele databases nogal moeizaam zijn te mappen op objecten (en dus ook op services!). Mogelijk moet het gebruik van relationele databases binnen SOA dus worden afgeraden.”
– Wat de toekomst is van relationele databases is ongewis, maar wat je schrijft ben ik het wederom niet mee eens. Ten eerste; een record in een tabel kun je prima als object benaderen en met ORM er bovenop kun je dat prima als basis gebruiken om met services te praten. Wil je als object in zijn geheel communiceren? Sure, parse hem naar JSON en je bent klaar.
De open vraagt blijft dus: Wie slaat hier de plank mis?
Maar zoals ik eerder schreef, SOA is Off Topic 🙂
@Henri
Als we alle planken bij elkaar nemen hebben we genoeg om SOA te ‘kisten’ en ten grave te brengen;-)
Als service klutser moet je eens ophouden om spijkers te leveren als de klant om schroeven vraagt, lees overdrachtelijk nog eens dat stukje over grottekening en infographic als je twijfelt over delivery model van cloud computing.
Ewout, de term misschien, de realiteit is ieder bedrijf steeds meer gebaseerd wordt op SOA.
Ik zal mijn argumenten nogmaals in andere bewoordingen met je delen, want er is nauwelijks een andere conclusie mogelijk.
Hoe verbinden applicaties zich aan een server voor data? Met een rechtstreekse verbinding of via Open DataBase Connectivity (ODBC). Dit is jarenlang het (enige) model geweest, en bij browser applicaties is dit nog steeds dominant. De webserver staat vaal heel dicht bij de database server.
Maar wat als je data moest delen met andere applicaties buiten de organisatie. Daarvoor werd in de eerste instantie Integrated Development Environment (IDE) voor bedacht -dit was nog voor de opkomst van het internet- wat in de praktijk vaak een gedrocht werd.
Tegenwoordig zie je ook nog wel dat er ingewikkelde VPN verbindingen worden opgezet, of een firewall geconfigureerd wordt om een andere applicatie toegang te geven tot een deel van de database.
Dit is technisch uitdagend, heeft een hoge doorlooptijd en is gewoon gevoelig en schaalt niet.
In een wereld waarin alles met alles kunnen verbinden steeds meer het nieuwe normaal is: Je smartphone kan wel met 20 verschillende systemen verbinden (maar los van het data delen tussen deze apps), en samenwerkingen tussen organisaties wordt steeds normaler moest er er iets anders komen en dit is de facto webservices geworden.
Als je applicaties bouwt met webservices als fundament, dan heb je hiermee een aantal krachtige voordelen als het aankomt op integratie, veiligheid en schaalbaarheid. Het is ook heel flexibel en uitbereidbaar en bovenal, je werkt hiermee platform onafhankelijk, iedere andere tool kan met je communiceren door middel van deze webservice. Wie hiervan de kracht niet ziet of zich ertegen afzet, zal dan wel een alternatief moeten noemen en dit onderbouwen.
In mijn ogen hebben webservices als basis voor client server applicaties twee nadelen : Performance en Beheersbaarheid. Een webservice is fundamenteel trager dan een client-(database)server verbinding, het is namelijk een tussenlaag die in zichzelf performance kost en ook de output van een webservice is gewoon minder efficiënt dan een database connectie. Deze twee nadelen kunnen echter in veel gevallen gemitigeerd worden doordat een webservice van nature schaalbaar is, je kunt er vrij simpele rekenkracht tegenaan gooien. En beheersbaarheid wordt vooral aangetast omdat men steeds meer kan en dat het dus gemakkelijk is een oerwoud aan verwevenheden te creëren. Maar als je de webservice net zo traditioneel inzet als je client-server verbinding is er niets aan het handje en heb je zelfs meer meetmogenlijkheden dan daarvoor. Want als de business heel veel wil en je gebruikt *geen* webservices, dan heb je pas een probleem!
Oja, dat richten op webservices als de de facto standaard binnen een bedrijf en bouwen onder architectuur, dat noemt men SOA.
Dus Ewout, de opjager van service klutsers, ik zou graag een aanpak lezen hoe je de integratie en flexibiliteit wensen van de business oplost zonder SOA. Ik ben oprecht benieuwd!
Ik zou graag zien dat er gaten geschoten worden op bovenstaande, dat is dan per definitie leerzaam voor me, of helpt me argumenten aan te scherpen.
Maar bovenstaande is in mijn ogen een hele toegankelijke uitleg over de geschiedenis van SOA en webservices.
@Henri
Je vraagt je toch af hoe ze het vroeger deden. Oh wacht, ik riep iets over grottekeningen die misschien wel als pre-historische infographic gebruikt werden.
Tuurlijk is het mooi dat we alles en iedereen over de hele wereld kunnen verbinden en zo informatie uitwisselen met de snelheid van het licht. Die dynamiek biedt kansen maar zoals we ondertussen merken ook bedreigingen.
In een heel korte reactie naar jouw stelde ik dat SOA nog teveel TCP zonder IP is. Ik kan het mis hebben maar Jack lijkt in zijn betoog uit te gaan van het Informatie Protocol in plaats van het Techniek-Communicatie Probleem.
Nogmaals, cloud computing is TCP en dus niet meer dan een delivery model.
Dat ik wat gekscherend over SOA doe komt door klutsers die van alles een webservice willen maken, altijd lachen bij Service Desks. Als je belt dat Internet het niet doet vertellen ze dat je naar de website moet gaan om een incident aan te maken. Snap jij het?
SOA is misschien niet dood maar herdefinieer eerst de service, deze laat nog weleens te wensen over. Maar misschien komt dat wel door de semantische dementie als je begrijpt wat ik bedoel.