PAAS & de toekomst van programmeren (3)

In het laatste deel van het drieluik rond PAAS en de toekomst van programmeren enkele afrondende gedachte;

Platform As A Service (PAAS) gaat in de komende periode een belangrijke doorontwikkeling krijgen en daar door een prominentere rol in het cloud portfolio. Zelfs Amazon ziet de kansen op dit deel van de markt en lanceerde deze week de AWS Elastic Beanstalk. Werner Vogels (CTO Amazon) meld in zijn blog:

…developers who do not need control over the whole software stack often use development platforms that help them manage their application development, deployment and monitoring. There are some excellent platforms running on AWS that do precisely this; Ruby on Rails developers have Heroku and Engine Yard, Springsource users have CloudFoundry Drupal developers can use Acquia, and PHP aficionados can sign up for phpfog, just to name a few. These platforms take away much of the "muck" of software development to the extent that most RoR developers these days will choose to run on a platform instead of managing the whole stack themselves.

Gaat IAAS verdwijnen?

Infrastructure As A Service (IAAS) speelt een hele belangrijke rol; het is cruciaal voor een heleboel innovatie op het gebied van PAAS en SAAS. Veel van de huidige startups rond PAAS en SAAS maken gebruik van IAAS oplossingen zoals die van Amazon. Het feit dat deze bedrijven onbeperkte opslag en rekenkracht tot hun beschikking hebben tegen een pay-per-use model levert een belangrijke bijdrage aan hun succes. SAAS oplossingen zoals Dropbox (gebouwd op Amazon S3 storage) en PAAS oplossingen zoals Heroku (ook op Amazon IAAS), hadden bijvoorbeeld grote moeite moeten doen om het benodigde kapitaal bij elkaar te krijgen om hun groei te faciliteren. Denk hierbij aan de CAPEX die nodig is voor hardware en de OPEX voor de tientallen systeembeheerders om dit alles in de lucht te houden.

IAAS zal hierbij voor de eind gebruiker/enterprise IT naar de achtergrond verdwijnen. PAAS en SAAS zijn nu eenmaal de lucratievere modellen voor de CIO.

En SAAS dan?

Zoals eerder beschreven, zullen commodity IT producten zeer geschikt zijn voor Software As A Service. Daarnaast zullen we zien dat een golf aan nieuwe (internet) applicaties, die geleverd worden als SAAS, zullen ontstaan. Dit komt omdat IAAS en PAAS omgevingen ontwikkelaars gereedschap in handen geeft, die ze nog niet eerder hadden. Dit zal leiden tot vele nieuwe innovaties. De aanwezigheid van App Stores, om een applicatie gemakkelijk in te kunnen aan bieden, versterkt dit.

Helemaal geen programmeurs meer?

In de vorige delen werd aangenomen dat de ‘tech-savy’ eind gebruiker met zijn kennis en de nieuwe technologische mogelijkheden, zelf applicaties gaat bouwen met microfunctionaliteit. Dit betekend echter niet dat we geen programmeurs meer nodig hebben. Het werkveld van de huidige programmeurs zal zich wel verleggen.

De leveranciers van PAAS en SAAS omgevingen hebben grote behoefte aan goede programmeurs. Zeker mensen met kennis van Python, Ruby en/of Java worden veel gevraagd door dit soort bedrijven. Deze markt zal dus uitbreiden.

Voor de organisaties waar IT niet de core business is (zoals enterprise IT), zal er in eerste instantie behoefte zijn aan programmeurs voor data ontsluiting. Denk hierbij aan de bouw en onderhoud van API’s. Zeker in de eerst komende jaren zal slechts niet kritische en commodity ICT (&data) naar de public cloud verdwijnen. De bedrijf kritische data zal intern nog ontsloten moeten worden en mogelijk voorzien van een applicatie set. De organisatie zal echter wel eisen van de IT afdeling dat dit gebeurd op een interne cloud omgeving. Daarnaast wil men de mogelijkheid om de applicatie in de toekomst te transporteren naar de (public) cloud. Dit betekend dat nieuwe applicaties dus wel ‘cloud ready’ gebouwd moeten worden.

Binnen enterprise IT zal er daarnaast altijd behoefte zijn aan het in stand houden van legacy omgevingen. Er zijn nog steeds mensen met COBOL bezig en zo zullen er ook nog mensen bezig blijven met interne (legacy) Java en .NET applicaties.

Naar mate er meer mogelijkheden komen voor eind gebruikers om hun eigen (micro)functionaliteit te bouwen, zal de behoefte voor grote interne applicaties afnemen. Daarmee neemt de behoefte aan interne programmeurs ook af. De behoefte aan goede data ontsluiting, via API’s, zal hierbij toenemen. Ook bij de inzet van crowdsourcing voor applicatie bouw, zien we dat de programmeur geen onderdeel meer behoeft te zijn van de organisatie. 

Welke skills worden belangrijk voor programmeurs?

Al eerder is aangegeven dat het ontwikkelen van applicaties op een cloud platform iets anders is dan de traditionele IT applicaties. Bij het ontwerpen van een cloud applicatie dient men er rekening mee te houden dat systemen zullen uitvallen in een cloud omgeving. Het ontwerpen rond ‘applicatie redundantie’ is belangrijk. Hierbij werd al eerder opgemerkt: ‘Cloud applications assume failure.’

Het bouwen van cloud applicaties vereist het ontwerpen van stateless applicaties. Zodra er iets niet meer werkt of reageert binnen een cloud omgeving, is het idee dat je deze instance verwijderd (kill) en een nieuwe start. Dat werkt niet als de state ook opgeslagen is binnen deze instance. Ook het concept van een lokale disk is niet aanwezig; er is bijvoorbeeld geen registry. Veel applicatie bouwers hebben vroeger wel geleerd om netjes met ‘state’ om te gaan, maar zijn dit een beetje verleerd omdat de huidige IT dat niet echt afstrafte. Gemakkelijke applicaties zijn vaak stateless. Pas bij de echte interessante applicaties komt een bepaalde mate van state om de hoek kijken. Hier voor zijn in de cloud wel databases en objectstores beschikbaar. Echter de applicatie onderdelen die snel moeten kunnen schalen zoals de web-front-end, moeten stateless zijn.

Daarnaast zijn veel cloud applicaties versplinterd; de applicatie presentatie laag kan bijvoorbeeld op Facebook zijn, de opslag op Amazon S3 en de applicatie logica bij een andere cloud provider. Dit betekend dat er goed nagedacht moet worden over de architectuur, met de nadruk op de schaalbaarheids mogelijkheden die deze platformen bieden.

Voor het vastleggen van de data en state, zijn diverse mogelijkheden in cloud omgevingen die echt anders zijn dan de traditionele IT. Denk hierbij aan de inzet van niet relationele databases. Zowel het Windows Azure platform als de Google App Engine, geven de ontwikkelaar een andere manier om met data om te gaan;

The uses of abstraction and statelessness also have database implications. For example, Azure presents developers with a different perspective on databases than the standard relational model, said Ben
Day, president of Benjamin Day Consulting. The Azure storage engine does not use a standard relational database, so a lot of the stuff you would do if you were developing a standard app using a standard relational database just doesn’t make a lot of sense anymore. An example: the relational database concept of stored procedures, in which query logic is close to the actual data itself. This is no longer applicable in the Azure cloud.

The problem is with Azure is there’s no guarantee that the data that you’re going for lives in any particular location or datacenter or any particular device. You end up writing basically SQL queries against the store because the stored procedures aren’t relevant anymore. Plus, the Azure storage engine is different than the SQL Data Services cloud-based version of SQL Server. As an example, Azure stores a 1MB file as a blob, unlike SQL Server, which stores it in a table.

Bij de Google App Engine, word voor opslag Google’s Big Table gebruikt. Dit is ook geen SQL database. Daarnaast zien we de opkomst van technieken zoals Hadoop voor de verwerking van grote hoeveelheden data.

Daarnaast hebben we de opkomst van diverse nieuwe/andere talen en frameworks. Hierbij zal zullen Java en .NET voorlopig nog niet uitsterven, maar is het wel verstandig voor programmeurs om zich eens te verdiepen in de leidende cloud talen op dit moment.

Op het persoonlijke ontwikkelingslijstje van de programmeur zou dus moeten staan:

• Verdiepen in Ruby en/of Python.
• Verdiepen in (nieuwe) frameworks i.r.t. cloud (zoals de recente ontwikkelingen rond Springsource).
• Verdiepen in API’s (REST, JSON, XML), want dit word je koppelvlak met data uit diverse bronnen.
• Verdiepen in andere manieren van data opslag en omgang zoals Hadoop, etc..

Dit alles zou je kunnen starten door eens mee te doen aan lopende prijsvragen voor crowdsource applicatie bouw. Leer je programmeren voor de cloud en misschien hou je er nog een zakcentje aan over 😉

Als ik dit alles zo zie, breken er gouden tijden aan voor programmeurs…

Boek tip: Cloud Application Architectures: Building Applications and Infrastructure in the Cloud (George Reese, 2009)