Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

IT-platformen en PaaS vormen nieuw concept

 

De laatste decennia volgen technologische ontwikkelingen, en daarmee veranderende wensen van uw klanten, elkaar steeds sneller op. In diverse industrieën zijn het juist de ondernemingen die hun voordeel weten te halen uit het gebruik van platform-concepten het meest succesvol. Een nog relatief nieuw toepassingsgebied van dit concept, it-platformen, kan ook voor jouw onderneming beslissend zijn!

Buiten de it zijn ontwikkelplatformen al geruime tijd in gebruik. Fabrikanten voegen nieuwe toepassingen vaak toe aan bestaande producten. Denk hierbij bijvoorbeeld aan de ontwikkeling van de mobiele telefoon, waaraan in de laatste jaren steeds meer nieuwe functies zijn toegevoegd. De eerste modellen konden uitsluitend bellen en sms’en, maar tegenwoordig worden smartphones ingezet als mp3-speler, navigatiesysteem en camera. Nieuwe modellen bouwen hierbij steeds voort op de bestaande modellen.

Zo kan er met kleine aanpassingen (bijvoorbeeld een betere camera) een totaal nieuw product worden gelanceerd. Hergebruik van bestaande componenten leidt in dit geval tot een veel kortere time-to-market en lagere kosten, dan wanneer er een geheel nieuw toestel ontwikkeld zou moeten worden. Dit maakt het mogelijk om snel in te spelen op nieuwe trends in de markt, en een betere aansluiting te hebben met klantenwensen, met een verbeterde concurrentiepositie tot gevolg.

Kosten besparing

In de auto-industrie is het gebruik van platformen ook duidelijk zichtbaar. Een goed voorbeeld is de Volkswagen Groep. Zij gebruiken vergelijkbare componenten in meerdere merken en modellen. Denk hierbij aan de overeenkomsten tussen Skoda, Volkswagen en Audi, die technisch grotendeels identiek aan elkaar zijn. Ook daar ligt de focus op het verlagen van kosten, versnellen van time-to-market en verbeteren van de concurrentiepositie.

Modular Transverse Matrix (MQB) is de belichaming van de filosofie van de Volkswagen Groep om auto’s te produceren als een platform.

De opkomst van Platform-as-a-Service

Met de opkomst van PaaS kunnen deze principes nu ook worden toegepast door een it-organisatie in het ontwikkelen van nieuwe producten. Bij het ontwikkelen van applicaties voor bedrijfsspecifieke processen is het daardoor niet langer nodig om de it-infrastructuur en programmatuur steeds opnieuw te ontwikkelen. Door gebruik te maken van een volwassen ontwikkelplatform zijn standaard applicatie componenten (bijvoorbeeld voor workflow, autorisatiemodel, user interface, et cetera), data en interfaces herbruikbaar om nieuwe functionaliteit te ontwikkelen. Je hoeft daardoor niet voor elke applicatie ‘het wiel opnieuw uit te vinden’.

Dit heeft een enorm positief effect op de snelheid en kwaliteit waarmee nieuwe it-applicaties ontwikkeld, getest, en geïmplementeerd kunnen worden. Snellere (en dus goedkopere) levering van nieuwe functionaliteit door it-organisaties heeft een positief effect op de tevredenheid van de klanten en daarmee heeft platform-technologie de potentie om it-organisaties te transformeren van ‘cost center’ naar ‘strategische business partner’.

Kortom, it-platformen bouwen voort op beproefde industriële ideeën en het is tijd om de potentie hiervan voor jouw organisatie te begrijpen en te verwezenlijken.

Elmer de Valk, eigenaar en managing consultant bij Plat4mation

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4970614). © Jaarbeurs IT Media.

?


Lees meer over


Partnerinformatie
 

Reacties

Iets te algemeen stukje over Platform as a service, niettemin is het goed dat het onder de aandacht wordt gebracht.

In mijn gesprekken met IT leiders merk ik dat het concept wel herkend wordt, maar nog niet helemaal op waarde geschat. In mijn ogen (onderbouwd door rapporten van marktanalisten) is het potentieel enorm. Mijn advies zou zijn: Maak een keer de business case en bereken het potentieel voor jouw (IT) organisatie.

Wanneer je je ontwikelingstraject modulair en in buildings blocks opbouwt dan hoef je niet per se van PaaS gebruik te maken.

Voorwaarde hiervan is dat het fundament waar je product op gebouwd wordt gelijk blijft. Als voorbeeld, je kunt niet je ontwikkelingsomgeving voor je app`s (geheel)hergebruiken als je je bestaande app`s aan een 64x besturingssysteem wilt aanpassen.

Waar ik soms erg veel moeite mee heb is het commerciële gehalte vaak, evenals overigen het commerciële gehalte in de reacties die daar op volgt.

Hoog WC eend gehalte waarbij ik mij dan altijd even twee dingen afvraag;

a. Is er een toevoegende waarde?
Waar zit de winst? Kijken naar een ander model doe je alleen als je overtuigd bent dat er hoe dan ook winst valt te behalen... lijkt mij dan even erg simpel....

b. Voldoet mijn huidige proces dan niet beter met wat 'frisse' aanpassingen?

Zoals Reza hier terecht stelt, heb je voor ontwikkelingsstrategie niet per definitie PaaS nodig natuurlijk. Je kunt het commercieel heel hard en vaak blijven roepen natuurlijk.....

Als ik vanuit de fysieke wetmatigheden van IT als materie blijf denken, ik weet het, oubollig want... tijd perceptie alles veranderd en ik wil niet mee..... maak er maar wat van...

Dan is het nog altijd zo dat wanneer ik ga ontwikkelen, testen, packagen, piloten, ik dat gewoon op eender welk platform bij mij in huis kan. Een beetje tester zorgt dat die het nodige gewoon in huis heeft. We hebben het,volgens mij nog steeds niet, over rocket science.

Ik kan mij vergissen maar.....

- Wanneer het licht in de straat uit valt, en dus ook de eerste beste wijk of gebiedskast, neen, die staat op gelijk net als straatverlichting in meer dan 60% van de gevallen, kan ik nog steeds door gaan.

- Valt mijn verbinding van mijn leverancier weg, zal het wel, ik kan nog steeds door.

- Valt mijn router naar buiten uit? Tja, zal daar niet wakker van liggen.

Zullen we nog even zo door gaan? We kunnen vanuit commercieel oogpunt erg veel blijven roepen maar de wetmatigheden van en in IT blijven onverkort dezelfde. (Grappig als je daar ooit nog eens even over zou willen nadenken.)

Law number 9
Hoe meer componenten, hoe groter de kans op omissie.

Deze gelden niet alleen als universeel, ook in de IT natuurlijk.

Ik zie dat Reza me voor is want ik vroeg me ook af of hier niet modulaire platformen bedoeld wordt aangezien er nog weleens verschil wil zitten tussen database, middleware en programmeertalen zelf. Die 'modules' hebben trouwens allemaal onderhoud nodig en PaaS is naar mijn opinie dan ook meer een deployment methodiek waarbij het niet om het platform maar de automatisering gaat.

Marktanalisten - en Henri - roepen dan wel dat PaaS de weg is maar deze zit vol met (val)kuilen en aangaande de business case geldt vaak: we hebben een hamer en daarom is alles een spijker. Ik ga liever uit van omgekeerde, welke gereedschap is nodig op grond van het bouwwerk omdat veel 'one-size-fits-all' oplossingen uiteindelijk gewoon kromme spijkers zijn. Horizontale schaalbare webservices met vertikaal schalende database blijft tenslotte een ongelukkige combinatie.

Wie het wiel niet opnieuw uit wil vinden zou bijvoorbeeld ook kunnen overwegen om open source te gebruiken, zeker voor de levering van snelle en goedkope functionaliteit interessant. In dat geval natuurlijk wel even denken aan de non-functionele aspecten want open source is helaas niet de heilige graal.

Ik zie PaaS niet alleen als deployment methodiek, maar zeker ook als het standaardiseren van de applicatieondersteunende software. En daar is echt nog veel winst te behalen. Vooral als je meerdere applicaties gebruik laat maken van gedeelde platforms, zoals middleware of databases e.d. Ik weet vanuit de praktijk dat er nog software wordt ontwikkeld die het niet toestaat naast andere software te draaien.
En dan zie je dat je ondersteunende software als het ware single tenant in moet zetten, met alle beheer- en licentiekosten van dien.
Het standaardiseren drijft ook het hergebruik. Dat is in de software-ontwikkeling nog steeds een lastig punt.

PaaS biedt wat mij betreft mooie kansen. Het heeft zeker meer om het lijf dan ergens in een cloud kunnen deployen. Dat is vooral IaaS naar mijn idee.
Belangrijkste toevoeging van PaaS is het bieden van "standaard" applicatie infrastructurele diensten zoals (SQL)Storage, Communicatie Infrastructuur en dergelijke waar vanuit het platform al intrinsiek rekening wordt gehouden met scale-out en multitenancy scenarios, en doordat dit "out-of-the-box" beschikbaar is, wordt het veel eenvoudiger om nieuwe producten en diensten op een schaalbare wijze op te zetten.

Een belangrijke beperking is wat mij betreft nog wel de standaardisatie, aangezien elk PaaS platform/leverancier zijn eigen APIs kent. Een ontwikkeld product op "PaaS A" kan dus niet zomaar geport worden naar "PaaS B".

Daarom verwacht ik dat PaaS pas echt een vlucht zal nemen als hier standaardisatie gaat plaatsvinden en je dus eenvoudig van platform kunt gaan wisselen als de PaaS leverancier niet meer bevalt (bijv. vanwege te hoge prijzen, onvoldoende halen van SLAs, onderhevig zijn aan Patriot Act etc.)

Nu even zonder de gebruikelijke kretologie.

PAAS (ongeveer een server als internetdienst) biedt een dienst tegen lagere kosten maar met haken en ogen.
Meer staat ook niet in het artikel.

Dat wordt hier nu x maal herhaald, maar zo begrijpt een manager het misschien ook . . .

PAAS of platformen algemeen is een kapstok begrip in kan qua context hele verschillende dingen betekenen.

Om een voorbeeld te noemen : Google Drive is een Platform as a service.

Say What?

Google Drive is niet alleen een SAAS dienst waarop je bestandjes op kunt slaan, maar je kunt het ook inzetten als generieke enquete dienst (Google Forms), en je kunt er ook scripts op zetten die uitgevoerd worden als er een bepaald event plaatsvind. Dus als iemand Document X in Folder Y zet, dan kan een script uitgevoerd worden die niet alleen de inhoud van het document aanpast (bijvoorbeeld de datum van vandaag op een bepaalde plek invoegd), maar ook een email stuurt naar iemand om aan te geven dat een document is toegevoegd.

Elastic Beanstalk, een service van Amazon Webservices is ook PAAS. Ik ontwikkel een software webservice, windows service of website applicatie en laat deze landen op een platform die zelf schaalt op basis van bepaalde triggers. Ik hoef geen virtuele servers aan te maken, deze maken zich zelf aan op basis van regels.

Decisions.com is ook een platform as a service waarop je processen kunt uitvoeren en datakopplelingen kunt realiseren maar zit weer heel anders in elkaar.

PAAS is te divers om er zomaar wat uitspraken op los te laten.

Standaardisatie is een hefboom die ook kan leiden tot commodity. Er zit ook echter een zeer groot nadeel aan standaardisatie. Het is namelijk beperkt en niet innovatief.

Ik geloof dat het nog (veel) te vroeg is voor standaardisatie. Als dit nu al zou beginnen vermoord je de innovatie. Beter gaan we nog even lekker door zoals het nu gaat en pas als we echt een beetje snappen wat de toekomst brengt, dan wordt het tijd om wat standaarden te omarmen.

Nu inspringen op de standaard (PAAS) is binnen een paar jaar legacy, dat beloof ik.

@Henry: bijzonder opmerking van je: "Er zit ook echter een zeer groot nadeel aan standaardisatie. Het is namelijk beperkt en niet innovatief."

Dus standaardisatie en innovatie gaan niet samen? Een goed voorbeeld van het tegendeel is b.v. EasyJet.
Maar je bedoelt misschien standaardisatie als beperking en niet meer kunnen veranderen (je kunt kiezen uit alle kleuren: groen, groen en groen).


Leen, standaardisatie is een zeer krachtig iets met een enorme hefboom.

Maar laat me even een paar ideeën delen: Uit het Euro songfestival zal nooit veel innovatie voortkomen als de winnaar wordt gekozen door de massa. De standaard ligt altijd in het midden.

Stel dat micro USB de standaard wordt om telefoons op te laden... Micro USB en een crime om aan te sluiten, is niet waterdicht heeft beperkte functionaliteit. Dus als dat de standaard word remt dit de ontwikkeling van de telefoon.

Windows is de de facto standaard op de Desktop. We weten wat dit qua innovatie allemaal gebracht heeft... Handig is het wel, als je software maakte hoefde dat alleen maar op Windows te draaien.

Als je een software pakket hebt wat je als "standaard" neer kunt zetten omdat het met alle databases babbelt dan mis je alle specifieke voordelen van alle database systemen aangezien deze niet gebruikt kunnen worden omdat het anders geen standaard meer is.

XML wilde ze ook de standaard maken... brrrrr.


Dat wisselstroom op 230V een standaard is heeft veel goeds gebracht met een enorme hefboom, maar dit is wel legacy waar we nog heel lang aan vast zullen zitten.

X86 architectuur is de standaard maar hoeveel innovatie het tegen heeft gehouden kunnen we alleen maar van dromen!

Als platformen, API's, NoSQL, SAML methoden nu al een standaard worden terwijl we de fundamenten nog niet goed begrijpen dan kan de standaard niet anders zijn dan iets wat je niet wilt hebben.

Maar goed, dit zijn mijn gedachten.

Uiteraard kun je wel weer verder bouwen op standaarden en verhoog je uitwisselbaarheid, maar een goede standaard is in mijn ogen pas goed als de kennis erachter wat volwassener is.

Stel dat Edison gewonnen had van Tesla, dan waren we nu wellicht zo ver geweest als in de jaren 80 van vorige eeuw.... Maar dat het imperial system vermoord zou moeten worden ten behoeve van een wereldwijde standaard (metric), daar ben ik het heel erg mee eens :-)

Henri,
Bekijk je de innovatie en standaardisatie vanuit positie van de klant of ontwikkelaar?
Ik kan me voorstellen dat de standaardisatie voor een enthousiasme ontwikkelaar remmend kan zijn maar dat geeft je klant best duidelijkheid en houvast voor het bedenken en implementeren van haar innovatieve ideeen of plannen.

Bovendien ik vind dat de verdere ontwikkelingen van een product en hieraan gerelateerde sub producten snel en in goede banen geleid kunnen worden als het product op een gestandaardiseerd fundamen gebouwd is.

Kun je je voorstellen als standaardisatie binnen cloud computing ingevoerd wordt hoe snel de ontwikkelingen zullen gaan en hoe snel de adoptie door klanten gaat gebeuren.

Ik heb je al (2 weken geleden) in mijn reactie op een eerder artikel gewezen op de voordelen van standaardisatie in de wereld van automotive.

Maar goed, ik vind dat dit total een andere discussie is dan het onderwerp van dit artikel.

Als ik bovenstaande commentaren lees wordt ik bevestigd in mijn mening dat PaaS vele gezichten kent. Afhankelijk van de achtergrond van de beschouwer komt er een bepaald beeld (en mening) naar voren. Mijn beeld is dat PaaS high level in 2 smaken verdeeld kan worden.

1) PaaS als een infrastructurele dienst om applicaties te deployen (denk aan bijvoorbeeld Azure, GoogleAppEngine)
2) PaaS als een middel om applicaties te bouwen én deployen (denk aan bijvoorbeeld Mendix, OutSystems of Force.com).

Beide typen PaaS bieden voordelen voor een IT organisatie. Denk hierbij aan snelheid, kwaliteit en kosten. Welke behoefte er door PaaS kan worden afgedekt, welke PaaS leveranciers hierbij passen en hoe de Business Case er dan uitziet blijft een klant specifieke vraag. PaaS is helaas geen one-size-fits all...

Elmer,
Bij optie 2 moet je niet snel voorbij een onderwerp gaan waardoor je extra tijd en budget voor je project nodig hebt:

Het gebruiken van PaaS als middle om je applicatie te bouwen en later in een andere omgeving of platform implementeren vereist extra tijd en budget voor het fine tunen van je product in een andere omgeving.

Maw, het is niet kopieren van wat je in een (PaaS) omgeving gemaakt hebt en neerzetten in een andere (PaaS) omgeving.

Bereken de kosten die je hierdoor maakt en vergelijk deze met een modulaire werkwijze (building blocks) zoals ik eerder heb opgemerkt.

Het grappige van definities is dat ze altijd vroeg of laat zodanig gebogen worden dat ze passen in het straatje van een leverancier. Het is dus jammer dat cloud heksen weer bezig zijn met allerlei abracadabra waardoor juist die knelpunten met de datakoppelingen ontstaan waar ik het in eerste reactie over had. Ik vraag mij namelijk af hoe efficient het is om MEAP laag in de cloud te zetten maar je data on-premises en of zo'n 'backdoor' ook wenselijk is.

Tenslotte zou je deployment probleem ook op kunnen lossen met een appliance waarbij applicatie stack gecombineerd wordt in een geoptimaliseerde infrastructurele bouwsteen waarbij het onderhoud via een abonnementsvorm afgenomen kan worden. Er zijn tenslotte 56+ meer of minder bekende oplossingen en sommige op basis van open source want dat het hier om Mendix/Force.com had ik al begrepen, de gebruikelijke hamertje tik dus.

Want als ik dit soort verhalen lees krijg ik een ESB/ERP deja vu gevoel waardoor we in de back-office met die vertikaal schaalbare databases zitten die we alleen met een steekkarretje kunnen verplaatsen. Volgens mij kun je uit snelheid, kwaliteit en kosten dan ook uiteindelijk maar 2 kiezen.

Leuk verhaal maar ... waarom zou ik dit op PAAS doen en niet lokaal in een eigen omgeving?

Het artikel overtuigd mij niet dat PAAS zoveel goedkoper is, maar geeft (terecht) aan dat een volwassen ontwikkelplatform en een architectuur welke onafhankelijke componenten mogelijk maakt efficiënt is.

Reza, "Maw, het is niet kopieren van wat je in een (PaaS) omgeving gemaakt hebt en neerzetten in een andere (PaaS) omgeving."

Waarom blijf je maar hameren op portabiliteit? Als een bedrijf voor SAP kiest weet deze ook wel dat het niet portable is. Ideeen afschieten op portabiliteit is zo dood als een pier. Natuurlijk moet je een exit strategie hebben, maar kiezen voor portabiliteit is gewoon een uiting van onzekerheid en kiezen voor schijnzekerheid.

Je kunt een MS SQL database prima verplaatsen naar een andere leverancier, maar als deze de complexe business rules die uitgevoerd worden in procedures niet begrijpt is dit nog steeds zinloos.

Ewout, jouw knelpunten zijn uitingen van slecht ontwerp, die zullen je hard raken ongeacht of je voor een platform kiest of voor gedegen traditionele systemen. Spaghetti maken is niet exclusief voor cloud diensten.

PaVaKe, ik ben deze week begonnen met een artikel die precies jouw vraag zou moeten beantwoorden. 1 van de cruxen is dat lokaal deployen het lokaal denken uitlokt. Men maakt oplossing vaak hard gecodeerd waardoor ze beperkt bruikbaar zijn en niet doorontwikkeld (kunnen) worden.

Reza, er staat me iets van bij dat ik je automotive voorbeeld niet sterk vond, maar ik kijk niet alleen vanuit ontwikkelaar, maar juist ook vanuit een business perspectief. Beide zijn namelijk belangrijk en zouden ook in lijn met elkaar moeten zijn.

@Henri ... ik ben benieuwd

Volgens mij is het verschil tussen lokaal en globaal denken niet zozeer tool afhankelijk, maar meer een mentaliteitskwestie.

Ik heb afgelopen jaren wel vaker tunnelvisies meegemaakt binnen ontwikkelgroepen. Dat los je niet (alleen maar) op met een andere tool, maar is vooral een stukje bewustwording kweken volgens mij.

Henri,
" Waarom blijf je maar hameren op portabiliteit?"

Ik snap niet wat je met deze vraag bedoelde.

Ik probeer het nog een keer:

Als je je applicatie in een PaaS omgeving gemaakt hebt dan weet je niet welke middleware je PaaS-leverancier precies gebruikt heeft.

Deze wetendheid heb je nodig voor het verhuizen van je applicatie naar een andere omgeving in de cloud of intern in je eigen datacenter.

Om dit probleem op te lossen heb je meer tijd en ook geld nodig om je applicatie na de ontwikkeling in je PaaS omgeving geschikt te maken voor andere omgeving.
Dit is en belangrijk punt waar Elmer snel voorbij gaat.

Ik hoop dat deze laatste uitleg wat meer duidelijkheid verschaft.

Reza,

"Deze wetendheid heb je nodig voor het verhuizen van je applicatie naar een andere omgeving in de cloud of intern in je eigen datacenter."

Dat bedoel ik met portabiliteit. Dus de mogelijkheid om naar een andere applicatie / platform / leverancier te gaan als je niet meer blij bent met de eerder gekozen "applicatie / platform / leverancier". Ik ontken niet dat portabiliteit niet belangrijk is, maar veel keuzes uitsluiten omdat je volledig vrij wilt zijn in het kiezen van leverancier of applicatie platform is een utopische gedachte. Met andere woorden: Als je een keuze maakt voor een platform en je deze echt in gebruik neemt kun je niet zomaar switchen.

Een fout die veel Open Source denkers ook maken. Als je een open source product bij een leverancier draait betekent dit niet dat je deze zonder pijn kunt verplaatsen naar een andere leverancier.

Als je bijvoorbeeld kies voor Windows Azure als PaaS en specifieke zaken van dit platform gebruikt betekent dit dat je niet zomaar hiervan af kunt stappen, en dat is okee als je er goed over hebt nagedacht. Maar ik krijg het idee dat jij veel keuzes afkeurt omdat de portabiliteit niet goed is. Dat is een keuze en een visie en die van mij is ietswat anders :-)


PaVaKe: Bewustwording en de menselijke kant is zeker belangrijk, maar ik heb nu meerdere trajecten meegemaakt waarbij het moven naar de (publieke) cloud echt een nieuwe bewustzijn creëerde. Als je in de comfort zone van je ontwikkelaars blijft zullen ze ontwikkelen zoals ze dit altijd al gedaan hebben. In de cloud zullen ze dit ook wellicht proberen maar komen ze er snel achter dat dit voor geen meter werkt. Bezit versus gebruik werkt echt verhelderend.

Als je iemand zijn boeken, boekenkasten en DVD spelers afneemt gaat de adoptie van streaming en digitaal veel sneller als dat je probeert hem of haar bewust te maken.


Reza,

Als een applicatie wordt gebouwd met een Rapid Application Development PaaS of aPaaS(bijvoorbeeld: (ditmaal in alfabetische volgorde) Apppoint, Force.com, Mendix, Miosoft, OrangeScape, OutSystems, Zoho, etc.), dan is het in sommige gevallen weldegelijk mogelijk deze op een meerdere infrastructuur platformen te hosten.

De vraag die bij mij opkomt is of dit wenselijk is. Ik ben het met Henri eens dat een keuze voor een platform weliswaar beperkt in portabiliteit, maar dat dit ook niet noodzakelijk een overweging hoeft te zijn.

Kom ik terug bij mijn eerdere statement: Denk bij het starten van een PaaS initiatief / manier van werken goed na over de keuze voor het juiste platform. Hierbij is toekomstvastheid (net als bij SAP het geval is) een belangrijke overweging.

@Elmer,
In een dynamische ict-wereld waar alles voortudurend aan het veranderen en verbeteren is hoe kun je nu een keuze maken voor iets (zoals een PaaS platform) waar je over een paar maanden geen spijt van krijgt?

Verschillende cloudleveranciers komen elke dag met iets anders wat je niet bij je huidige levernacier krijgt en ook misschien niet in de nabije toekomst krijgt. De prijzen worden steeds veranderd, de mogelijkheden worden per leverancier regelmatig veranderd dan moet ik aan toekomstvastheid denken en een keuze maken waar ik later geen last van krijg? Moest ik bij cloud niet denken aan "vrijheid"?

Hadden we het niet eerder over "standaardisatie" in cloud? Is dat niet het sleutelwoord?
Of moeten we onze software beter op een IaaS platform bouwen waar we zelf meer controle op kunnen uitoefenen?
En als IaaS dit gaat oplossen dan hebben we het zeker over een ander prijskaartje. Dus terug naar mijn eerste opmerking vergelijk een modulair gebouwde omgeving met een cloud-oplossing.

@Reza,

Ik zie je punt. Echter als je mij vraagt wat beter is: Wachten totdat de PaaS markt is gestandaardiseerd, of starten met een goed product wat past bij de huidige behoeftes, dan zou ik kiezen voor het laatste. PaaS biedt ook met de huidge stand van technologische ontwikkelingen hele interessante mogelijheden. Daarbij is het bekwamen van jezelf (als IT organisatie) op het vlak van PaaS een belangrijke stap om hier zowel nu als in de toekomst de vruchten van te kunnen plukken. Sterker nog, het zou een strategische competentie kunnen worden die "game changing" kan zijn voor de business. Dergelijke comtenties opbouwen kost tijd.

Fortune favours the brave!

@Henri
Blijkbaar vind je de eerdere keuzen een slecht ontwerp wat natuurlijk wel begrijpelijk is omdat je verblind bent door de cloud, er zit nogal wat rook om je hoofd en ik zal dus 'koppig' zijn en het nog een keer proberen uit te leggen:

Als eerste hebben we data - opgeslagen in 30 jaar oude ontwerp/architectuur keuzen - die we probeerden te ontsluiten met een ESB, de vierkante cloud die mee kwam met SOA architectuur waarbij datakoppelingen met XML en SOAP gemaakt werden en de workflows voor orchestration zorgden. Iets soortgelijks lijken de Mobile Enterprise Application Platformen (MEAP) te doen.

Dat je cloud kiest voor uitvliegende gebruikers en bijbehorend platform als landingsbaan kiest is prima. Maar denk ook eens aan de bagage die buiten het zicht blijft maar wel door een heel logistiek proces heen gaat. Een uitdaging waar veel (ERP) systemen mee worstelen is dan ook de afstemming waardoor jij sneller bij de uitgifteband bent dan je koffer. En of je koffer nu .Net of Java is lijkt me een kwestie van smaak maar je business rules in de database stoppen is volgens mij toch echt een keuze.

Een luchtverkeersleidingssysteem stelt wat andere eisen dan de marketingprulletjes waar jij het telkens over hebt. En internet, toch de basis van cloud, een betrouwbaar netwerk noemen lijkt mij nogal..... Workflows in cloud, ITSM in de cloud en dan straks klagen dat we de regie kwijt zijn omdat de heilige graal cloud service orchestration is. Zeg maar de workload portability die niet om applicaties of platformen maar de informatie gaat.

En hoewel de kaarten betreffende PaaS zeker nog niet geschud zijn lijkt open source tot op heden de troeven te hebben. De redenen hiervoor zijn enigzins divers maar het feit dat het hier community inspanningen betreft zorgt ervoor dat iedereen de huidige stand van zaken kan adopteren en bijdragen aan de verdere ontwikkeling. Vergeet niet dat GNU zo'n beetje internet gebouwd heeft en leuk dat er in de discussie weer een nieuwe definitie toegevoegd wordt met aPaaS maar er zit verschil tussen GPL en AGPL.

Ewout, ik kan me redelijk vinden in je reactie, maar plaats er wel een paar kanttekeningen bij. Zo zie ik mijzelf niet verblind door de cloud, eerder verlicht door de cloud.

Waarom ben ik zo pro cloud computing? Die vraag wordt mij niet gesteld. Het korte antwoord is: Omdat ik van simpel houd. Niet te verwarren met makkelijk. Lange antwoord: Als ik rekenkracht nodig heb, of een OS om iets op te laten landen, dan wil ik niet beperkt worden door "the kingdom of No", ofwel een IT afdeling die nee zegt omdat er geen tijd is, geen capaciteit is, er impact analyses gemaakt moeten worden, er geen groot budget is, het in beheer nemen een heel project is, et cetera. Nu niet roepen "welkom in de enterprise" en dat het in een grote organisatie nu eenmaal niet op zijn boerenfluitjes kan. Dat bedoel ik niet. Er moet wel een plan aan ten grondslag liggen waarin een IT afdeling mee mag praten, maar mijn ervaring is dat de IT afdeling geen trek heeft in dingen die ze niet kennen en een soort levensbehoefte van "Nee" hebben gemaakt en vaak denken in beperkingen. Een goede valide reden voor Nee is er natuurlijk ook, valide redenen zijn bijvoorbeeld: Dat OS is niet de standaard, wildgroei aan applicaties, andere projecten die overlap hebben, et cetera. Je moet dus in je aanvraag voor rekenkracht ook rekening houden met de bestaande conventies en beleidsregels, maar een goed beleid geeft ook ruimte voor proefballonnetjes.

Maar ik ben niet voor cloud om cloud, maar omdat het iets brengt waarin ik geloof.

Nu terug naar de echte wereld.

Ik heb een grote klant met veel servers, databases een datawarehouse, jarenlange opbouw en nu komt er een extra stroom data aan die slechts zijdelings met het primaire productie proces te maken heeft. Deze data stroom zou volgens het beleid via allemaal kanalen, queues, batches, verwerkingen moeten ondergebracht worden in o.a. een Biztalk omgeving. Het raakt wel vijf verschillende personen die hiervoor iets moeten doen en dan zit het in beheer nemen er nog niet eens bij.

Snelle oplossing, knal een queue en een notificatie kanaal open bij AWS, doe 1 call "naar binnen toe" voor een kleine dataverrijking en voila, klaar. Infrastructuur? Check. Voldoende capaciteit en snelle response tijden? Check. Schaalbaar? Check. Bericht naar beheerder met instructie bij faal? Check. Kosten per GB data 10 eurocent. Miljoen berichten? 40 eurocent. Managed omgeving? Check. Stel dat het echt veilig moet dan kunnen deze berichten natuurlijk ook versleuteld worden, dit vergt echter wel wat inspanning bij het begin en endpoint.

Als dit net zo gemakkelijk kan on-premises of je in "private" cloud of hosting omgeving, sure, go ahead. Maar zo is het vaak niet.

Het komt er allemaal opneer dat we in een versnelling zitten qua mogelijkheden, maar dat er veelal nog steeds in traditioneel gedacht wordt. Daarom kunnen startups zo hard gaan en komen er steeds meer grote bedrijven tot stilstand of putten hun bestaansrecht uit een machtspositie.

"Een luchtverkeersleidingssysteem stelt wat andere eisen dan de marketingprulletjes waar jij het telkens over hebt." - Hiermee komt de aap uit de mouw. AWS bombaderen tot marketingprulletjes geeft in mijn ogen aan dat je :

A) Geen vlieguren hiermee hebt, dus niet echt weet waarover je praat
B) Zeer grote organisaties die met deze marketingprul werken blijkbaar in onwetendheid zijn
C) Je blijkbaar bedreigd voelt tegen al dat nieuws en je er daardoor tegenaf zet
D) Je misschien veel verder kijkt dan de rest van ons en het dus echt beter weet.

Uiteraard heb je wel gelijk als je zegt dat ik in de regel met kleinere afdelingen werk en jij wellicht bezig bent met het beheersbaar houden van een gehele organisatie met duizenden medewerkers. Maar ik verzet me tegen de aanname dat grote organisaties zich afzijdig moeten houden van de grote cloud computing providers.

Wat betreft open source en troeven... Dat weet ik zo net nog niet. Ik denk dat open source vooral interessant is voor puntsoplossingen (Applicaties) , maar als je het hebt cloud computing lijkt OpenStack de grootste kanshebber, maar OpenStack is hard bezig zichzelf op te blazen omdat er teveel "coopetition" is. Zie hier een aardige post : http://goo.gl/LGjSie . Vooral de links en reacties onder die stukken (wel uit juli 2013) zijn zeer kenmerkend voor het gevaar waarin OpenStack zich begeeft. Teveel stakeholders die eigen belangen nastreven.

Kortom, ik herken je reactie en die is zeker onderbouwd en is ook de houding die ik veel tegenkom, al dan niet terecht, maar ik geloof in platformen, zoals Steve Jobs zei toen hij Flash vermoordde "Je moet op de schouders van ontwikkelingen kunnen staan om samen verder te komen" en dat is wat een goed platform doet. Je gebruikt een fundament om zelf verder te komen en de kracht zit hem in de mogelijk eenvoud waarbij je vooral bezig houdt met de functionaliteit voor de business en alles eronder als vanzelfsprekend ziet.

Henri,
Amazon is een olifant in IaaS en volgens mij hadden we het hier over PaaS maar ik meen al wat gezegd te hebben over definities en hoe die soms verbogen worden. Betreffende uitspraak over marketingprulletjes moet je ook even een verschil maken tussen een 'stand-alone' en 'connected' oplossing. Als we het over business applicaties hebben dan gaat het meestal om het laatste en dus is de aansluiting op de back-office belangrijk, al was het maar om te voldoen aan wetgeving.

Verder stelde ik in mijn reactie dat de kaarten nog niet geschud zijn, PaaS is nog niet commodity en wordt het misschien ook nooit door teveel bewegende vlakken. Maar de kracht van een community kan dus wel een voordeel geven, Microsoft is hier groot mee geworden op de desktop doordat iedereen er oplossingen op kon maken. Dat open source ook het nadeel heeft van 'forks' zal ik niet ontkennen maar daarover misschien later meer.

Ewout,

Platformen en PaaS is wel erg breed, maar Amazon als IaaS neerzetten is veels te kort door de bocht.

In den beginnen was AWS Iaas (S3, EC2) en Windows Azure PaaS (je kon er geen losse virtuele server op los laten en al helemaal geen Linux). Windows Azure kroop wat meer naar IaaS toe kom toch klanten binnen te houden.

Nu zijn Windows Azure en Amazon Webservices veel, echt heel veel, meer PaaS dan IaaS.

Laat me een paar PaaS producten van Amazon opsommen:
- Redshift (Warehouse)
- Simple notification Services (SNS)
- Simple Queue Services (SQS)
- Simple Email Service (SES)
- DynamoDB (NoSQL Database)
- Elastic Beanstalk (PaaS Zoals Windows Azure Paas Was)
- Data Pipeline
- Et cetera

Windows Azure heeft bijvoorbeeld deze PaaS onderdelen:
- Cloud Services (automatisch deployen van VM's ten behoeven van je software solution, .NET only)
- Active Directory (AD in de cloud met API)
- Biztalk Services
- Mobile Services
- Service Bus
- Management Services
- Web Sites (meer dan hosting, door o.a. autoscaling)

En dan heb ik niet eens over de API's die eigenlijk al per definitie PaaS zijn.

Dit geeft een aantal dingen aan, namelijk dat ontwikkelingen zo snel gaan, dat jij blijkbaar nog ander aannames hebt.

Niettemin ben ik niet blind voor je argumenten en snijden die echt wel hout en is het vaak ook nog de huidige realiteit. We hebben allebei de wijsheid niet in pacht en daarom levert dit ook zulke mooie discussies op.

Ieder zijn eigen waarheid toch?

Henri,
Ik heb natuurlijk niet de wij(ds)(z)e vergezichten van jouw maar als in je gebruikelijke rijtje producten de helft nog niet uit ontwikkeld (beta) is onderschrijft dat volgens mij eerdere opmerking dat op PaaS gebied de kaarten nog niet geschud zijn.

Verder vraag ik me af hoe fijn snelle ontwikkelingen zijn als juist daar de pijn ligt, stem maar eens de wijzigingen in een keten af. Ik ken bedrijven waar niets gewijzigd mag worden als de kwartaal of jaarcijfers opgeleverd moeten worden. Aansluitend op een eerdere opinie over beheer(s)baarheid heb ik hier al gezegd dat je uit snelheid, kwaliteit en kosten er maar 2 kan kiezen.

Als ik de hele discussie eens door worstel, ontkom ik me niet aan het gevoel, hebben ze zichzelf nou wel eens afgevraagd waarom je eigenlijk automatiseert?

Het vehikel IT zal die discussie uiteindelijk volkomen worst zijn. Als een 'ontwikkeling'..... hoe je die ook wil noemen, niet consistent is aan de wetmatigheden van IT. Heb je aan heel die ontwikkeling gewoon niets. Welke boom je er ook op welke wijze over op zet.

Je moet volgens mij gewoon eens even terug naar de basis van hetgeen waarmee je je graag bezig houd. De vraag waarom je automatiseert en de aansluitende vraag, jezelf afvragen of je automatiseren moet. Pas dan ga je eens kijken op welke manier je dat wil doen....

Volgens mij nog steeds voor hetzelfde uiteindelijk. Los van de manier waarop je het professioneel zou willen doen. Dacht ik.

@NumoQuest:

Als ik naar cloudartikelen op deze site kijk dan zie ik:

- Er wordt zoveel langs elkaar heen gediscusseerd en gepraat,
- Reacties die langer zijn dan het artikel zelf,
- Onderwerpen die eerder besproken en behandeld zijn waar nog steeds over gediscusseerd wordt (herhaling van herhaling)

Dat zegt me genoeg hoe wollig dit onderwerp en sommige reacties nog zijn. En ik zie ook nog een nieuwe functie in het cloud-landschap:

Cloud Dominee!

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×