New technology – Page 2 – JanWiersma.com

Lager kosten=groei; Jevons Paradox

De afgelopen tijd heb ik een aantal keer Jevons paradox gebruikt in presentaties rond cloud.
Het idee en concept achter Jevons paradox in combinatie met cloud computing komt volledig uit de koker van Simon Wardley.
Voor die gene die zijn briljante presentatie(s) nog niet eerder hebben gezien:

[youtube=http://www.youtube.com/watch?v=5Oyf4vvJyy4&w=448&h=252&hd=1]

In zijn verhaal gebruikt hij vaak het voorbeeld van product naar diensten (services/utility) ontwikkeling.
Deze zien we terug bij de ontwikkeling van elektra. Deze gaat van de uitvinding van elektra en zijn mogelijkheden (innovatie), via Custom Build waarbij iedereen zijn eigen elektra opwerkte naar Utility levering waarbij we elektra uit de muur kunnen halen en ons niet meer druk maken over wat er eigenlijk allemaal ‘onder’ zit.
Deze ontwikkeling zien we ook terug bij de PC en ook bij de ontwikkeling van CRM. Daarbij zijn we gegaan van custom CRM systemen naar Salesforce vandaag de dag.

Als we de curve omhoog volgen zien we ook dat het product wat deze ontwikkeling volgt, steeds meer standaard word. Hierbij hebben we het dan over het toepassen van (internationale) standaarden, maar ook het feit dat een product zo algemeen beschikbaar is dat deze je als organisatie geen concurrentie voordeel meer beid; iedereen heeft het of kan het kopen.
Het zorgt er ook voor dat men de Utility tegen lager kosten kan af nemen of tegen een pay-per-use model. Hier door word het product beschikbaar voor een grotere groep mensen of bedrijven.

We zien ook dat het product dat een Ultility en zo algemeen beschikbaar, weer een nieuwe golf van innovatie teweeg brengt.
Bij de ontwikkeling van elektra was dit ook te zien; mensen en bedrijven behoefde niet langer te investeren in eigen ‘energie centrales’ waar door de consumptie voor meer mensen mogelijk werd en de consumptie van het product omhoog ging.

Jevons paradox

De toepassing van Jevons paradox op deze ontwikkeling zegt (op hoofdlijnen), dat als de kosten omlaag gaan de consumptie van het product stijgt.

Deze paradox is ook van toepassing op diverse IT ontwikkelingen.
Een uitstekend voorbeeld wat ik in de praktijk diverse malen mocht tegen komen is de inzet van virtualisatie.
Door de time-to-market te verlagen naar 2 dagen (van 6 weken) en de kosten te verlagen (soms met 75%) per te leveren server, kon er meer gedaan worden aan IT innovatie tegen lager kosten dan voorheen.
Hier door steeg de vraag naar een virtuele server explosief.
Dit fenomeen, wat ook wel bekend is als VM-sprawl, kun je zien als iets negatiefs maar dat is het zeker niet. Als jij de business kan helpen met snellere
innovatie tegen lager kosten, dan doe je het juist heel goed.
Daar waar de business dacht slechts 3 innovaties te kunnen door voeren dat jaar… en het worden er nu 7… dan lever jij een concurrentie voordeel voor jou
organisatie t.o.v. de rest van de markt.

Jevons paradox en Cloud

Jevons paradox is ook van toepassing op cloud computing.
Met cloud computing word het gebruik van 1000-en compute nodes beschikbaar voor iemand met slechts een credit card. En als hij klaar is… dan betaald hij ook niets meer. En dat zonder torenhoge start kosten om die nodes te moeten kopen, bouwen en onderhouden.
Deze manier van levering en het feit dat het ontzettend toegankelijk is, zullen zorgen voor een explosieve groei op dit vlak.

De meeste organisaties vandaag de dag, zitten vast in hun huidige complexiteit en hoge beheerskosten. Hier door is er weinig tot geen ruimte meer voor innovatie.
Door de onderliggende lagen van de IT infrastructuur als een utility af te nemen, zodat men zich hier niet langer druk over hoeft te maken, kan men ruimte creëren voor nieuwe innovatie.

Dit alles betekend echter dat op langere termijn de complexiteits uitdagingen zich zullen verplaatsen naar de hogere lagen van de IT Stack.
Dat is ook de plek waar we vandaag de dag een hele boel uitdagingen hebben waar we niet echt goed aan toe kwamen. Denk bijvoorbeeld aan de explosieve data groei.

Christian Belady (Microsoft) paste recent ook Jevons paradox toe op de ontwikkeling van de datacenter markt. De afgelopen jaren kende de markt voor bouw en ontwikkeling van datacentra een expolieve groei;

Jevons’ Paradox has been one of the reasons given for the incredible growth we are seeing with online services. The explosion of services now available on the internet has fueled one of the fastest growing industries today: Datacenter construction.

Dit alles is ook logisch omdat al die cloud omgevingen wel ergens gehuisvest moeten worden. Aangezien het verbruik zal toenemen, zullen er ook meer (of grotere) datacentra gebouwd moeten worden om aan al deze vraag te kunnen voldoen.

Uiteindelijk zal al deze ontwikkeling er voor zorgen dat vele (niet ICT) organisaties een volgende stap kunnen maken in hun eigen innovatie en ontwikkeling. Dit alles ondersteund door IT, die niet langer een beperking is maar een katalysator.

En over 10 jaar? Dan zitten we weer om de tafel; om de complexiteit in de hogere lagen van de IT stack op te lossen… ICT blijft een mooi vak 😉

Datacenter temperatuur & ARBO

Naar aanleiding van mijn blogs over temperatuur verhoging (recent en in het verleden) en presentaties die ik daar over gegeven heb, kreeg ik vragen over de nieuwe omgevings condities en of je daar in wel mag werken.

De vraag: als de inlet temperatuur van servers naar 27C of hoger gaat (in de koude gang), dan word de achter kant (warme gang) wel heel erg warm (40+). Daar kan ik dan niet fatsoenlijk meer werken zonder een zwembroek.

Toen ik in 2007 verantwoordelijk werd voor o.a. het beheer van een datacenter, heb ik door een ARBO dienst een onderzoek laten uitvoeren naar de werkomstandigheden in een datacenter. Voor de temperatuurs condities was het volgende grof weg het antwoord:

Met de invoering van het arbobesluit in 1997 werd de zogenoemde PMV-index gelanceerd. Deze index is de uitkomst van een uiterst ingewikkelde berekening die allerlei zaken meeneemt: temperatuur, luchtvochtigheid, luchtsnelheid, kleding en te verrichten werkzaamheden.
De stelling is vervolgens dat het binnenklimaat behaaglijk is als de PMV-index tussen de 0,5 en -0,5 ligt of als minder dan 10% van de werkzame personen klachten over het klimaat meer zal hebben. Een overschrijding van deze normen gedurende 10% van de werktijd wordt overigens acceptabel gevonden. Het probleem is dat deze officiële norm heel ingewikkeld in elkaar zit: het vraagt een hoop meet- en rekenwerk.

Als je naar de onderliggende onderzoeken en documenten kijkt, zien we dat boven de 26C spraken is van extra belasting. Die grens word vooral bepaald door de lichamelijke inspanning van het werk. Zo is bij licht kantoor werk 30C de grens en bij zware lichamelijke inspanning 25C. Ook maakt het uit of er een voelbare luchtstroom is. Deze zorgt namelijk voor verlaging van de gevoelstemperatuur. Boven de grens moet de werkgever inspanningen doen om de belasting te verlagen. Dit kan zijn door korter werken, zo kort mogelijk aaneengesloten werken, pauzeren in koele ruimtes, aangepaste kleding, extra ventilatie, veel (sportdrank) drinken.

Als we naar de datacenter omgeving kijken zien we dat deze temperatuur grens al snel gereikt word, ook in een traditionele omgeving. Neem een omgeving met server inlet temperatuur van 21C en blade servers met een delta T van 15C (verschil tussen voor en achter kant), dan komen we op 36C in de warme gang.

Bij temperaturen hoger dan 26C in het datacenter, dienen we dus rekening te houden met speciale eisen voor de arbeidsomstandigheden. Bij hogere temperaturen dan in de traditionele omgevingen zal dit leiden tot aanvullende maatregelen maar niet een (wettelijke) onwerkbare situatie.

Let wel: bij werken in het datacenter word je bloot gesteld aan tal van omgevings factoren. Denk hier bij aan lawaai van server ventilatoren en koeling, het ontbreken van daglicht, aanwezigheid van zware stroom voorzieningen (400v) en aanwezigheid van zware machines (kg). Temperatuur is slechts 1 onderdeel. Welke maatregelen precies gewenst zijn moet per geval worden bekeken door deskundigen, bijvoorbeeld door een arbeidshygienist van de arbo-dienst.

Meer:

Datacenter temperatuur–revisited

In 2009 schreef ik een uitgebreid stuk over datacenter temperatuur. De afgelopen jaren heb ik dit onderwerp ook diverse keren behandeld op congressen. Gezien de ontwikkelingen op dit gebied de laatste maanden; tijd voor een update.

Algemeen kunnen we stellen dat computer apparatuur best wel wat kan hebben. Kijk eens naar de PC die ergens onder je bureau al jaren trouw staat te draaien. Als we die open maken zitten ze meestal vol met stof. Ook is de lucht circulatie meestal niet al te best, zo weg gestopt tussen allemaal spullen. Als we naar game consoles kijken zien we dat hardware helemaal veel kan hebben. De uiterst krachtige PlayStation 3 of XBOX 360 zijn uitgevoerd met een kleine ventilator en weg gestopt in een kastje onder de TV. Zo gaf ook James Hamilton (Amazon) aan in 2010:

[youtube=http://www.youtube.com/watch?v=kHW-ayt_Urk&w=448&h=252&hd=1]

(Bedoelde stuk vanaf 20min:15sec, de rest van de video is ook erg de moeite waard overigens…)

De hoofd reden om koeling toe te passen in het datacenter zijn de eisen van de IT hardware leverancier. Deze eisen zijn terug te vinden in de garantie voorwaarde. Zodra je buiten de aangegeven bandbreedte opereert, vervalt je garantie. De vraag is hoe groot de veiligheids marge is die door de advocaten van de hardware leverancier is ingebouwd. Mensen, zoals Christian Belady, die in de ontwikkeling van hardware hebben gewerkt merkten al eerder op:

As a former server designer, I know that server vendors “sandbag” their hardware. Sandbagging refers to the practice of knowing you can do more but holding back to hedge your risks; in reality, I believe that manufacturers can take greater risks in their operating environments and still achieve the same reliability levels.

Verandering aan de horizon.

ASHRAE is altijd aardig richting gevend geweest als het aankomt op datacenter temperatuur. Vooral hun Technical Committee (TC) 9.9 (Mission Critical Facilities, Technology Spaces and Electronic Equipment), is een bonte verzameling aan datacenter specialisten, eind gebruikers en hardware leveranciers die bepalend zijn voor een aantal ‘standaarden’ binnen de datacenter industrie.

TC9.9 heeft een bonte verzameling aan boeken gepubliceerd, waar onder “Thermal Guidelines for Data Processing Environments”. In dit boek word ook de bandbreedte voor datacenter temperatuur behandeld, en de inhoud word door alle grote IT leveranciers onderschreven. In de eerste editie van dit boek was de grens op 25C voor de inlet-temperatuur gesteld. In 2008 kwam er een update waarbij de grens op 27C gesteld werd.

Versie 3 komt over een aantal dagen (begin maart 2011) beschikbaar en hier in zal de bandbreedte weer opgerekt worden. Wederom ondersteund door alle grote IT leveranciers. Zoals het persbericht vermeld, word naast de hogere temperatuur er ook rekening gehouden met (oudere) legacy systemen die dit niet ondersteunen.

The third edition will be equally groundbreaking in that it will enable compressorless cooling (all cooling through economizers) in many applications. Accomplishing this has been a challenge since major tradeoffs (equipment size, equipment cost and operating cost) surface above a certain temperature threshold. This challenge is complicated because the threshold is not the same for all the manufacturers.

“Different locations, applications and business philosophies make it ineffective to force all equipment to be capable of the same high temperature tolerance (in some cases higher thresholds would negatively impact the return on investment),” Beaty said. “To address this, the third edition creates multiple server classes and therefore provides freedom of choice. This is particularly important since the thermal guidelines are used throughout the world.”

Deze update door TC9.9 is ook duidelijk een antwoord op de groeiende trend bij grotere datacenter eigenaren om zelf de temperatuur grenzen op te zoeken. Yahoo nam deze stap al in hun

‘Yahoo Computing Coop’ waarbij men volledig passief koelt en hogere temperaturen gebruikt. eBay nam samen met DatacenterPulse dit nog een stap verder door een datacenter in Phoenix te bouwen, met een gemiddelde van 38C in de zomer, en deze volledig van vrije koeling te voorzien. Ook hierbij werden hogere temperaturen voor de IT systemen gebruikt.

Buiten de grenzen.

Veel van de innovatieve ideeën komen door het denken buiten de bestaande oplossingen en vooral jezelf af te vragen waarom dingen zijn zoals ze zijn. Als we zien dat hogere temperaturen en bijvoorbeeld stof maar een marginaal effect heeft op de beschikbaarheid van het systeem en we zien dat er grote winsten te halen zijn door anders (of niet) te koelen zou je een radicale stap kunnen nemen: je systemen buiten de garantie grens laten draaien.

Zodra je buiten de grens komt (nu meestal 35C), vervalt je garantie. Dit betekend dat je niet meer bij de leverancier kunt aankloppen als je systeem stuk is. Als je echter zelf een paar extra systemen op de plank legt ter vervanging van je defecte systeem, is je probleem ook snel opgelost. Daarnaast kun je met de leverancier onderhandelen over een inkoop korting voor deze systemen aangezien je de garantie niet nodig hebt. Zoals eerder gezegd kent de garantie voorwaarde een hele grote veiligheids marge en blijken systemen een stuk robuuster.

Dit idee is een kwestie van kosten en risico berekening.

Integratie en meten

Extreme temperatuur of niet, het goed meten en vastleggen van de (inlet) temperaturen in het datacenter is een must. Dit geeft je inzicht in de effecten van het verhogen van de temperatuur en het totale warmte beeld dat dit oplevert voor je datacenter.

Ondanks het feit dat bijvoorbeeld server systemen tegenwoordig een garantie grens kennen van 35C, heb ik diverse discussies met engineers van grote IT leveranciers gehad over het feit dat het ‘te warm’ zou zijn in een datacenter dat afgeregeld was rond de 25C. Het goed meten en vastleggen van temperatuur kan je dus ook redden in dit soort garantie discussies.

Voor de ontwerpen van Yahoo en eBay zien we dat men maximaal steunt op de integratie tussen IT systemen en het fysieke datacenter. Door deze keten goed op elkaar af te stemmen kan de echte winst gehaald worden. Denk hierbij aan de discussie: als de temperatuur omhoog gaat –> gaat de server fan harder draaien, waar door de energie afname om hoog gaat (zi
e vorige blog). De oplossing hier voor word dus niet alleen gezocht in fan-less server ontwerpen maar vooral in de integratie tussen de keten delen.

Warm is best wel eng…

Van ASHRAE mogen we al enige tijd hoger dan 21C. Ook de leveranciers voorwaarde staan ons niet in de weg om hoger te gaan. Daarnaast zijn er diverse onderzoeken die zelfs laten zien dat het nog veel extremer kan met 35C+. De realiteit is dat maar weinig datacentra echt naar hogere temperaturen gaan; de meeste blijven hangen rond de 20 – 22C.

Ik kan me voorstellen dat bedrijven zich niets aan trekken van een ‘groen imago’ of ‘maatschappelijk verantwoord zijn’. Door hun ICT-ers en facilitair personeel echter niet te stimuleren om te kijken naar datacenter temperatuur en het verhogen daar van laten deze bedrijven financiële besparingen liggen. En dat is toch iets was aantrekkelijk moet zijn voor elke organisatie in deze tijd van economische crisis…

Meer:

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

Nu echt modulair…

Een datacenter bouwen als Lego blokjes… dat lijkt de utopie in de modulaire datacenter wereld. In deze wereld is het datacenter gebouwd uit verschillende blokjes met de volgende karakteristieken: modularity

De blokjes zijn beschikbaar in verschillende soorten en maten
De blokjes zijn snel leverbaar, hier door is het datacenter snel uit te bereiden (+/- 6 weken, JIT levering)
Bij de keuze van het blokje, kan men kiezen uit TIER 1 t/m 4 voor beschikbaarheid. Hier door kan men beschikbaarheidsniveaus mixen.
Bij de keuze van het blokje, kan men kiezen uit diverse PUE niveaus.
Bij de keuze van het blokje, kan men kiezen uit diverse warmte belastingen per rack (kW/rack).
Bij de keuze van het blokje, kan men keizen uit diverse koeloplossingen (lucht (van buiten), water)
Bij de keuze van het blokje, kan men kiezen uit huur, lease of koop van het blokje.

Hier mee kan men dus op het juiste moment, het meest geschikte blokje inzetten tegen de juiste financiële voorwaarde. Deze modulariteit is niet automatisch een container datacenter. Diverse ‘niet-container-leveranciers’ leveren ook een modulair gebouwde oplossing.

Deze utopie is al langer de wens van menig datacenter eigenaar. Uiteraard proberen diverse leveranciers in te spelen op deze wens. Modulariteit is hier mee tot een marketing term verworden, die te pas en te onpas vermeld word bij diverse datacenter oplossingen.

Zoals Lex Coors (Interxion), terecht, zich beklaagd in DatacenterWorks:

Tegenwoordig lijkt het wel alsof alle datacenters modulair worden gebouwd. Helaas verstaat niet iedereen hetzelfde onder modulair bouwen, zo stelt Lex Coors, vicepresident datacenter technologie en engineering group van Interxion. “Er wordt veel gesproken over modulair bouwen maar uiteindelijk zie ik alleen de fasering terug en niet de modulaire benadering van de infrastructuur.”

Datacenter Pulse toetst regelmatig binnen de 1500+ leden wat hun top 10 grootste uitdagingen zijn op datacenter gebied. Op nummer 9 vinden we daar ook modulariteit:

More Products with Modularity

Goal: Enable pro-active, simple expansion or contraction of datacenter capacity without risk or reduction of design availabilities.

Update: Not seeing any significant increase in modular product offerings or end user implementations

Both vendors and end users need to elevate the discussions to implement current modular solutions to enable future modular products.

De frustratie van Lex word dus gedeeld door andere datacenter eigenaren. Datacenter Pulse komt nu te hulp met de Modulair RFP.

Continue with reading

Het datacenter naar zee

In 2008 kondigde International Data Security (IDS) aan om schepen in te zetten als datacenter locaties. Deze week komen ze met het bericht dat ze een Proof Of Concept (POC) gaan uitvoeren.

De ideeën voor een datacenter op zee zijn niet nieuw. Zeker gezien het patent wat Google hier op aanvroeg in 2007. (zie plaatje).

Hierbij word vooral ingezet op het gebruik van zee water; als koelwater voor de IT systemen en voor het genereren van elektra via golfslag.

Nu hebben wij als Nederlanders al een hele lange relatie met de zee en het bedenken van creatief gebruik van de zee. Voor elektra opwekking zijn dus diverse (Nederlandse) oplossingen beschikbaar.

In 2006 testen de TU Delft de aandrijving van een citruspers op het strand van Scheveningen, onder het motto ‘Energie uit golven’

De firma Ecofys werkt aan hun Wave Rotor concept, waarbij de kracht van de zee word om gezet in energie.

Ook in het buitenland word er al enige jaren gewerkt aan energie opwekking uit zee:

Tijdens de conferentie Clean Energy Power in januari 2006 in Berlijn was één van de themabijeenkomsten speciaal gewijd aan het opwekken van energie uit de zee. Het was indrukwekkend om te zien met hoeveel inzet of ‘Begeisterung’ Duitse ingenieurs en universiteiten werken aan het onderzoek naar de mogelijkheden om energie op te wekken uit zee: in vrijwel alle projecten over de wereld hebben Duitse ingenieurs op de een of ander manier wel een aandeel.

(Bron: Verslag conferentie Clean Energy Power in januari 2006 in Berlijn – http://www.twanetwerk.nl/default.ashx?DocumentId=5967)

De vraag is hoe wetgeving zal om gaan met ‘het datacenter op zee’. De discussie rond de locatie van data is aardig aangezwengeld door de Cloud ontwikkelingen, en deze oplossing maakt het nog interessanter. Op zo’n 22km uit de kust eindigt het territoriale water en is het VN-zeerechtverdrag van toepassing.

Meer:

IDS Readies Data Centers on Ships

Chill Off 3 aan de horizon

Het heeft even geduurd voordat DatacenterPulse (DCP) met een update rond de Chill Off testen konden komen. Dit heeft te maken met wat tegenslag tijdens het testen, maar vooral met de ontzettende hoeveelheid aan onderzoeks data, die het opgeleverd heeft. Deze moet, uiteraard, nauwkeurig onderzocht en getoetst worden voordat men met resultaten komt.

Op dit moment worden de resultaten van de Chill Off 2 aan diverse externe specialisten voorgelegd; technische DCP leden die hun sporen verdient hebben in de datacenter wereld en in hun huidige functie verantwoordelijk zijn voor de grootste datacentra op de wereld.

Tijdens het SVLG Data Center Energy Efficiency Summit in oktober van dit jaar zullen de resultaten gepresenteerd worden.

De DCP Board is zich vast aan het voorbereiden op het vervolg: de Chill Off 3.

Tot nu toe hebben we ons gefocust op de efficiëntie van koelsystemen. De datacenter koelsystemen zijn er om de IT systemen in het datacenter te kunnen laten functioneren. De vraag is echter: wat kunnen de IT systemen eigenlijk hebben en wat kunnen we daar nog aan verbeteren.

Denk hierbij aan de Datacenter Tent test van Microsoft;

Inside the tent, we had five HP DL585s running Sandra from November 2007 to June 2008 and we had ZERO failures or 100% uptime.

In the meantime, there have been a few anecdotal incidents:

Water dripped from the tent onto the rack. The server continued to run without incident.

A windstorm blew a section of the fence onto the rack. Again, the servers continued to run.

An itinerant leaf was sucked onto the server fascia. The server still ran without incident (see picture).

Maar ook aan het recent oprekken van de temperatuur in het datacentrum door ASHRAE;

Expansion of the recommended data center temperature range, which should be taken at the server inlets. They should now be 18 degrees Celsius to 27 degrees (64.4 degrees Fahrenheit to 80.6 degrees), expanded from 20 degrees to 25 degrees (68 degrees Fahrenheit to 77 degrees).

De IT systemen blijken dus best wel wat te kunnen hebben… tijd dus om ze aan de tand te voelen.

Voor de Chill Off 3 zullen server leveranciers gevraagd worden om hun beste systeem te leveren met de volgende parameters:

– DCP stelt de inlet temperatuur vast (verwacht voor lucht rond de 40C)

– DCP levert benchmark software (o.a. eBay query’s en mogelijk SPECxxx)

– DCP test met luchtkoeling en waterkoeling (ook water direct op de chip) in een datacenter omgeving.

Resultaten zullen getoetst worden op basis van het aantal Query’s per Watt dat de machine kan verwerken bij de door ons aangegeven omgevingscondities. De server leveranciers worden hiermee gedwongen om te kijken hoe ver ze kunnen gaan met hun systemen.

Tot nu toe heeft o.a. Intel al toegestemd met medewerking voor deze testen.

Er moeten nog een hoop details uitgewerkt worden voordat we kunnen starten met deze testen, maar deze tweaker/overklokker mentaliteit zie ik natuurlijk helemaal zitten 🙂

Microsoft’s holistische blik…

Microsoft heeft een nieuw whitepaper uitgebracht genaamd A Holistic Approach to Energy Efficiency in Datacenters.

In het document onderschrijven ze de manier waar op DatacenterPulse naar het datacenter kijkt en die ik eerder heb beschreven in Groene applicaties ? Integratie !

But just improving PUE should not be an organization’s goal. The real goal is to eliminate waste and pack as much
compute capability in the available power budget. PUE can be a useful indicator of energy efficiency, but it can also
mislead you if used blindly. Take for example a scenario in which the fans in a server can be removed without impacting
its performance. The elimination of fan power reduces the IT power (fan power is part of IT power), improves energy
efficiency, but it also increases the PUE!

De Microsoft mensen (voornamelijk Global Foundation Services (GFS)) verdienen credits voor hun werk en openheid hier over.

Meer: