programmeren – JanWiersma.com

Nabrander – Groene software; door beïnvloeden van gedrag

Naar aanleiding van de workshop rond groene software, mijn blog en presentatie daar, zijn er nog een aantal zaken die ontbraken in mijn vorige blog of interessante zaken die voorbij kwamen in de discussie.

1. Virtualisatie.

Zoals de heren van Schuberg Philis lieten zien in hun presentatie, zijn veel systeem resources op servers onderbenut. Virtualisatie kan daarbij duidelijk een rol spelen; het zorgt voor betere uitnutting van de beschikbare hardware. Aangezien een server die niets staat te doen (idle is) toch 40-60% van zijn maximale energie consumeert, levert dit dus energie besparingen op.

2. Strippen en tunen van je server OS.

In de discussie kwam de overhead van besturingssystemen aanbod; In de afgelopen jaren zijn besturingssystemen (OS’en) zoals Windows en Linux uitgegroeid tot alleskunners. De leverancier van het OS weet uiteraard vooraf niet wat de klant er op wil draaien. De ene keer kan het een email servers zijn, de volgende keer een database server. Standaard komt een modern OS dus met een waslijst aan services of daemon’s die aan staan. Daar boven op komen vaak nieuwe services van een virusscanner, een inventory tool, monitoring tool, etc.. Al met al gaan er een hoop computer resources verloren met al deze services en deamon’s.

IT Security specialisten leren ons echter ook al jaren dat je server OS’en dient te ontdoen van al deze overhead. Dit maakt namelijk de mogelijke ingangen voor hackers kleiner. Diverse tools van IT leveranciers kunnen hierbij helpen. Ook kan men steeds meer kiezen voor zo geheten virtual appliances. Deze virtuele servers zijn door de leverancier al gestript en taak specifiek gemaakt.

Het strippen en tunen van je server OS na het installeren van zijn specifieke rol is dus een security en (energie) efficiëntie noodzaak.

3. Is energie afname van software wel te ‘zien’ ?

Er was een kritische kanttekening bij het feit of de energie afname van een query wel te zien was;

Systeembeheerders weten al enige tijd dat het systeem wat zijn in beheer gaan nemen voorzien moet worden van een baseline. Hierbij word basis gedrag van het systeem bepaald, zodat er binnen monitoring en beheer applicaties drempelwaarde gezet kunnen worden om het nieuwe systeem in de gaten te houden. Op deze manier worden de beheerders niet onnodig belast met valse meldingen.

Tijdens een goed OTAP proces met performance testen, worden dit soort baselines opgesteld voor hele applicatie ketens. Dit helpt de test&performance analist om te bepalen hoe de applicatie keten werkt en of deze goed werkt. Deze gegevens kunnen later gebruikt worden om de beheerder te voeden voor zijn baseline.

Als men een goede baseline (op een gestripte server) vast stelt, is het zeer goed mogelijk voor een applicatie ontwikkelaar om relaties te leggen tussen de handelingen die zijn code uitvoert en het gebruik van systeem resources.

4. Server energie afname.

Zoals bij 1 aangegeven gaat ook een hoop energie verloren in systemen die niets staan te doen. Tijdens de discussie gaf dit een opening tot de ontwikkeling van efficiënte hardware. Daar heb ik in vorige blogs al een hoop overgeschreven. Wat nog specifiek het vermelden waard was:

OpenCompute project heeft een OpenRack design uitgebracht waarbij o.a. met DC power gewerkt word in het rack. Servers hier voor zullen binnen kort van HP en Dell op de markt komen. Binnen kort meer…

De Schuberg Philis mannen tipte mij nog een Anandtech artikel over een test met OpenCompute server hardware; http://www.anandtech.com/show/4958/facebooks-open-compute-server-tested

5. IT Energie afname is geen focus voor vele.

Al vroeg tijdens de bijeenkomst viel het feit dat energie afname door IT, voor veel bedrijven geen primaire focus zou zijn. Dat is een punt wat ik onderschrijf, zeker voor bedrijven waarbij ICT niet hun primaire product is maar een ondersteuning. Voor veel van dit soort bedrijven zitten hun grote kosten (OPEX) niet in energie.

In 2009-2010 concludeerde diverse mensen en organisaties al dat de adoptie van energie efficiëntie daar door maar lastig op gang komt. Zolang er voor een bedrijf geen grote financiële motivator onder zit, zal het lastig blijven om hier focus op te krijgen.

De opkomst van Cloud computing en met name bedrijven in de IAAS / PAAS sfeer, helpt om holistisch gezien deze efficiëntie slag wel te maken;

Voor de bedrijven die de IAAS/PAAS dienst leveren is het datacenter en zijn energie afname wel een grote kosten post, zeker gezien de schaal grote waar veel van dit soort infrastructuren op worden gebouwd. Het verhuizen en consolideren van IT services uit de bezemkast van niet-IT-bedrijven naar een Cloud computing provider levert op dit vlak dus een juiste prikkel.

Zoals in mijn vorige blog vermeld, krijgen de gebruikers van de IAAS/PAAS diensten ook een goede prikkel om efficiëntie programmeer code te gebruiken. De pay-per-use modellen in veel Cloud computing aanbiedingen zorgen daar voor;

“the art of efficiënt programming is lost… Cloud will bring it back… “

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)

PAAS & de toekomst van programmeren (2)

PAAS, programmeren en crowdsourcing

Het eerste deel van PAAS & de toekomst van programmeren sloot ik af met het idee dat in de toekomst eindgebruikers (hun) applicaties zouden kunnen schrijven. Als we dit combineren met de technologische mogelijkheden van internet zoals PAAS en wereldwijd bereik van potentiele ontwikkelaars, komen we bij een interessante optie: crowdsourcing.

Conform Wikipedia verstaan we onder crowdsourcing:

…gebruikt om een recente ontwikkeling aan te duiden, waarin organisaties (overheid, bedrijven, instituten) of personen gebruikmaken van een grote groep niet vooraf gespecificeerde individuen (professionals, vrijwilligers, geïnteresseerden) voor consultancy, innovatie, beleidsvorming en onderzoek.

Hierbij is dus het idee om (groepen) mensen aan het werk te zetten om voor jou organisatie applicaties te gaan bouwen. Dit kunnen eigen personeels leden zijn die applicaties bouwen om hun werk beter te kunnen uitvoeren, maar kunnen ook andere mensen zijn. De verleiding tot het bouwen van een applicatie komt vaak in de vorm van een wedstrijd met een (geld) prijs. Daarnaast is het veel deelnemende ontwikkelaars te doen om de eer en de status.

Een aantal ontwikkelingen in de afgelopen jaren maken het bovenstaande echt mogelijk;

Kennis

In 2007 concludeerde de Yankee Group al dat eind gebruikers steeds meer technische kennis bezitten en steeds meer ‘tech-savvy’ worden. Dit beeld werd versterkt met het feit dat steeds meer thuis elektronica zijn intrede deed binnen bedrijven. Dit begon met het zelf mee brengen van een laptop en telefoon/smartphone en de komst van de iPad heeft dit alleen nog maar versterkt. We kunnen niet ontkennen dat generaties die na ons volgen ook vele malen handiger zijn met bijvoorbeeld de PC dan wij zelf.

Platform As A Service

Zoals in het eerste deel vermeld geeft een PAAS omgeving zoals Force.com of Google App Engine, de ontwikkelaar de mogelijkheid om zijn applicatie te bouwen zonder zich druk te maken over de onderliggende technische infrastructuur. Mocht zijn applicatie een succes worden, dan hoeft hij zich ook niet druk te maken over het opschalen van die infrastructuur. Succesvolle diensten kunnen heel snel groeien, denk bijvoorbeeld aan Playfish; Zij bouwde een aantal succesvolle games voor Facebook en iPhone en schoten binnen enkele maanden naar 50 miljoen gebruikers (en werden gekocht voor $300 miljoen door EA). Zonder een flexibel cloud platform was dat niet mogelijk geweest.

Nieuwe programmeer technieken

De manier van applicatie ontwikkeling is veranderd in de afgelopen jaren. Daarnaast zijn er veel tools en frameworks beschikbaar gekomen die het ‘kloppen van code’ makkelijker hebben gemaakt. Er komen ook steeds meer SDK’s beschikbaar die het schrijven van een applicatie voor bijvoorbeeld de iPad makkelijker maken.

(In het vorige deel van de blog is hier voor een deel ook al naar gekeken.)

API’s

API staat voor Application Programming Interface en is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel. Het vormt zeg maar het onafhankelijke koppelvlak tussen aanbieder en afnemer.

Applicaties zijn leuk, maar het gaat uiteindelijk om de data en informatie die er mee bewerkt, bekeken en geproduceerd kan worden. Als een applicatie ontwikkelaar een applicatie gaat bouwen, dient deze wel te weten op welke manier hij de data kan benaderen en welke opmaak deze data heeft. Hierbij komen API’s in beeld; een API definieert de toegang tot de functionaliteit die er achter de API schuil gaat. De buitenwereld kent geen details van de functionaliteit of implementatie, maar weet dankzij de API wel hoe deze kan worden aangesproken.

Steeds meer organisaties en bedrijven publiceren hun data via een API op internet. Door middel van het combineren van API’s kunnen applicatie bouwers hun applicaties verrijken met deze informatie bronnen. Denk hierbij aan de combinatie van Google Maps en foto’s op Flicker via hun API’s. (Dit worden ook wel Mashups genoemd).

Er zijn inmiddels diverse producten op de markt voor de bouw, publicatie en beheer van API’s. Voorbeeld: Apigee (waar je ook uitgebreide kennis over API’s kunt vinden.)

(O ja, en als je die API(’s) dan gaat bouwen… dan graag een RESTfull API…)

Opensource

Over opensource kunnen we lang discussiëren, maar in een model waarbij crowdsourcing voor applicatie bouw word toegepast word de meeste winst behaald door de applicatie onder een opensource model te ontwikkelen. Het beschikbaar hebben van de broncode, levert inspiratie voor andere ontwikkelaars, levert snellere ontwikkeling door hergebruik van code en veiligere applicaties door dat 10 ontwikkelaars meer zien dan 1.

Uiteraard bestaan hier hele, bijna religieuze, debatten over… maar uiteindelijk past dit gewoon goed bij elkaar. Luister maar naar Simon Wardley. (opensource na +/-20min)

Versie- en broncodebeheer

Goed versie- en broncodebeheer is noodzakelijk voor het beheer en onderhoud van de gebouwde applicatie. Het zorgt voor betere onderlinge samenwerking tussen ontwikkelaars, goede registratie en opvolging van software fouten en betere documentatie. In combinatie met opensource geeft het deelnemers aan een competitie ook de mogelijkheid om code en applicatie delen te hergebruiken en sneller een applicatie te kunnen leveren.

Men kan een eigen systeem selecteren en opzetten of gebruik maken van de vele systemen die op internet al beschikbaar zijn. (Tip: gebruik GitHub… het is 1 van de betere op dit moment… en ja deze draait ook ‘in de cloud’, maar is ook geschikt voor closed-source)

Wedstrijdplatform

Om de competitie voor de applicatie ontwikkeling te houden, dient men een wedstrijdplatform te creëren. Hier bij gaat het in de basis om een systeem waarbij
alle benodigde informatie rond de competitie te vinden is en men zich kan inschrijven. Het is nog beter om dit systeem te verrijken team omgevingen die samenwerking bevorderen en verbeteren en met ranglijsten die het spel en uitdagingselement versterken. Voorbeeld: http://www.challengepost.com/

Laten we na al deze theorie en benodigdheden enkele voorbeelden bekijken van crowdsourcing en app ontwikkeling:

Continue with reading

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.

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