This post is sponsored by VMware. Learn about VMware virtualization and cloud solutions for small & mid-size business visit info.vmware.com



This article is available in other languages:

This article is available in other languages:

Germany Voordelen van een hybride cloud/virtualisatie systeemFrance Voordelen van een hybride cloud/virtualisatie systeemChina Voordelen van een hybride cloud/virtualisatie systeemNetherlands Voordelen van een hybride cloud/virtualisatie systeemEngland Voordelen van een hybride cloud/virtualisatie systeemPortugal Voordelen van een hybride cloud/virtualisatie systeem

In onze laatste post schreef ik over enkele verschillen tussen het draaien van uw app op cloud hosting van publieke handelswaar en het bouwen van uw eigen privé cloud en hem daar te draaien, en hoe u zou moeten kiezen tussen de twee.

Deze keer wil ik u vertellen dat u niet per se hoeft te kiezen. Tijdens het uitleggen van hoe u uw hosting omgeving moet kiezen, heb ik een belangrijke veronderstelling weggelaten die het een ofwel/of voorstelling maakte, namelijk dat uw gehele applicatie een heterogene set van prestatie, beschikbaarheid en budget beperkingen zou bezitten.

Het is een makkelijke veronderstelling om te maken, aangezien in het algemeen de meeste applicaties worden ontwikkeld op een grootschalige manier, met een code basis, een standaard ontwikkelingsomgeving, en uiteindelijk enkel een productie inzetting. Door het opsplitsen van uw grootschalige app in kleinere onderdelen bent u nu vrij om elk onderdeel te hosten op een omgeving die perfect bij zijn eigen beperking past.

Service of Resource Oriented Architecture

Dit proces van het opsplitsen van uw applicatie wordt over het algemeen Service Oriented Architecture (Service-oriëntatie), of Resource Oriented Architecture genoemd. De juiste naam om te gebruiken hangt af van de manier waarop u uw applicatie opsplitst, en is dit moment voor ons niet echt belangrijk.

In dit artikel praat ik over de voordelen en nadelen van SOA met betrekking tot hosting. Het bereik van het maken van de verandering naar SOA is veel groter dan dit, en ik raad u sterk aan meer onderzoek te doen naar dit onderwerp voordat u zich hieraan bindt.

Een Specifiek Voorbeeld

In het laatste artikel gebruikte ik het voorbeeld van de digitale inhoud marktplaats en hoe we deze hebben verplaatst van de cloud naar een prive virtuele omgeving, voornamelijk uit behoefte naar snellere prestaties en meer beheersing.

Naarmate we nieuwe marktplaatsen openden, veranderde het ladingsprofiel van de applicaties aanzienlijk. We hadden nog steeds de gestage stroom van e-commerce klanten die snelle service nodig hadden, maar met elke nieuwe marktplaats kwamen nieuwe soorten bestanden die werden geupload met sterk verschillende behoeftes voor nabewerking, en deze verschenen in zeer sporadische vensters.

Op dit punt was onze productieomgeving te hard aan het werk om “alle dingen voor alle mensen” te zijn. Wanneer we keken naar de app als iets dat voornamelijk ontworpen was om het zo makkelijk mogelijk te maken om dingen te kopen, was onze beslissing om deze te hosten op onze prive cloud nog steeds verstandig. Wanneer we deze echter bekeken als voornamelijk een platform voor mensen om inhoud aan te dragen (die dan beschikbaar zou zijn voor verkoop) op een grote schaal, maar met een zeer onvoorspelbaar ladingspatroon, dan zou de veelzijdige aard van de openbare cloud logischer zijn voor de app.

Splits de applicatie in tweeën

Wanneer de kosten van het onderhouden van extra capaciteit voor het verwerken van grote toestroom van nieuwe inhoud, en de ingewikkeldheid opliep bij het onderhouden van bestandsopslag om deze allemaal op te slaan, splitsten we de applicatie en verplaatsten 100% van activa opslag en verwerking naar de cloud.

De hoofd productieomgeving zou geuploade inhoud lang genoeg behouden om deze te verplaatsen naar cloud opslag, en de nieuwe activa verwerkingsdienst ervan op de hoogte brengen dat er nieuwe inhoud beschikbaar was. De activa service zou alle benodigde bestandsvalidatie, transformatie, CDN publicatie, etc. doen en dan de hoofdwebsite ervan op de hoogte stellen dat de inhoud klaar voor gebruik is.

Voordelen

Het grootste voordeel zat in het eindpunt. Door het verminderen van de extra capaciteit in onze privé cloud, en het werk verplaatsen naar de openbare cloud waar we capaciteit konden toevoegen en verwijderen wanneer dit nodig was, spendeerden we minder om meer “werk” te voltooien.

Het volgende was verminderde complexiteit in de primaire omgeving. De primaire omgeving was nu 100% gericht op het dienen van de website, en had minder bewegende onderdelen om te onderhouden. Aangezien prestatie om te beginnen een van onze grootste drijfveren voor het kiezen van de privé cloud was, gaf de vereenvoudiging van die omgeving ons minder knelpunten, en maakte het oplossen van problemen wanneer deze zich voordeden een stuk eenvoudiger.

Uiteindelijk maakte het het onderhouden van een grote beschikbaarheid voor onze klanten makkelijker. Door een strenge scheiding tussen de website en activa verwerking te houden, werd het erg moeilijk voor problemen in ons activa systeem om door te sijpelen naar onze website.

Nadelen

Helaas krijgt u niet alle voordelen gratis.

Het eerste nadeel is dat door het bezitten van verschillende componenten in verschillende datacentra, of zelfs in hetzelfde datacentrum aangezien sommige providers fysieke en cloud hosting aanbieden, is dat u wachttijd in uw systeem zal introduceren, en het zal erg wisselvallig zijn.

U zult een aanzienlijke hoeveelheid technische inzet moeten maken om om alle interacties tussen de twee systemen asynchroon en tolerant tegenover fouten te maken. Er is nu erg veel netwerk hardware die u niet onder controle heeft tussen uw twee systemen. Pakketten zullen laat aankomen, of helemaal niet. Wanneer u website enkel werkt wanneer de andere dienst spoedig data terugstuurt, zal uw website niet meer functioneren.

Beveiliging is ook een probleem aangezien uw voormalige “interne” systeemcommunicaties nu worden overgedragen aan het grote enge internet. Het opzetten van een VPN is goed om te doen, of anderzijds als u uw inter-service communicaties via HTTP doet is het om te verzekeren dat al uw diensten robuuste verificatie hebben en op SSL draaien.

Als laatste, de ingewikkeldheid van ontwikkeling en inzetting nemen toe wanneer u van een grootschalige app naar meerdere onafhankelijk gehoste diensten veranderd. Het introduceren van nieuwe functionaliteit zal aanzienlijke inzet voor coördinatie eisen om te verzekeren dat alle diensten samen zullen blijven werken.

Conclusie

Wanneer u moeite heeft uit te vinden of een publieke of privé cloud geschikt is voor uw app, kan het antwoord beide zijn.

Kijk voorzichtig naar uw applicatie. Er zullen misschien twee (of meer) kleinere apps zijn die moeite hebben door te breken, en wanneer ze dit doen, zou het vinden van de juiste hosting omgeving voor elk een stuk simpeler moeten zijn