Bij Jitterbit is het onze missie om zelfs de meest complexe connectiviteitsuitdagingen te vereenvoudigen en iedereen in staat te stellen verbinding te maken in de digitale wereld van vandaag. Hoewel we benadrukken dat je geen ontwikkelaar hoeft te zijn om de producten van Jitterbit te gebruiken, staat achter elke geweldige softwareoplossing een team van fantastische ontwikkelaars. In de Jitterbit Tech Talk blog serie, geven leden van het Jitterbit-ontwikkelteam ons inzicht in het bouwen van een enterprise-class cloudplatform en de uitdagingen die ze moesten oplossen op het gebied van multi-tenancy, schaalbaarheid en beveiliging.
Deze week kijkt Pankaj Arora, onze Sr. Director of Technology, hoe u een zeer schaalbaar cloudplatform van ondernemingsklasse ontwerpt en bouwt.
De Cloud biedt bedrijven een krachtige manier om hun producten en diensten aan te bieden die overal en op elk apparaat eenvoudig toegankelijk zijn. Het biedt ook enorme voordelen voor de leverancier, waaronder inzicht in hoe hun aanbod wordt gebruikt, snelle ontwikkeling en implementatie en algemene verlagingen van IT- en onderhoudskosten. Als gevolg hiervan is bijna elke company today wil hun oplossingen beschikbaar maken in de cloud.
Maar er komt nog veel meer bij kijken om een echte cloud te worden company dan het installeren van software op een gehoste server en het toevoegen van “Cloud” aan uw marketingmateriaal.
Ik was onlangs aan het chatten met een technologiestrateeg en ze merkten op dat ongeveer 75% van de bedrijven hun legacy enterprise-aanbod naar de cloud zou willen migreren. Verrassend genoeg stelt 90% van hen een eerste plan op dat zou worden gebouwd op een architectuur waarin hun legacy-applicaties gewoon zouden worden geïmplementeerd op een openbaar toegankelijke cloudserver. Deze aanpak doet alle voordelen die de cloud te bieden heeft teniet.
Het bouwen van een echt multi-tenant Cloud-platform vereist het oplossen van een aantal verschillende soorten uitdagingen, zoals beveiliging, betrouwbaarheid, schaalbaarheid, hoge beschikbaarheid, fouttolerantie, logboekregistratie, monitoring, meldingssysteem, continue implementatiemogelijkheden en meer.
In de post van vandaag gaan we dieper in op hoe we de 'schaalbaarheid'-uitdaging hebben aangepakt bij het ontwikkelen van ons multi-tenant cloudintegratieplatform.
De mate van schaalbaarheid van een applicatie is gekoppeld aan het vermogen om verticaal en horizontaal te schalen. In een cloudomgeving betekent dit het ontwerpen van services die externe verzoeken bedienen die schaalbaar zijn, zodat ze interne backend-systemen zoals databases, caches, mediatorlagen, batchprocessen (analytische engine, aanbevelingsengine) enz. kunnen gebruiken om praktisch oneindige verzoeken in een redelijk korte tijd. Het is niet altijd mogelijk om het aantal gebruikers op uw platform te voorspellen. Het ontwerpen van een architectuur die hiermee rekening houdt in het multi-tenancy model helpt om van deze onzekerheid een generiek schaalbaarheidsprobleem te maken.
Verticaal schalen
Verticale schaalbaarheid omvat het toevoegen van bronnen zoals extra CPU's of geheugen aan een enkel knooppunt in een systeem, en dit zou het eerste moeten zijn waar u aan denkt bij het schalen van uw services. Het is erg belangrijk om uw applicaties zo te ontwerpen dat ze deze resources optimaal benutten. Neem de veelvoorkomende use-case voor ons hybride integratiecloudplatform, waar integratieactiviteiten worden uitgevoerd door on-premise of cloudserverknooppunten. Hier moeten de services een verzoek indienen om integraties uit te voeren, het verzoek doorgeven aan serverknooppunten en doorgaan met het afhandelen van meer verzoeken. De services-laag mag niet afhankelijk zijn van, of worden geblokkeerd door, de processen die plaatsvinden in verschillende lagen van het systeem. Als zodanig is het erg belangrijk om een asynchrone, gebeurtenisgestuurde architectuur te hebben.
Een eenvoudige manier om asynchrone architectuur te begrijpen, is door uw architectuur te zien als een restaurant. Een ober neemt bestellingen van een tafel en geeft deze door aan de chef-kok. Terwijl de chef-kok, foodrunner en busjongen zorgen voor activiteiten als koken, serveren en schoonmaken, gaat de ober verder met het bedienen van nieuwe klanten en voert hij controles uit aan het einde van de service.
Het handhaven van asynchroniciteit terwijl het systeem werkt met alle componenten zoals database, cache en mediatorlaag is erg belangrijk. Door de belasting door te geven aan geclusterde, zeer beschikbare serverknooppunten die integraties uitvoeren, komen de bronnen vrij voor de servicelaag om meer verzoeken aan te nemen en te reageren wanneer processen zijn voltooid.
Horizontaal schalen
De volgende belangrijke overweging zou moeten zijn dat de services zo zijn geschreven dat het niet uitmaakt hoeveel exemplaren van die services worden uitgevoerd en welk gedeeld systeem op een bepaald moment transacties uitvoert. Dit geeft ons cloudplatform de flexibiliteit om de serviceslaag automatisch te schalen. Elk deel van de backend is zeer beschikbaar en automatisch schaalbaar om de vraag naar groeiende servicecontainers bij te houden.
We kunnen echter geen oneindige containers hebben met servicelagen die gedeelde componenten gebruiken. Dat is niet het optimale ontwerp. Laten we teruggaan naar ons restaurantvoorbeeld. Met verticale schaalvergroting zou een enkel restaurant zeer schaalbaar kunnen worden door meer personeel toe te voegen, maar op een gegeven moment zal het aantal middelen (koks, hardlopers, busjongens) een verzadigingspunt bereiken. Om verder te schalen, zou dit bedrijf extra locaties moeten openen om klanten te verdelen en de last in evenwicht te houden.
Het is beter om het hele platform in meerdere zones te verdelen, waarbij elke zone zich gedraagt als een replica van de oorspronkelijke zone. Hierdoor kunnen we meerdere zones gebruiken om toekomstige behoeften in evenwicht te brengen.
Dit model heeft meerdere voordelen:
1. Mogelijke oneindige horizontale schaling, omdat we een willekeurig aantal zones kunnen toevoegen
2. Fouttolerantie, voor het geval de hele zone uitvalt door een natuurramp
3. Gegevensscheiding, in het geval van een SaaS-platform dat zelfs locatiegebaseerde metagegevensscheiding vereist, zoals voor zones in de VS, EMEA, enz.
Het gewenste resultaat hier is dat de ervaring van een gebruiker hetzelfde moet zijn, ongeacht waar ze zijn en welke zone ze raken. Er zou geen handmatige tussenkomst van een gebruiker nodig moeten zijn om het werk gedaan te krijgen.
In onze hybride integratiecloud blog, bespraken we hoe we tegen de uitdaging aanliepen om een bemiddelaarlaag te gebruiken op een manier die een beperkte verticale schaal ondersteunde. Door onze eigen aangepaste niet-blokkerende verbindingslaag te schrijven op basis van veilig HTTPS-transport, konden we de architectuur uitbreiden tot 50x verticale schaal. Natuurlijk is het ook horizontaal schaalbaar. Deze combinatie van verticale en horizontale schaling gaf ons een goedkopere en gemakkelijk uitbreidbare laag om aan onze groeiende behoeften te voldoen.
Het gebruik van gedeelde componenten optimaliseren:
Gedeelde componenten moeten zelf schaalbaar en zeer beschikbaar zijn om het cloudplatform te ondersteunen. Maar gedeelde componenten worden gedeeld en zijn daardoor niet zo schaalbaar als de services-laag. Het is erg belangrijk om te zorgen voor enkele componenten die gevoelig kunnen zijn voor een hoge belasting, bijvoorbeeld databases. Een model kan zijn om het gebruik van gedeelde componenten te prioriteren en in de wachtrij te plaatsen, waar meerdere, gelijktijdige, grote volumes problemen kunnen veroorzaken. Prioritering kan de belasting verlagen en fouten verminderen bij bedrijfskritieke verzoeken. Terug in ons restaurant is de keuken een gedeeld onderdeel en terwijl de ober de bestelling van een diner voor een aperitief, voorgerecht en dessert opneemt, zal de keuken prioriteit geven aan het koken van deze items en hun lading in evenwicht houden.
Een andere manier om de belasting aan te pakken, kan het cachen van gegevens zijn die zelden veranderen om een hoog gebruik van die componenten te voorkomen. Als frites een populair item op het menu zijn, kan het restaurant besluiten om een continue batch te "cachen" in plaats van ze op bestelling te frituren.
Bewaking van componenten:
Ten slotte is het erg belangrijk om elk onderdeel te controleren en de beperkingen ervan te kennen. Het systeem moet in staat zijn om automatisch en op het juiste moment de bandbreedte te vergroten om de systemen draaiende te houden volgens de behoeften van het cloudplatform. Monitoring kan extern zijn of door een applicatie worden geïnitieerd, maar in beide gevallen is het uiteindelijke doel om het systeem automatisch te laten schalen op basis van de belasting.
In de volgende blog post, zullen we het hebben over monitoring, logging en andere elementen van de architectuur.
