Unitt breekt barrière tussen Public en Private Cloud
In de rubriek ‘Manager aan het woord’ geven wij CEO’s en andere leidinggevenden de mogelijkheid om hun visie op de ICT-sector anno 2015-2016 uitvoerig toe te lichten. IT-trends, maar ook zakelijke evoluties komen hier aan bod.
Benjamin Jacobs, CEO Unitt
Enterprise Hosting gebeurt dankzij de innovaties van Unitt nu altijd op het juiste Cloudtype, maar met dezelfde ijzersterke garanties en gebruiksgemak. Bovendien zorgt continuous deployment voor minder risico en een snellere time to market.
De stap naar de Cloud. Maar welke Cloud?
Ik zie Unitt als één van de weinige Advanced Consulting Partners van Amazon Web Services (AWS) in de Benelux. We hebben ondertussen al een heus track record opgebouwd in zowel Public als Private Cloud. Unitt volgt al sinds het prille begin met een gezonde interesse de opkomst van Public Cloud diensten zoals Amazon en Azure. De Public Cloud vendors zijn pas recent matuur geworden en hebben ondertussen hun strepen verdiend. Geen beter moment voor Unitt om met haar totaaloplossing op de markt te komen.
Public Cloud heeft lange tijd het imago gehad dat deployment slechts een kwestie van enkele klikken was. In de praktijk blijkt dat echter niet zo leert de ervaring ons. Pas na de oplevering van de infrastructuur begint het echte werk, of dat nu Public of Private Cloud is.
AWS-kennis en DevOps in huis
In de zomer van 2014 hebben we AWS-specialist GiMiScale via een acquisitie verworven en geïntegreerd in Unitt. GiMiScale beschikt over extra tools die het management van Public Clouds sterk vereenvoudigen en het product beter integreren op de bestaande platformen. Bovendien heeft Unitt sterke Service Level Agreements (SLA’s) uitgewerkt die meer bieden dan de rechtstreekse standaardcontracten van Public Cloud vendors zoals Amazon en Azure.
Bij elk project wordt de code van de applicatie geanalyseerd die in de Cloud moet draaien. Dat was al het geval bij Private Cloud maar is nog belangrijker geworden bij Public Cloud. Onze DevOps-engineers tweaken en optimaliseren zo in samenspraak met de klant de code. Het resultaat is een sterke toename in de performantie.
We zien meer en meer bedrijven de stap zetten naar Public en Private Cloud. Enkele jaren geleden waren bedrijven nog huiverachtig om hun business naar de cloud te verplaatsen omwille van securityredenen. Nu zijn die bedrijven eerder een uitzondering geworden.
We leven in een tijd waarin de marktomstandigheden snel veranderen. Bedrijven moeten daarop snel kunnen inspelen om te overleven. Helaas wil de business vaak sneller wijzigingen in de IT-toepassingen doorvoeren dan voor de IT-afdeling mogelijk is. IT vormt zo vaak een belemmering voor de business in plaats van een enabler. U wilt al die nieuwe functionaliteit morgen al, niet over vijf maanden.
Met continuous deployment is het mogelijk om continu kleine veranderingen in uw toepassingen uit te rollen zonder het risico te verhogen dat er iets misloopt. In combinatie met de cloud maakt continuous deployment van uw bedrijf een realtime business. U bent in staat om snel te schakelen en flexibel te reageren op veranderende marktomstandigheden terwijl er over de betrouwbaarheid van uw IT-platform geen discussie is.
Wat is continuous deployment?
Continuous deployment wordt al jaren met succes toegepast bij bedrijven die doorgedreven van de cloud gebruikmaken. Amazon geeft de functionaliteit van zijn webwinkel elke 11,6 seconden een update. Websites zoals Instagram en Pinterest voeren gemakkelijk duizend deployments van nieuwe code per dag uit.
Om op een betrouwbare manier continu vernieuwingen in uw toepassingen te realiseren hebt u automatische processen nodig die u helpen bij het testen, releasen en uitrollen van uw software. Daarbij kunt u gebruikmaken van de volgende praktijken:
Continuous integration
U laat uw toepassing op geregelde tijdstippen automatisch bouwen en testen, zodat u eventuele problemen zo snel mogelijk opmerkt. Dat kan met automatische daily builds, die dagelijks de nieuwste versie van de code bevatten. Maar u kunt ook vóórdat een ontwikkelaar zijn code in het versiebeheersysteem plaatst automatische tests laten uitvoeren. Als die tests dan problemen opleveren, weigert het versiebeheersysteem de code. De ontwikkelaar weet dan dat zijn code een fout bevat en dat ze niet aanvaard wordt voor hij het probleem oplost. Zo bereikt u meer betrouwbare code omdat alle ontwikkelaars weten dat de huidige code die ze uit het versiebeheersysteem halen altijd aan de testsuite voldoet.
Continuous delivery
Voert u doorgedreven continuous integration uit en zijn de tests van uw testsuite voldoende uitgewerkt, dan kunt u er op vertrouwen dat uw toepassing op elk moment aan minimale kwaliteitseisen voldoet. De volgende logische stap is dan ook dat u de code op elk moment klaar voor een release beschouwt. U levert dan ook regelmatig kleine en goed beheersbare releases aan de QA-afdeling. Die aanpak staat in schril contrast met de klassieke manier waarbij u na heel wat ontwikkelingen besluit dat er een nieuwe release komt en een langdurig proces nodig hebt om de code release-ready te maken. De QA-afdeling krijgt dan een versie te zien met heel veel wijzigingen die allemaal op hun kwaliteit en betrouwbaarheid getest moeten worden, wat een hele uitdaging is.
Continuous deployment
Als uw toepassing dankzij continuous delivery op elk moment in principe release-ready is, is de volgende stap logisch: rol effectief constant nieuwe releases uit. Dat is de aanpak die heel wat diensten gebruiken die op cloudtechnologie gebouwd zijn, zoals Instagram, Pinterest en Amazon. U laat dan het uitrollen van de nieuwste release op geregelde tijdstippen automatisch gebeuren, bijvoorbeeld dagelijks. Een andere optie is om na elke aanvaarde code commit onmiddellijk de wijzigingen van de ontwikkelaar uit te rollen. Welke aanpak u ook kiest, het constante thema is dat er een volautomatisch proces bestaat vanaf de commit door een ontwikkelaar in het versiebeheersysteem tot de functionaliteit die uiteindelijk in de toepassing terechtkomt.
Welke pijnpunten lost continuous deployment op?
Continuous deployment gebruiken voor uw toepassingen in de cloud helpt u om de volgende pijnpunten op te lossen:
Laat u toe om korter op de bal te spelen
Gebruikt u goed of optimaal (of iets dergelijks) een continuous-deploymentproces, dan kunt u op elk moment sneller schakelen als dat nodig is. U ontwikkelt de nieuwe feature, bouwt de nieuwe release, test die en rolt die uit. Zo bent u in staat om kort op de bal te spelen zonder de betrouwbaarheid van uw toepassing in het gedrang te brengen.
Vermindert releasestress
In de klassieke aanpak zorgen de grote releases met vaste deadlines steevast voor extra stress bij iedereen die aan de release meewerkt. Ze willen allemaal immers tot op het laatste moment de features die nog niet correct werken toch werkend krijgen omdat ze anders pas in de volgende release terechtkomen. Met continuous deployment krijgt u niet met die stress te maken: elke feature wordt uitgerold wanneer hij klaar is, los van een of ander releaseschema.
Geeft gemoedsrust aan operations
Een grote zorg van operations wanneer de ontwikkelaars een nieuwe release willen uitrollen is: hoe weet ik zeker dat het mijn productie niet in gevaar brengt? Of bevat de nieuwe release geen bugs? De automatisering van de deployments elimineert al heel wat mogelijke menselijke fouten. Bovendien zorgt de integratie met de testsuite ook voor heel wat gemoedsrust: operations weet dat de code die uitgerold wordt door de testsuite is geraakt. Continuous deployment verhoogt de kwaliteit van de code.
Elimineert handmatige stappen
Bij elke deployment komen er traditioneel heel wat handmatige stappen aan te pas. Voor de IT’ers die de stappen uitvoeren is dat een repetitief werkje dat ze niet graag doen. Bovendien is de laatste jaren iedereen door het succes van clouddiensten gewend aan snellere releases. Met continuous deployment automatiseert u het hele proces, waardoor uw IT’ers tijd vrij krijgen voor minder repetitieve jobs. Ook neemt de eliminatie van handmatig werk de ‘human error’ factor weg. Betrouwbaarder dus..
Behandelt toepassing en infrastructuur samen
Continuous deployment is niet alleen interessant voor toepassingen, maar ook voor (cloud)infrastructuur. Dat is mogelijk omdat heel wat cloudinfrastructuur ook als code te beschouwen is: virtuele infrastructuur op clouddiensten zoals Amazon Web Services is dankzij configuratiebeheersystemen zoals Chef en Puppet in code uit te drukken net zoals u dat voor het ontwikkelen van toepassingen doet.
Maakt u gebruik van deze infrastructure as code aanpak, dan kunt u uw infrastructuur samen met uw toepassing ontwikkelen, testen en uitrollen. Voor u een nieuwe release uitrolt, wordt dan automatisch in een testomgeving getest of op infrastructuurniveau alles werkt: is er voldoende servercapaciteit aanwezig, heeft de toepassing toegang tot de databaseserver, werken de logservers? Pas als de toepassing in de testomgeving correct werkt, gebeurt de deployment in de productieomgeving.
Unitt zorgt voor continuous deployment infrastructuur
Unitt helpt u graag om de transformatie te maken naar continuous deployment. Gaat u met ons in zee, dan bekijken we eerst hoe u momenteel uw toepassingen uitrolt. Daarna kijken we hoe we de verschillende stappen kunnen automatiseren met scripts en hoe u zo uiteindelijk de mogelijkheden van continuous deployment benut.
We hebben uitgebreide ervaring met continuous deployment in Amazon Web Services en andere clouddiensten. Zo kunnen we ook het bouwen van cloudinfrastructuur in uw deploymentproces meenemen. Als u dan later bijvoorbeeld extra servercapaciteit nodig hebt, hoeft u daarvoor geen beroep meer te doen op ons, maar bent u in staat om dat zelf te configureren in uw deploymentscripts.
Dat de stabiliteit en betrouwbaarheid van uw productieomgeving heilig zijn voor u, begrijpen we maar al te best. Daarom helpen we u graag om uw deploymentproces zo op te zetten dat alles wat naar de productieomgeving gaat getest is. Om uw toepassing te testen bent u uiteraard zelf het best geplaatst, maar wij vullen dat aan met tests van uw cloudinfrastructuur. Zo testen we of uw toepassing zonder foutmelding start, of de juiste poorten (bijvoorbeeld 80 of 443 voor http respectievelijk https) open staan, of alle buckets voor Amazon S3 waar u uw bestanden plaatst aanwezig zijn, of er load balancers zijn, of de firewallregels correct zijn enzovoort.
We bieden een totaalpakket aan waarbij we als Cloud Architects zowel Public als Private managed Cloud hosting aanbieden. De keuze voor een Public of Private cloudoplossing is gebaseerd op de noden van het project. Unitt heeft dus geen voorkeur voor het ene noch voor het andere. Er wordt altijd geopteerd voor het juiste platform, dat is de belangrijkste driver.
