JanWiersma.com

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)

Share

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;

image_2

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.

The advantages of PaaS are

  • 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.

Continue with reading

Share

En dan… die applicatie naar de Cloud toe…

Cloud Applicatie Migratie

Na het doen van de nodige research, lezen van blogs en whitepapers, bezoeken van seminars en praten met leveranciers… heb je nu besloten dat Cloud de stip aan de horizon moet worden voor je organisatie. Maar hoe ga je daar komen ? Hoe hervorm je de huidige IT spaghetti naar deze utopische Cloud wereld ?

De eerder gepubliceerde whitepaper rond cloud strategie geeft aan:

De migratie naar externe Cloud computing heeft een significante impact op een IT organisatie, de leveranciers rol van de IT organisatie en de manier waar op applicaties ontwikkeld worden en gebruikt.
Omdat men groeit vanuit een interne IT omgeving naar meer verbruik van externe Cloud computing omgevingen, moet men rekening houden in de architectuur met samengestelde applicaties.

De whitepaper geeft ook aan dat er verschillende verschijningsvormen van Cloud zijn zoals SaaS, PaaS en IaaS. De stap vanuit de huidige enterpise IT omgeving naar elk van deze verschijningsvormen kent zijn eigen karakteristieken. Een van de beste benaderingen voor cloud migratie is de huidige IT omgeving te bekijken van de applicatie of dienst zijde;

Niet alle applicaties zijn op dit moment geschikt voor een migratie naar een externe Cloud omgeving. Goede kandidaten zijn applicaties die niet missie kritiek zijn, matige tot geen integratie kennen met andere belangrijke applicaties en niet van strategische (competitieve) waarde zijn voor de organisatie. Om beveiligingsrisico’s te verminderen, zou de applicatie ook geen sensitieve informatie moeten bevatten. Naar mate de volwassenheid van externe Cloud omgevingen toeneemt, zullen meer applicaties de stap kunnen maken naar deze omgeving.

Waar de whitepaper vrij snel in gaat op applicaties die potentieel gemakkelijk te migreren zijn, wilde ik dat even in wat bredere context zetten en verkennen: “Cloud Applicatie Migratie, hoe doe ik dat ?”

Een applicatie op een cloud platform is iets anders dan een applicatie in de traditionele IT omgeving. In de recente afscheidsblog van Ray Ozzie ((ex-)Microsoft) schrijft hij over de toekomstige uitdagingen van de nieuwe naadloos schaalbare computing modellen. Het idee dat men ‘zo maar’ bestaande applicaties kan overzetten op dit soort modellen werkt niet. Software vandaag de dag is daar meestal gewoon niet voor gemaakt. Veranderingen rond de user interface (zoals touch screens), data management (zoals niet-relationele data modellen), horizontaal kunnen schalen en zelfs programmeer stijlen (zoals ‘fail-ready’ software) zorgen er voor dat bestaande code meestal niet direct geschikt is voor echte cloud computing omgevingen.

Om te beginnen is een Applicatie Portfolio Analyse de belangrijkste actie. Deze kan echter snel uit de hand lopen als het doel er van niet helder beschreven of begrepen is. Of een applicatie of dienst geschikt is voor een cloud computing omgeving zal getoetst moeten worden door rationalisatie van de portfolio. Deze rationalisatie kent meerdere dimensies, die de applicatie toetsen tegen de  karakteristieken van een ‘cloud applicatie omgeving’ en de geschikte migratie optie (private of public cloud) en het geschikte migratie pad (IaaS, PaaS of SaaS) selecteren. Daarnaast dient een kosten analyse de impact op TCO & ROI te bepalen en te helpen om een business case te bouwen.

Bij de rationalisatie van een applicatie voor cloud computing kan men de volgende 4 aandachts gebieden bekijken

image

(Vrij naar sys-con.com )

Hierbij kan men de volgende indicatieve richtlijnen volgen om te bepalen of een applicatie of dienst klaar is voor cloud;

  1. Elasticiteit kan gemeten worden langs drie parameters: workload, storage, utilization. Het is belangrijk om een dergelijke karakteristiek van de applicatie te hebben zodat bepaald kan worden of en hoe deze op een cloud platform kan landen. Deze gegevens zijn vaak te halen uit monitoring tools of log files in de bestaande omgeving.
  2. Bij een negatieve impact op Governance (SLA, beveiliging, wet en regelgeving, etc..), levert dit meteen een ‘veto’ op om een applicatie of dienst niet naar de public cloud te verhuizen.
  3. De technische haalbaarheid; de impact op de architectuur van de applicatie en de impact op de kwaliteit van de dienst verlening moeten goed overwogen worden.
  4. Functionele toekomstvastheid van de applicatie.

Door het toepassen van een score model op de bovenstaande aandachtsgebieden, zou men goed inzicht moeten krijgen op de cloud geschiktheid van de applicatie of dienst.

Hoewel een public cloud infrastructuur veel voordelen kan beiden (bijvoorbeeld in schaal en kosten) die niet mogelijk zijn in een eigen (private) cloud omgeving, zullen bepaalde applicaties nooit naar de public cloud verhuizen. Dit zal vooral het geval zijn bij de kroonjuwelen van een organisatie; informatie die missie kritiek is of een hoge gevoeligheid heeft.

De business case voor cloud applicatie migratie is niet compleet zonder rekening te houden met het doel platform; private of public cloud. De migratie en overhead kosten variëren behoorlijk bij deze keuze en beïnvloeden daar mee ook de totale besparing die te behalen is. Een goede kosten analyse helpt bij de keuze om een applicatie wel of niet te verhuizen en de te verwachte TCO/ROI.

Kosten analyse zou ten minste CapEx, OpEx en Overhead moeten bevatten. Hier onder kunnen we o.a. de volgende elementen verstaan:

  • CapEx
    • Servers
    • Storage
    • Backup
    • Netwerk apparatuur
    • Vastgoed (datacenter)
  • OpEx
    • Energie
    • Personeel
    • Bandbreedte
    • Onderhoud
    • Licentie contracten
  • Overhead
    • Migratie kosten
    • Skills
    • Governance

Applicaties en diensten die worden aangeboden op een eigen (dedicated) infrastructuur zijn goede potentiele kandidaten voor migratie naar een cloud infrastructuur. Het bepalen van de kosten voordelen voor deze applicaties zou redelijk makkelijk moeten zijn. Voor applicaties die een gedeelde infrastructuur kennen, moet er mogelijk een specifieke workload analyse gemaakt worden om de potentiele besparingen te bepalen.

Migratie strategie

Het vast stellen van een applicatie migratie strategie betekend dat men bekend moet zijn met de diverse migratie mogelijkheden, opties en organisatie doelstellingen. De uitdaging zit in de balans tussen organisatie prioriteiten en kosten. Als basis hebben (enterprise) organisaties twee keuzes voor cloud infrastructuren; public en private. Hierbij zijn de volgende migratie paden een optie; IAAS, PAAS, SAAS. De keuze word gedreven door zaken als elasticiteit, business model en information2.0/technologie2.0 strategie (zie: The New Normal). De keuzes worden beperkt door factoren als technische haalbaarheid, beveilging, migratie kosten, etc.. Het is daarom niet ongewoon dat grote organisaties kiezen voor een hybride cloud strategie waarbij men gecontroleerd kan evolueren.

tweet1

Het is belangrijk om te beseffen dat het werken met een applicatie portfolio rationalisatie die leid tot 1 migratie strategie voor alle applicaties niet behulpzaam is. De migratie strategie zal per applicatie of dienst bepaald moeten worden en door ontwikkelen. Dit na een goede evaluatie van de bekeken applicaties op de eerder geschetste vlakken. De uitdaging op bijvoorbeeld hardware infrastructuur en architectuur gebied die samenhangen met een cloud migratie, moeten onderdeel worden van de totale migratie strategie. Bekijk de dienst of applicatie hierbij vanuit de totale IT stack om zo de samenhang te ontdekken en in kaart te brengen.

tweet2

Migratie paden

De migratie van een applicatie waarbij men de onderliggende server infrastructuur verhuist naar een public of private IAAS omgeving levert een snelle manier om enkele voordelen van de cloud mogelijkheden te plukken. Dit soort migraties zijn ongecompliceerd door dat het slechts het verhuizen van de host betreft en geen aanpassing in de applicatie code. Het mag echter ook duidelijk zijn dat dit soort migraties slechts een klein deel van de voordelen van cloud computing oplevert. Voorbeeld van bovenstaande services zijn Amazon EC2 of Rackspace.

De migratie naar een echte SAAS architectuur en de hosting daar van op een omgeving die tientallen tot honderden klanten kan bedienen (multi-tenant) levert de grootste kosten voordelen op voor enterprise organisaties. Het helpt ook bij applicatie rationalisatie door applicaties met gelijke functionaliteit samen te brengen en deze enkele SAAS applicatie te bieden op een gedeelde infrastructuur. Migratie van een applicatie naar een volledige SAAS omgeving kan echter een ontmoedigende bezigheid zijn, omdat de meeste applicaties niet geschikt zijn voor deze nieuwe (multi-tenant) cloud architectuur. De beweging naar een SAAS omgeving zal derhalve eerder een vervanging van de bestaande applicatie door een SAAS in houden. Voorbeeld eigen enterprise CRM door Salesforce.com. De sleutel hierbij is het feit dat er gebruik gemaakt word van een basis applicatie code die voor alle honderden klanten word gebruikt en het toestaat om daar boven op specifieke uitbreidingen toe te passen (plugin, mashup of widget).

Als tussen model heeft men PAAS; Leveranciers als Google App Engine en Microsoft Azure leveren een complete cloud IT stack voor software ontwikkeling en levering. Dit levert de mogelijkheid om ‘echte’ cloud applicaties te bouwen en uitleveren op een schaalbare en elastische omgeving. Dit levert echter ook een hoop beperkingen op, op elke technologie laag van de applicatie stack. Vanwege deze beperkingen is het vaak lastig om bestaande applicaties en code over te zetten op deze nieuwe cloud omgevingen. Dit zit soms in de applicatie code en het feit dat programmeurs soms ‘vergeten’ zijn om netjes te programmeren (voorbeeld stateless/statefull). Waar dit in huidige silo IT omgevingen geen problemen oplevert zie je dat dit op gedeelde PAAS en SAAS omgevingen wel een uitdaging geeft. Om deze redenen leent PAAS zich vooral goed voor ‘Greenfield’ acties.

Planning en implementatie

Als we kijken naar een applicatie cloud strategie, word er vaak gekeken naar de technische migratie consequenties. Men moet echter niet vergeten dat de introductie van cloud technologieën ook effect heeft op de organisatie. Bij de migratie moet men rekening houden met het wijzigen van de functie en rol van beheer bijvoorbeeld.

Ook moet men rekening houden met het effect op (bestaande) SLA’s, Service management, onderhouds contracten, door belasting methodes, en skill sets. Hier over in een later blog meer.

tweet3

Zodra men klaar is om de stap naar een cloud omgeving te maken dient er eerst goed naar de huidige applicatie en diensten porfolio gekeken te worden. Er dienen duidelijke landingsplaatsen gedefinieerd te worden zoals private en public cloud en routes zoals IAAS, PAAS en SAAS. Per applicatie moet bepaald worden of deze afsterft in de huidige infrastructuur en word vervangen door een applicatie in een cloud omgeving. Door het toetsen van de applicatie met behulp van enkele cloud basis elementen en het kijken naar de kosten van de applicatie kan er een route naar de toekomst worden uitgezet met een goede business case.

Dit alles kost de nodige inspanning, maar is noodzakelijk voor het slagen van de cloud transitie.

Zie ook:

‘Moving to’ versus ‘building for’ cloud computing

Hands-on migratie analyse voorbeeld: Migration steps to a private cloud

Share