Ook als software ontwikkelaar lukt profiteren van cloud computing niet zonder veranderingen. Als traditionele software naar de cloud wordt gemigreerd is dit vaak op basis van Infrastructuur as a Service. Dit is geen keuze die je veel verder zal brengen en van kostenbesparing is al vaak geen sprake meer. Lees nu hoe het dan wel moet.
Van de week mocht ik een seminar van een uur geven aan een groep Java-ontwikkelaars. De eerste dertig minuten heb ik besteed om een basis te leggen wat cloud computing is, het laatste half uur heb ik een demonstratie gegeven hoe ik niet één, maar twee platformen heb gebruikt om een dienst vanaf scratch te ontwikkelen en te deployen naar de cloud.
Dit op basis van een schaalbaar, robuust en veerkrachtig platform dat zich automatisch aanpast naar de omstandigheden. De essentie is dat er gebruik gemaakt wordt van automatisering. Iets dat zelf heel veel geld en tijd zou kosten om te realiseren.
Ik kan bijna niet genoeg benadrukken hoe belangrijk het is om dit als software-ontwikkelaar te onderzoeken. Dit negeren is een zonde en kan in de toekomst het verschil zijn tussen succes en het opereren in de marge.
Traditioneel
Stel je biedt een dienst aan op basis van Software as a Service. Je ontwikkelt code, richt een database en een server in en om de zoveel tijd deploy je de code naar de testomgeving zodat deze geaccepteerd kan worden voor de productieomgeving.
Vaak is de productieomgeving omvangrijker dan de testomgeving en wordt het in de lucht houden van de omgeving gedaan door beheerders. Het opschalen (neerschalen wordt niet gedaan in traditionele omgevingen) is iets wat gepland moet worden en veelal veel geld, tijd en hoofdbrekens kost.
Als dit uitbesteed wordt naar de cloud is dit altijd op basis van Infrastructure as a Service. Hiermee zijn de kosten weliswaar operationeel, maar kan er van besparing geen sprake zijn. Je hebt gewoon je spullenboel elders draaien met alle bijkomende kosten die daar bij horen. Ja, je kunt zeggen dat je de cloud geadopteerd hebt, maar per saldo schiet je er niets mee op.
Platform as a service
Om echt een hefboom te verkrijgen die leidt tot minder kosten, betere schaalbaarheid, robuust en flexibeler is met lagere beheerkosten, zul je moeten overschakelen naar Platform as a Service. Aan de ene kant zijn de verschillen om dit te realiseren niet heel groot. De essentie van de geproduceerde code is vaak niet heel anders en de manier van deployen is vrij simpel als je van diensten gebruik maakt zoals Windows Azure of Amazon Webservices. Het Windows Azure-platform leent zich overigens vooral voor Windows .NET code, Amazon Webservices kan veel breder toegepast worden.
Wat er gebeurt is dit: Er is een configuratie ingesteld voor de software. Deze is anders voor Windows Azure dan voor Amazon Webservices. In deze configuratie staat onder andere welk type server in de basis gebruikt wordt en een aantal eigenschappen zoals geheugen, processor en dergelijke. Ook naar welk abonnement gedeployed wordt en hoe de omgeving heet en over welke url deze benaderd wordt.
Als er op de deploy knop gedrukt wordt, gebeuren er zeer veel dingen onder de motorkap. Er worden virtuele servers aangezet, certificaten geïnstalleerd, virtuele load balancers geplaatst en een aantal business rules geactiveerd. Een voorbeeld van een businessrule is bijvoorbeeld dat als de cpu van een server meer dan 80 procent gebruikt wordt voor drie minuten er een server wordt bijgeplaatst en als de cpu van een server langer dan drie minuten onder de 30 procent komt er een server wordt weggehaald tot een minimum van twee servers.
Een detail wat je op het eerste gezicht niet ziet, maar bijdraagt aan de ‘resilience’ is dat elke server in een ander ‘fault domain’ draait. Vrij letterlijk is dit een ander serverrack in het datacenter en dat het ‘cloud OS’ weet dat de servers met elkaar in verbinding staan en bij onderhoud dus nooit twee servers tegelijkertijd een update krijgen.
Maar het zit hem in deze automatisering die cloud computing zo aantrekkelijk maakt. Je kunt op een vrij gemakkelijke manier op een hele robuuste manier met online software omgaan. Dit is wat het een platform maakt.
Aandachtspunten
Overigens zijn er wel degelijk dingen anders als je software op een platform van Amazon of Microsoft deployed. Zo heb je geen invloed op de servertijd. Alle servers in de cloud, ongeacht locatie, draaien op utc-tijd. Dit betekent dat je direct vanaf de basis hier rekening mee moet houden aangezien de tijd van je klanten (en dus hun browser) niet overeen komt met de tijd op de server. Het is geen ramp, maar wel iets wat je in het ontwerp mee moet nemen.
Ondanks dat de data opslag en rekenkracht schaalbaar en elastisch is opgezet, gaat dit niet zomaar op voor relationele databases. Ook hier heb je met beperkingen te maken en dingen die in de cloud anders zijn dan on-premises.
Niettemin adviseer ik bedrijven om in ieder geval een account aan te maken en ontwikkelaars ervaringen op te laten doen. Door het gebruiken van de diensten komen ze op ideeën die ze na kunnen bouwen. Er is geen excuus om dit links te laten liggen omdat je Amazon of Microsoft afkeurd. Daarnaast gaat de ontwikkeling van de diensten griezelig snel. Bijna wekelijks komen er nieuwe opties in de portal of worden verdere principes uitgewerkt.
Ik ben er dan ook voorstander van om de diensten zo ‘kaal’ en puur mogelijk te consumeren, dit voorkomt aanpassingen bij veranderingen, maakt een exit ook beter mogelijk en maakt een vendor lock-in zo klein als mogelijk. Er zijn veel diensten die de huidige problemen met cloud computing op kunnen lossen. Als die noodzakelijk zijn om live te kunnen gaan, kun je ze inzetten, maar gebruik ze vooral als een losse en vervangbare extensie en verweef ze niet teveel in de oplossing zelf. Als de ideeën van deze extensies namelijk goed zijn, worden ze vanzelf overgenomen of nagebouwd.
Conclusie
Kortom, bouwen op een platform heeft zeer veel voordelen en weinig nadelen; met minder mensen meer kunnen doen in kortere tijd met een verbeterde kwaliteit en controle en veiligheid. Het klinkt bijna te mooi om waar te zijn. It simpel maken is een basishouding die elke softwareontwikkelaar zou moeten adopteren en verschuiven van infrastructuur naar platform is een zinvol middel. Nee, het is nog niet af, nog niet compleet, maar het komt dicht in de buurt en de ontwikkelingen gaan razend snel.
Henri,
Weer één van je gebruikelijke stukjes waarbij alleen de voordelen genoemd worden maar nadelen onbesproken blijven. Zin als: ‘…gebeuren er zeer veel dingen onder de motorkap.’ laat zien dat je enkel oog hebt voor service delivery maar weinig stilstaat bij service support. En cloud principes voor schaalbaarheid zijn prachtig maar hoe zit het nu werkelijk met de beschikbaarheid?
Verder levert een platform dat door één provider gedefinieerd, geleverd en ingericht wordt naar mijn opinie WEL een vendor lock op. Die zit dan misschien niet in de resources maar dan toch zeker in alles wat daar boven zit. Want hoe zit het met de migratie mogelijkheden van Azure naar een ander cloud platform?
Dat Microsoft een weg naar Azure biedt vanuit andere (OSS) oplossingen hebben we al eens besproken maar dat er meestal geen weg terug is blijft naar mijn mening een bezwaar. Je opmerking bij opinie over OpenStack was voor mij dan ook veelzeggend: ‘…persoonlijk ben ik dus ook nog terughoudend om me volledig in te zetten voor OpenStack.’
Mede omdat je in 9 van de 10 gevallen als het over Cloud Computing gaat de .NET stack noemt kun je dan ook misschien beter de titel van Cloud Computing Consultant veranderen in Azure (business) developer.
Want om terug te komen op je opmerking ‘onder de motorkap’ zou het mooi zijn als we niet meer hoeven te kiezen voor benzine of diesel.
@ Henri,
Zijn dit soort platformen ook echt schaalbaar en flexibel op het gebied van Storage? Wordt er bijvoorbeeld gebruik gemaakt van QoS ( Quality of service ) en Automatic storage tiering? Kan ik vooraf gegarandeerde performance afspreken? En hoe elastisch is dit? Dit wordt meestal vaak vooraf keihard gereserveerd door de andere aanbieders in de markt. Maar ik zou dit graag zien dat dit via het burstable principe gebeurt. Of te wel pay for use niet alleen voor CPU rekenkracht maar ook voor de opslaglaag. Anders is dit natuurlijk niet zo kosteneffectief.
Kan jij hier wat duidelijkheid in verschaffen? En wat zijn de andere smaken in de markt die dit doen? In je stukjes heb je het bijna altijd over Azure en Amazon. Maar er zal toch vast wel meer zijn.
Hey Ewout,
Beschikbaarheid is *het* argument voor cloud computing en plaformen in het bijzonder. Juist door minder bezig te zijn met infrastructuur en meer op platform verhoog je de beschikbaarheid om te leunen op een architectuur die daarvoor ontworpen is! Je hebt zogezegd de kracht en de kennis van top engineers voor de prijs van je neefje (of in jouw analogie een post geleden te spreken: De kwaliteit van een a la carte restaurant voor de prijs van een afhaal chinees). Amazon en Microsoft hebben dit zeer goed voor elkaar en als je dat niet ziet, of wilt zien, dan is dat jammer.
Hoewel ik inderdaad Microsoft (.NET) georiënteerd ben, beschrijf ik in het begin van mijn artikel hoe ik code op 2 platformen deploy, ik had er misschien aan moeten toevoegen dat deze code volledig uitwisselbaar is! Ik kan hem dus zowel deployen bij Amazon ALS bij Windows Azure en als kers op de taart, ook nog lokaal. Overigens kun je Linux prima deployen op beide platformen al kun je je voorgedefinieerde images niet meenemen. Maar daar zit niet de angel. Ik schrijf dus niet voor 1 platform MS platform, excuus dat ik dit blijkbaar niet duidelijk genoeg omschreven heb, al denk ik dat je wat vooringenomen bent 😉
De reden waarom ik wat terughoudend ben naar OpenStack is dat ik daar nogal wat voordelen mis die ik bij Amazon en Microsoft wel heb. OpenStack is een stuk technischer en dat wil ik nu juist vermijden. Het overgrote voordeel van OpenStack is : Grote community met zeer sterke achterban, Open Source, niet afhankelijk van Amerikaanse providers.
De ene keer verwijt je mij Google, nu verwijt je mij Microsoft, ik durf bijna niet meer verder te schrijven over Amazon. De enige overeenkomst is dat het allen Amerikaanse bedrijven zijn. Ik ben geen fan van de Amerikaanse overheid, maar de diensten uit dat land zijn superieur op dit moment en ik denk dat deze diensten je verder kunnen brengen en daar schrijf ik over.
Met betrekking tot je laatste opmerking: Je vergeet elektriciteit 🙂 Goedkoop en 0% belasting, of ben ik nu bevooroordeeld?
Dag Ruud, bedankt voor je reactie.
Dit artikel gaat over platform as a service en waarom je hierop zou moeten richten… als software ontwikkelaar. Die scope heb ik in de eerste zin direct duidelijk gemaakt.
De enige twee platformen waar ik veel ervaring mee heb zijn Windows Azure en Amazon webservices. Maar er zijn ook andere diensten die zo’n platform aanbieden
zie
https://www.heroku.com/
http://uhurusoftware.com/
En zo zijn er meer, maar daar heb ik geen of weinig ervaring mee.
Punt is wel dat ik het heb over Platform as a service en niet Infrastucture as a service. De behoefte van niet software ontwikkelende bedrijven is dus anders dan als je zelf wel een software ontwikkelaar bent. QoS en Automatic storage tiering is iets wat het platform voor je zou moeten brengen.
Storage vanuit een software perspectief is inderdaad schaalbaar, flexibel en per direct beschikbaar. Zoals ik echter schrijf zijn relationele databases een ander beestje waar geen quick-fix voor is.
Daarnaast moet je wel rekening houden met factoren zoals latency, dat data verplaatsen tussen clouds zijn maxima kent er hiervoor ook kosten gelden.
Maar nogmaals de behoeften van een regulier bedrijf zijn anders dan het leveren van online software en diensten.
Pay per use is niet alleen voor CPU, ook voor data. Je kunt 10 TB reserveren en maar 10 Gb gebruiken, in principe betaal je dan alleen voor die 10 Gb.
Ik hoop dat je hier iets mee kan.
Henri,
Thanks.
Ik lees alleen in je reactie terug dat het schaalbaar is op rekenkracht en opslagcapaciteit. Wat nu als ik een goede performace wil op het gebied van disk IO’s?
Opslagcapaciteit en CPU power geloof ik wel. De bottleneck zit vaak in een tekort aan bandbreedte en disk IO en het hebben van te veel latency.
Want je softwarelaag gaat het echt niet leuk vinden als je diskjes het onderwater niet op tijd verwerken. Storage performance is nog te vaak de bottleneck op dit soort platformen.
Ruud: Dit is wellicht een aardige blog om te lezen http://perfcap.blogspot.nl/2011/03/understanding-and-using-amazon-ebs.html
Dat gaat over performance, en hoe je “IOPS” reserveert door slim af te nemen.
In een “platform” omgeving heb je in de basis *niets* met disks te maken, die abstractie laag wordt juist van je weggehouden en van veel van de cloud uitdagingen met het hosten van software is je onderliggende disk snelheid of beschikbaarheid geen probleem.
Jouw problemen van bandbreedte en teveel latency herken ik dus niet.
Maar heb je voorbeelden of bronvermeldingen? Want nogmaals, als je software bouwt op een platform neem je veel van deze problemen weg. Daarnaast krijg je bijvoorbeeld bij Elastic Beanstalk prachtige performance tools er gratis bij, meten is dus weten. Als je IO performance dus slecht is, dan wordt dit direct duidelijk en je kunt er zelfs triggers op laten afgaan in de vorm van waarschuwingen (reactief) of het bijschalen van capaciteit (pro-actief).
Heb je AWS of Azure wel eens in actie gezien? Zou je het willen zien?
Het is namelijk behoorlijk indrukwekkend.
Henri,
Bedankt voor de link. Ik zal dit even doornemen.
Zijn er bij deze platformen geen verschillende tiers? Ik kan mij voorstellen dat een DB met 10000 IOPS flink wat duurder zou moeten zijn dan een simpele web omgeving met een lage disk io load.
Henri,
Laat ik beginnen bij je laatste zin want ik vergeet zeker niet de stroom die tussen cloud en gebruiker nog weleens wegvalt. Daarom vroeg ik ook naar de beschikbaarheid want service level agreements zijn een vak apart. Nu is dat echter meer gerelateerd aan uitbesteding want de principes van Cloud computing zijn leverancier (locatie) onafhankelijk. Het is dan ook jammer dat je me vooringenomen vindt want juist bij Azure zie ik, in tegenstelling tot Google meer mogelijkheden om tot een hybride oplossing te komen.
Ben trouwens ook benieuwd hoe het zit met de lifecycles van sommige functionaliteiten omdat deze nog weleens wijzigen of verdwijnen. Want aangaande je argument dat je code (je bedoeld functies?) naar twee verschillende platformen kunt uitrollen vraag ik me af wat dat met Cloud Computing te maken heeft. Het lijkt me hier namelijk meer om de runtime of stack te gaan die op doelplatform loopt en waarbij de API’s voor abstractie zorgen.
Betreffende laatste lijken de initiatieven voor Cross-cloud API’s helaas stil te sterven, vandaar mijn opmerking over de ontbrekende weg terug. En volgens mij maakt Nirvanix weer eens duidelijk dat een migratie strategie geen overbodige luxe is. En daar zit dan ook ons verschil in visie want blijf me afvragen hoe dat we alles efficiënt afstemmen met elkaar om de primaire doelstelling van organisaties te halen, namelijk de continuering van de bedrijfsvoering.
Ewout,
Je raakt wel een paar relevante onderwerpen. Maar eerst je eerste zin: Als je stroom uitvalt op je kantoor (met je servers aldaar) heb je eenzelfde probleem, en geen uitwijk mogelijkheid.
SLA hebben we het eerder over gehad, een SLA garandeert geen uptime.
Wat betreft code, daarmee bedoel ik inderdaad je code. De code in de cloud is dezelfde code die je gebruikt op je webserver lokaal, al zal een goede cloud applicatie wel wat afwijken dan traditionele code. Mijn code die draait op de Amazon cloud draait ook bij Windows Azure. Azure en AWS zijn echter meer dan alleen een Applicatie platform, je hebt ook nog service bus, storage, et cetera. Die API’s zijn inderdaad verschillend. Aardig detail is echter dat je storage op OpenStack op een zelfde manier aan zou kunnen spreken als storage op S3 van Amazon.
Daarnaast kun je ook een DAL schrijven die onder de motorkap de diverse API’s spreekt, eigenlijk net zoiets als je producten kan maken die met zowel Oracle als MS SQL server kunnen praten.
Daarnaast, als je de API’s bestudeerd zie je dat REST en JSON de klok slaan en dat omschrijven behapbaar is.
En om een heel goed artikel van vandaag aan te halen ( https://www.computable.nl/artikel/opinie/management/4877594/2379250/management-maakt-it-kapot.html ): Je bouwt een infrastructuur / oplossing toch voor langere tijd. Dat je naar een Vendor toe schrijft is gewoon een risico analyse, en zoals altijd daarbij hoort ook een exit strategie. Dat Nirvanix debacle lijkt mij geen drama als een bedrijf hier gewoon een exit strategie voor had. Die heb je ook nodig voor als je zaken doet met Amazon of Microsoft.
Maar om je afsluiter te bekrachtigen. Continuering is ook mijn visie en vandaar dat ik aanraadt te focussen op platform, niet op infrastructuur. 🙂 En daarin zijn uiteraard meerdere visies mogelijk.
Henri,
Bij stroomuitval in eigen datacenter neemt noodvoorziening het meestal over, de diesel blues. Maar ik zal beschikbaarheid even parkeren. Waar ik op verder wil gaan is cross-platform omdat dit een standaardisatie vraagt die naar mijn mening nog ver te zoeken is. Er zijn enkele initiatieven maar deze lijken ‘niet echt van de grond te komen’ omdat leveranciers er geen belang bij lijken te hebben.
En hierdoor wordt vergelijken ook lastiger: http://cloudharmony.com/benchmarks
Abstractie toevoegen en de intelligentie hoger in de stack leggen heeft zowel voor- als nadelen. Voordeel is een grotere flexibiliteit maar daarvoor betaal je wel een prijs in de vorm van performance cq. efficiency. Bare-metal, private cloud en zelf IaaS hebben allen als voordeel dat je dingen kunt tunen. Een elektromotor of dikke V8 onder de motorkap maakt namelijk een heel verschil en het is om die reden dat bedrijven ook nog weleens uit de cloud migreren.
En voor de duidelijkheid, je sized niet voor de piek maar de gemiddelde belasting van de hele keten waardoor schaalbaarheid nog weleens overgewaardeerd is. Nu is cloud bursting daarin wel een heel interessante optie en heeft Microsoft een pluspunt met een complete stack inclusief unified management. Tenminste voor degene die nu al een .NET stack hebben want om even terug te komen op jouw beschuldigingen aan mijn adres ben jij nogal vooringenomen betreffende OpenStack.
Maar ik ga weer volledig off-topic om uit te leggen dat Duitse tanks en Amerikaanse jeeps beide voertuigen zijn maar ieder een hele andere aandrijving hebben. En wel of geen toprollers gaan we nog weleens bespreken onder genot van een biertje;-)