På Jitterbit är vårt uppdrag att förenkla även de mest komplexa anslutningsutmaningarna och att låta vem som helst bli uppkopplad i dagens digitala värld. Även om vi betonar att du inte behöver vara en utvecklare för att använda Jitterbits produkter – bakom varje bra mjukvarulösning finns ett team av fantastiska utvecklare. I Jitterbit Tech Talk blog serien ger medlemmar av Jitterbits utvecklingsteam oss insikt i att bygga en molnplattform i företagsklass och de utmaningar de var tvungna att lösa kring multi-tenancy, skalbarhet och säkerhet.
Den här veckan tittar Pankaj Arora, vår Senior Director of Technology på hur du designar och skapar en mycket skalbar molnplattform i företagsklass.
Molnet erbjuder företag ett kraftfullt sätt att erbjuda sina produkter och tjänster som är lätta att komma åt från var som helst och på vilken enhet som helst. Det ger också enorma fördelar för leverantören, inklusive insyn i hur deras erbjudande används, snabb utveckling och driftsättning och övergripande minskningar av IT- och underhållskostnader. Som ett resultat, nästan varje company idag vill göra sina lösningar tillgängliga i molnet.
Men det finns mycket mer att bli ett riktigt moln company än att installera programvara på en värdserver och slå "molnet" på ditt marknadsföringsmaterial.
Jag chattade nyligen med en teknikstrateg och de noterade att omkring 75 % av företagen skulle vilja migrera sina äldre företagserbjudanden till molnet. Överraskande nog utarbetar 90 % av dem en första plan som skulle byggas på en arkitektur där deras äldre applikationer bara skulle distribueras på en allmänt tillgänglig molnserver. Detta tillvägagångssätt förnekar alla fördelar som molnet har att erbjuda.
Att bygga en äkta molnplattform med flera innehavare kräver att man löser ett antal olika typer av utmaningar som säkerhet, tillförlitlighet, skalbarhet, hög tillgänglighet, feltolerans, loggning, övervakning, aviseringssystem, möjlighet till kontinuerlig driftsättning och mer.
I dagens inlägg kommer vi att ta en djupare titt på hur vi hanterade utmaningen 'skalbarhet' när vi utvecklade vår molnintegreringsplattform för flera hyresgäster.
Omfattningen av skalbarhet för en applikation är knuten till dess förmåga att skala vertikalt och horisontellt. I en molnmiljö innebär detta att designa tjänster som betjänar externa förfrågningar som skalas så att de kan utnyttja interna backend-system som databaser, cachar, mediatorlager, batchprocesser (analytisk motor, rekommendationsmotor) etc för att hantera praktiskt taget oändliga förfrågningar på ett rimligt sätt kort tid. Det är inte alltid möjligt att förutsäga antalet användare som träffar din plattform. Att utforma en arkitektur som tar hänsyn till detta i multi-tenancy-modellen hjälper till att göra denna osäkerhet till en generisk skalbarhetsfråga.
Vertikal skalning
Vertikal skalbarhet innebär att man lägger till resurser som ytterligare processorer eller minne till en enda nod i ett system, och detta bör vara det första du tänker på när du skalar dina tjänster. Det är mycket viktigt att utforma dina applikationer så att de utnyttjar dessa resurser optimalt. Ta det vanliga användningsfallet för vår hybridintegrationsmolnplattform, där integrationsoperationer betjänas av lokal eller molnservernod. Här bör tjänsterna ta emot en förfrågan om att köra integrationer, skicka förfrågan till servernoder och fortsätta betjäna fler förfrågningar. Tjänsteskiktet bör inte vara beroende av eller blockeras av de processer som sker på olika skikt i systemet. Som sådan är det mycket viktigt att ha en asynkron, händelsedriven arkitektur.
Ett enkelt sätt att förstå asynkron arkitektur är att tänka på din arkitektur som en restaurang. En servitör tar emot beställningar från ett bord och skickar dem till kocken. Medan kocken, matlöparen och buspojken sköter aktiviteter som matlagning, servering och städning, fortsätter servitören att betjäna nya kunder och kör kontroller i slutet av tjänsten.
Att bibehålla asynkronitet medan systemet fungerar med alla komponenter som databas, cache och mediatorlager är mycket viktigt. Genom att överföra belastning till klustrade, högtillgängliga servernoder som kör integrationer frigörs resurserna för servicelagret för att ta fler förfrågningar och svara när processer är slutförda.
Horisontell skalning
Nästa viktiga övervägande bör vara att tjänsterna är skrivna på ett sätt så att det inte spelar någon roll hur många instanser av dessa tjänster som körs och vilket delat system som utför transaktioner vid varje given tidpunkt. Detta ger vår molnplattform flexibilitet att automatiskt skala tjänsteskiktet. Varje del av backend är mycket tillgänglig och automatiskt skalbar för att hålla jämna steg med efterfrågan på växande tjänstecontainrar.
Vi kan dock inte ha oändliga behållare som kör servicelager som använder delade komponenter. Det är inte den optimala designen. Låt oss gå tillbaka till vårt restaurangexempel. Med vertikal skalning kan en enskild restaurang bli mycket skalbar genom att lägga till mer personal, men vid en viss tidpunkt kommer antalet resurser (kockar, löpare, busspojkar) att nå en mättnadspunkt. För att skala ytterligare skulle denna verksamhet behöva öppna ytterligare platser som skulle hjälpa till att distribuera kunder och balansera belastningen.
Det är bättre att dela upp hela plattformen i flera zoner, där varje zon beter sig som en kopia av den ursprungliga zonen. Detta gör att vi kan använda flera zoner för att balansera framtida behov.
Denna modell har flera fördelar:
1. Möjlig oändlig horisontell skalning, eftersom vi kan ta in valfritt antal zoner
2. Feltolerans, om hela zonen misslyckas på grund av en naturkatastrof
3. Dataseparation, i fallet med en SaaS-plattform som kräver till och med platsbaserad metadatasegregering som för USA, EMEA-zoner, etc.
Det önskade resultatet här är att en användares upplevelse ska vara densamma oavsett var de befinner sig och vilken zon de träffar. Inget manuellt ingripande bör krävas av en användare för att få arbetet gjort.
I vår hybridintegrationsmoln blog, diskuterade vi hur vi stötte på utmaningen att använda ett mediatorlager på ett sätt som stödde begränsad vertikal skala. Genom att skriva vårt eget anpassade icke-blockerande anslutningslager baserat på säker HTTPS-transport kunde vi utöka arkitekturen till 50x vertikal skala. Naturligtvis är den horisontellt skalbar också. Denna kombination av vertikal och horisontell skalning gav oss ett billigare och lätt töjbart lager för att möta våra växande behov.
Optimera användningen av delade komponenter:
Delade komponenter bör själva vara skalbara och mycket tillgängliga för att stödja molnplattformen. Men delade komponenter delas och är därför inte lika skalbara som tjänstelagret. Det är mycket viktigt att ta hand om vissa komponenter som kan vara känsliga för hög belastning, till exempel databaser. En modell kan vara att prioritera och köa användningen av delade komponenter där flera, samtidiga högvolymsbelastningar kan orsaka problem. Prioritering kan sänka belastningen och mildra fel på alla uppdragskritiska förfrågningar. Tillbaka i vår restaurang är köket en gemensam komponent och medan servitören kan ta emot en middagsbeställning på förrätt, förrätt och dessert, kommer köket att prioritera tillagningen av dessa föremål och balansera deras belastning.
Ett annat sätt att hantera belastning kan vara cachning av data som sällan ändras för att förhindra hög användning av dessa komponenter. Om pommes frites är ett populärt alternativ på menyn kan restaurangen välja att "cache" en kontinuerlig sats istället för att steka dem på beställning.
Övervakning av komponenter:
Slutligen är det mycket viktigt att övervaka varje komponent och känna till dess begränsningar. Systemet ska kunna öka bandbredden automatiskt och vid rätt tidpunkt för att hålla systemen igång enligt molnplattformens behov. Övervakning kan vara extern eller applikationsinitierad, men i båda fallen är det slutliga målet att låta systemet skalas automatiskt baserat på belastningen.
I nästa blog inlägg kommer vi att prata om övervakning, loggning och andra delar av arkitekturen.
