PAAS & de toekomst van programmeren (1)
Cloud deed het goed in 2010. Vooral rond Software As A Service (SAAS) waren een hoop aankondigen van enterprise organisaties die overstapte. Denk aan Ahold die naar Google Apps ging, diverse US overheid instellingen die naar Microsoft BPOS gingen, maar ook SalesForce zijn CRM deed het weer goed in 2010.
Op de Infrastructuur As A Service (IAAS) waren enkele kleine lichtpuntjes te zien aan de eindgebruikers kant. Zo zetten de Amerikaanse overheid een RPF in de markt voor IAAS. Aan de aanbodzijde zagen we een explosieve groei. Naast de bestaande spelers kwamen er vooral veel hosting en co-lo bedrijven bij die de cloud markt betreden met een IAAS aanbieding. Op het vlak van IAAS kunnen we ook concluderen dat er redelijk wat volwassen technologieën bestaan die het makkelijk maken om een IAAS service uit te rollen.
De inzet van IAAS levert organisaties de mogelijkheid om flexibel opslag en rekenkracht af te nemen. Dit vaak in een pay-per-use model. De eindgebruiker blijft echter nog wel verantwoordelijk voor een hele hoop technisch beheer. Denk aan het besturingssysteem, database en eventuele applicaties. Ook de licenties en onderhoudscontracten hier op zijn voor rekening van de eindgebruiker.
Zoals eerder beschreven hebben we bij de traditionele IT zelf de controle over alles inclusief de, zelf bedachte, architectuur die alle lagen in de IT stack aan elkaar bind. Als we gebruik gaan maken van cloud geven we een gedeelte van deze controle uit handen;
Hoe hoger we in de bovenstaande ‘cloud stack’ (bron: Lori MacVittie) komen; hoe minder de organisatie zelf doet aan de ICT voorziening. Hoe hoger we in de stack komen, hoe dichter we zitten bij de waarde creatie van ICT voor de business; want laten we wel wezen het gaat om de applicatie. Maar ook hoe hoger we in de stack komen, hoe minder eigen controle. Hoe hoger we in de stack komen, des temeer we ons aan standaarden en referentie architectuur van de leverancier dienen te houden.
Bepaalde applicaties, zoals een tekstverwerker, zijn commodity ICT. De functionaliteit voor de tekstverwerker is voor veel bedrijven het zelfde en het is een dus danig uitgewerkt en beschikbaar concept, dat de organisatie er geen competitief voordeel haalt uit het hebben van een tekstverwerker. Dit soort applicatie lenen zich dus uitstekend voor SAAS. Echter niet alle applicaties in een enterprise organisatie zijn commodity. Hier komt Platform As A Service (PAAS) in beeld. Het kent minder restricties (en dus meer controle) dan SAAS, maar minder beheer (en benodigde kennis van de onderliggende infra) dan IAAS. Binnen de PAAS omgeving kan een applicatie ontwikkelaar een applicatie ontwikkelen voor de organisatie zonder zich echt druk te maken over de onderliggende lagen en techniek.
- Complete abstraction all the way up to development environments and other middleware components, taking the operations out of the picture
- Considerable cost savings and faster time to market
- Better security. As Chris Hoff pointed out, one could enforce sanitary programmatic practices across the derivate works built upon PaaS
PAAS in beweging.
De markt rond de leveringen op PAAS gebied is volop in beweging. James Urquhart meld in zijn 2010 jaar overzicht;
11. Platform as a Service steps up its game
VMware announced its Cloud Application Platform. Salesforce.com introduced Database.com and its acquisition of Ruby platform Heroku. Google saw demand for developers with App Engine experience skyrocket. Platform as a Service is here, folks, and while understanding and adoption of these services by enterprise IT still lags that of the Web 2.0 community, these services are a natural evolutionary step for software development in the cloud.
We zien VMware bewegen naar PAAS met hun overname van Spring Source en later de samenwerkingen met Google App Engine en SalesForce.com. Microsoft beweegt zich op het PAAS vlak met Azure, Google met App Engine en diverse startups zijn ook erg succes vol met hun PAAS oplossing (zoals Heroku; verkocht voor $212 miljoen).
Veel leveranciers van huidige IAAS oplossingen zien de nadelen van IAAS en voordelen van PAAS… even als hun klanten, die met IAAS nog niet in het beloofde IT landschap komen wat Nick Carr in zijn boek The Big Switch schetst.
Even een applicatie bouwen?
Zo’n echte PAAS omgeving is echter wel iets anders dan dat de ontwikkelaar gewend is in een traditionele enterprise IT omgeving. De afnemer van PAAS verwacht immers dat deze mooie cloud omgeving voldoet aan alle cloud karakteristieken zoals onbeperkte schaalbaarheid, pay-per-use, elasticiteit, etc.. Dit alles uiteraard zonder dat hij zich druk hoeft te maken over de werking hier van. Daarnaast heeft de aanbieder van PAAS vaak de uitdaging om deze omgeving voor multitenancy te bouwen; schaalgrote en meerdere gebruikers stapelen op 1 platform levert immers geld op.
Gartner schreef in Designing to fail;
Cloud-savvy application architects don’t do things the same way that they’re done in the traditional enterprise.
Cloud applications assume failure. That is, well-architected cloud applications assume that just about anything can fail. Servers fail. Storage fails. Networks fail. Other application components fail. Cloud applications are designed to be resilient to failure, and they are designed to be robust at the application level rathe
r than at the infrastructure level.…
Cloud applications assume variable performance. Well-architected cloud applications don’t assume that anything is going to complete in a certain amount of time. The application has to deal with network latencies that might be random, storage latencies that might be random, and compute latencies that might be random.
…
But most existing traditional enterprise apps don’t deal well with variable performance, and that’s a problem that will be much trickier to solve.
Bij dit alles lopen we dan al snel aan tegen de beperkingen van de traditionele programeer talen en frameworks die jaren lang gebruikt zijn in enterprise IT. Leveranciers van PAAS omgevingen zijn zich hier van bewust en zoeken andere programmeer talen en frameworks die in de behoefte kunnen voldoen. Ook zien we diverse ‘nieuwe’ talen die gebruikt worden door de leveranciers van SAAS applicaties zelf om hun schaalbare SAAS omgevingen te kunnen bouwen en aanbieden.
Als we kijken naar het applicatie en framework landschap wat er ontstaat zien we een grote diversiteit. Een greep:
- Ruby on Rails; Force.com (SalesForce onderdeel) zet stevig in op Ruby met de overname van Heroku. Ook Engine Yard levert hier een platform voor.
- Phython;
- JavaScript; maakt een comeback met de ondersteuning van Node.js.
- Google Go; gebruikt door Google intern.
De meeste PAAS leveranciers wedden echter niet op 1 paard als het gaat om talen en frameworks. Zo ondersteund Microsofts Azure zowel .NET als Java. SalesForce gaat voor Java (samen met VMware) en voor Ruby (met de overname van Heroku). Google geeft op hun App Engine ondersteuning voor Python, Ruby en Java.
Om het slagveld op dit moment nog groter te maken zien we op het web front dat men steeds meer Adobe Flash overboord zet en deze vervangt voor HTML5. Dit lot lijkt MS Silverlight ook te treffen.
De vraag is welke talen en frameworks dit gaan overleven…
Toekomst voor Java?
Java is voor veel enterprise organisaties het dominante platform. Dit vaak in twee strijd met het .NET platform van Microsoft en legacy talen zoals COBOL. Gezien de verwevenheid van dit platform en de investeringen hier in, zal dit voor veel organisaties nog wel even zo blijven. Rond Java zijn echter een aantal interessante ontwikkelingen gaande. Sinds de overname van SUN (eigenaar van Java) door Oracle, is er ruzie binnen de Java Community Process (JCP). Binnen dit overleg orgaan word de toekomst van Java al sinds 1998 bepaald. Recent besloot Apache Software Foundation uit de JCP te stappen omdat ze het niet eens zijn met de roadmap voor de volgende Java versie’s. In het afgelopen jaar stapt ook andere belangrijke leden al uit dit orgaan zoals Doug Lea. In 2010 volgde een hele serie aan ‘slecht nieuws’ rond de Java roadmap, gemeenschap en toekomst. We zien dat Oracle kiest voor een veel commerciëlere insteek rond Java, dan dat SUN dat deed. Dit past ook bij het business model van Oracle; geld verdienen uit licenties en onderhoud daar op.
Een deel van de gemeenschap heeft het idee dat al dit slechte nieuws zal leiden tot het zelfde lot als COBOL beschoren is; nog veel gebruikt maar niet langer cutting edge. Een ander deel is van mening dat Java op dit moment al (technologisch) achter ligt en enkel radicale wijzigingen in techniek en organisatie (waar onder de community) nog verbetering kunnen brengen.
De mannen van Eclipse (Ian Skerrett & Mike Milinkovich ) geven aan in hun blogs dat Oracle vooral moet leren hoe om te gaan met een ontwikkelaar gemeenschap zoals die van Java:
Oracle; I hate to tell you but you need some help with the Java community. The basic problem is that people don’t trust you and you aren’t very good at community building; in fact you are pretty bad at community marketing.
…
Right now lots of people are talking about Java but there is a silent void from you. The conversation is happening and you aren’t participating, so people speculate and hypothesize; not great for building trust.
Al met al; ‘Scary Times in Java Land’ en daarbij moeten enterprise organisaties zich bezinnen op de toekomst van de door hun gekozen applicatie frameworks en talen. Zeker met de opkomst van Cloud, App Stores en nieuwe devices zoals Apple iPad en Galaxy Tab (Andriod).
Gaan we nog wel programmeren ?
Omdat we de opkomst van andere talen en frameworks zien in relatie tot cloud en omdat er duidelijk is dat het ontwikkelen en ontwerpen van cloud applicaties toch echt andere competenties behelst, zullen enterprise organisatie in 2011 zich de vraag moeten stellen; heb ik die competenties in huis ? moet ik die gaan ontwikkelen ? gaan we zelf mensen opleiden of laten we ontwikkeling buiten de deur doen ?
Als het aan Dr Donald Ferguson (CTO van CA Technologies) is dat niet de toekomst:
Now we have a new generation of workers with fairly sophisticated IT skills who can create these apps themselves.
I call it end-user programming.
Once there were a few hundred apps running on a company’s servers, each used by thousands of people, and the IT team hoped for slow change of these apps. In the future, there will be tens of thousands of apps, each used by a small group. Companies like Salesforce.com with its force.com platform allow everybody to write apps.
End users will provide the applications, and we will provide just the feed, the data, the callable APIs [that power the apps].
Cloud computing will be a platform for these services.
Deze programmerende eind gebruikers hebben helemaal geen zin om diverse talen te moeten leren… en misschien hoeft dat ook niet. Zoals Ron Tolido (CTO CapGemini) merkte recent terecht op in een Twitter conversatie:
Volgens Matt MacLaurin van het Kodu project kan het ook anders;
“Our society thinks of computer programming as lucrative, therefore it must be hard and dull,” says the leader of the Kodu project, Matt MacLaurin. He says software development should be like a fourth-gr
ade art class: explore, create, discover.
En misschien is dat wel de toekomst van programmeren; ‘end-user programming’ op een manier die een 8 jarige begrijpt.
Meer leesvoer rond PAAS:
6 comments