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 1, 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 die zich automatisch aanpast naar de omstandigheden. De essentie is dat er gebruik gemaakt wordt van automatisering. Iets wat zelf heel veel geld en tijd zou kosten om zelf 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 tussen succes zijn 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 test omgeving zodat deze geaccepteerd kan worden voor de productieomgeving.
Vaak is de productieomgeving omvangrijker dan de test omgeving 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 welliswaar operationeel, maar kan er van besparing geen sprake zijn. Je hebt gewoon je spullenboel elders draaien met alle bijkomende kosten die daar bijhoren. 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 o.a. 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% gebruikt wordt voor drie minuten er een server wordt bijgeplaatst en als de CPU van een server langer dan drie minuten onder de 30% 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 server 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 en 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 in 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 goed om waar te zijn. IT simpel maken is een basishouding die elke software ontwikkelaar 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.