The Alumio
Arkitektur & Säkerhet
Hur fungerar Alumio integrationsplattform?
Alumio är en molnbaserad, low-code "integrationsplattform som tjänst"iPaaS. Som en API-ledd lösning hjälper Alumio till att ansluta flera system, programvara, applikationer och datakällor - över lokala miljöer och molnmiljöer.
Alumio är en low-code och erbjuder ett användarvänligt gränssnitt för både utvecklare och affärsanvändare för att skapa, övervaka och hantera alla integrationer i ett visuellt gränssnitt: utan anpassad kod och med enkla klick-och-konfigurationsalternativ. Alumio presenterar också utvecklarvänliga funktioner för att flexibelt kartlägga och omvandla data, automatisera komplexa arbetsflöden, hantera edge cases och implementera (eller till och med bygga) connector-paket för att bygga snabbare anslutningar och anpassade integrationer.
Alumio integrationsplattform centraliserar all integration och data på ett dedikerat molnutrymme och tillhandahåller single-tenant-infrastruktur och är byggd för att hjälpa företag att utveckla, styra och orkestrera säkra IT på ett skalbart sätt. It hjälper till att synkronisera data mellan alla integrerade system, förhindrar datasilos och minskar dubbleringsfel. Alumio ger datasäkerhet som ständigt förbättras och uppdateras, garanterar minimal driftstopp och är utrustad med återaktiveringsprocedurer, datacache och buffertfunktioner för att säkerställa affärskontinuitet under alla tider.
Medan allt ovanstående kan vara tillräckligt för att förklara Alumio ur affärssynpunkt, är it viktigt för tekniska proffs att utforska arkitekturen som Alumio bygger på för att förstå hur it verkligen fungerar.
Hur ser Alumio arkitektur och säkerhetsinfrastruktur ut?
För att ge en djupgående förståelse för vad som gör Alumio integrationsplattform medlow-code en flexibel, skalbar och framtidssäker lösning, ger detta white paper en teknisk djupdykning i:
Alumio
Alumio säkerhet
Alumio infrastruktur
Alumio prestanda har följande egenskaper
1. Alumio
Upptäck det inre arbetet i vår framtidssäkrade integrationsplattform
Alumio är utformat för att vara en nästa generations API-driven iPaaS (integrationsplattform som tjänst) som hjälper till att skapa, övervaka och hantera framtidssäkrade integrationer och IT . För att uppnå och förkroppsliga denna vision följer det arkitektoniska tillvägagångssättet bakom Alumio följande designprinciper:
Injektion av beroenden
Frikopplad arkitektur
PHP-FIG
Hexagonal design
1.1 Gränssnittet för integration
Alumio användarvänliga webbgränssnitt är utvecklat i React och är frikopplat från backend. Detta gör att frontend-utvecklingen till stor del kan vara oberoende av backend-utvecklingen inom plattformen. Användargränssnittet körs lokalt i användarens webbläsare och kommunicerar direkt till backend via OpenAPI över HTTPS. Användargränssnittet implementerar den autentisering som erbjuds av backend och läser konfiguration, (UI)-scheman etc. från backend.
Separering av affärslogiken i användargränssnittet och backend"
Alumio användargränssnitt tolkar den data som skickas från backend och formaterar it i vyer, formulär, valideringar etc. All data som utbyts mellan användargränssnittet och backend formateras med hjälp av JSON.
1.2 Injektion av beroenden (Dependency Injection, DI)
I traditionell mjukvaruutveckling används dependency injection för att separera problem och användning av objekt. Alumio tillämpar dependency injection-metoden för utveckling och/eller konfiguration av plattformsspecifika komponenter (SOAP, subscribers, transformers, publishers, etc.) Detta gör att konfigurationen kan återanvändas utan att orsaka hinder i programvaran.
Alumio Dependency Injection säkerställer att konfigurationen kan optimeras"
I praktiken innebär det att t.ex. en HTTP-klient kan konfigureras för många olika anslutningar, oberoende av om de hämtar eller skickar data. Dependency injection bidrar till att minska konfigurationen och underhållet som krävs för ett Alumio .
1.3 Aspektorienterad programmering (AOP)
Alumio implementerar AOP (Aspect-Oriented Programming), vilket innebär it olika typer av affärslogik separeras från varandra. Loggning av applikationsbearbetning implementeras automatiskt på grund av AOP, vilket innebär att varje klient, transformer och andra objekt kan ha loggning aktiverad utan att behöva utveckla en loggningsfunktionalitet inom dessa objekt.AOP-punktkorten är tillgängliga även för slutanvändare avAlumio , som sedan kan lägga till DI-plugins till de medföljande punktkorten.
1.4 Konfiguration av integrationer
Alumio har flera olika typer av konfigurationer som beskrivs nedan, nämligen
Konfiguration av Remote
Integrationsspecifik konfiguration
Konfiguration för allmänt ändamål
1.5 Konfiguration för gränssnitt med remote system
Alumio erbjuder flera generiska alternativ för klientkonfiguration för gränssnitt motremote .
Konfiguration av Remote
Konfigurera HTTP-klienter och använd dem för att interagera med HTTP-slutpunkter med hjälp av HTTP-kompatibla metoder. Förfrågningar kan utökas till att innehålla postdata.Autentiseringsmetoder som OAuth 2.0 kan konfigureras på en HTTP-klient med hjälp av DI.
PDO
Konfigurera databasklienter, från MySQL till Oracle, för att hämta och skicka databasdata, utföra lagrade procedurer etc.
SOAP
Konfigurera klienter för att ansluta till en SOAP för att hämta och skicka data med hjälp av vanliga tillgängliga förfrågningsmetoder. Alumio erbjuder en lösning för att anpassa sig till de inneboende skillnaderna mellan SOAP , som att lägga till ett anpassat autentiseringskuvert eller ändringar i meddelandestrukturen.
Filsystem
Konfigurera filsystem för att läsa och skriva filer på tjänster som FTP, SFTP, AWS S3, HTTP, etc. Filsysteminteraktioner utförs stateless.
1.6 Konfiguration för att upprätthålla integrationer
Integrationer mellan remote upprätthålls med hjälp av minst en route, som består av en inkommande konfiguration och en utgående konfiguration. Integrationerna kan vidareutvecklas med hjälp av transformers, som kan tillämpas på rutter, inkommande konfigurationer och utgående konfigurationer. Elementen beskrivs i detalj nedan:
Konfiguration av Remote
Inkommande konfiguration
En inkommande konfiguration använder remoteSOAP, REST, FTP, etc.) för att producera data för nästa del(ar) av den/de route(er) som de är konfigurerade för. En inkommande konfiguration kan ha transformers kopplade till sig för att manipulera de producerade uppgifterna innan uppgifterna skickas vidare.
Notera: i detta skede kan alla utländska filformat (XML, CSV, EDI) konverteras till JSON, eftersom Alumio arbetar med JSON .
It möjligt att använda en enda inkommande konfiguration i flera rutter, vilket möjliggör ett effektivare IT genom att ta emot data en gång och skicka it till flera remote efteråt.
Utgående konfiguration
Utgående konfigurationer kan ha transformers kopplade till sig för att manipulera de mottagna data innan data skickas till remote .
Observera: i detta skede kan JSON konverteras igen till andra filformat (XML, CSV, EDI etc.).
Konfiguration av Transformer
Transformation möjliggör urval/reduktion av data, översättning/mappning, kodning, beräkning, sortering/ordning, sammanslagning/joining/uppslagning från andra källor, aggregering, generering av surrogatnycklar, transponering/pivotering av array/objektnycklar och värden samt validering.
Transformers kan också användas för att filtrera bort hela datapunkter som produceras av inkommande konfigurationer, vilket förhindrar onödiga köobjekt.
1.7 Konfiguration för allmänt ändamål
Integrationer mellan remote upprätthålls med hjälp av minst en route, som består av en inkommande konfiguration och en utgående konfiguration. Integrationerna kan vidareutvecklas med hjälp av transformers, som kan tillämpas på rutter, inkommande konfigurationer och utgående konfigurationer. Elementen beskrivs i detalj nedan:
Miljövariabler
Förvaring
Konfigurera databasklienter, frånMySQL till Oracle, för att hämta och posta databasdata, utföra lagrade procedurer etc.
1,8 Kö
Alla data som kommer in i plattformen och är förberedda för att bearbetas av en utgående konfiguration blir tillgängliga i kön. Dessa köobjekt säkerställer att konfigurerade rutter kan inspekteras och visar task för att visa vilket arbete som har utförts och vad som inte har utförts.
Det finns flera sätt för ett köobjekt att dyka upp: schemalagda inkommande konfigurationer, webhook-anrop till plattformen och proxyförfrågningar via plattformen. Många av dessa är i realtid eller kan konfigureras som sådana.Varje köobjekt innehåller konfigurationsdata: varifrån data kommer och vart it är på väg.
Köobjekten visar också de data som är kopplade till dem.Slutligen visar köobjekten vilken loggning som har gjorts på den inkommande sidan och på den utgående sidan. Dessa logs kan innehålla fel och ge tillgång till felsökningsinformation som HTTP-fel.
1.9 Loggning
Alumio logs all data och alla händelser under behandlingen av inkommande och utgående data.Känslig data som API-lösenord filtreras automatiskt bort från loggdata och krypterade miljövariabler. Loggdata samlas in och synkroniseras till en Elastic Stack.Logginformationen visas för varje skapad task och varje subscribe/publish-åtgärd iAlumio.
Triggers kan skapas inom Elastic Stack baserat på loggdata. Detta kan användas som övervakning. Till exempel kan en varning skickas när ett antal av flera uppgifter misslyckas inom en enda timme.
1.10 Övervakning
Konfigurera triggers för att uppdatera underhållare om integrationernas hälsa, om uppgifter (köobjekt) fastnar, misslyckas med att publicera och så vidare.Itär möjligt att få aviseringar om Alumio via e-post.
1.11 Processor
De flesta integrationer körs i två separata processer, en för inkommande data och en annan för att bearbeta data. Bearbetningen startas vanligtvis med hjälp av en schemaläggare, annars startas it som en del av en realtidsåtgärd på grund av konfigurationsinställningar, som sedan körs tillsammans med processen för inkommande data.
Processorn är ett konfigurerbart element som gör det möjligt för plattformen att ställa in det maximala antalet uppgifter (köobjekt) som ska bearbetas för en viss route. Genom att ställa in ett maximalt antal uppgifter kan plattformen förhindra överbelastning av de mottagande remote . Detta säkerställer att de viktigaste integrationerna fortsätter att fungera medan andra integrationer väntar.
1.12 Lagring av applikationer
Alumio använder Elastic Stack och MySQL för att lagra applikationsdata och logs.De logs som produceras under körningen avAlumio skickas till Elastic Stack och indexeras där för att säkerställa att logs är snabbt tillgängliga från Alumio . Tack vare AOP är dessa logs mycket granulära och kan justeras i takt med att plattformen utvecklas.
Konfiguration, miljövariabler, uppgifter och användare lagras i MySQLNärAlumio utvecklas bibehålls MySQL med migreringar för att göra det möjligt för befintliga projekt att uppgraderas till den senaste versionen av plattformen.
1.13 Bearbetningsanslutning
Utlösta inkommande anslutningarWebhooks
Webhooks gör det möjligt för system att skicka automatiska meddelanden eller information tillAlumio.Itär ett kraftfullt sätt att automatiskt pusha data från en app till en annan.
Transparenta realtidsanslutningar (HTTP Proxy)
Schemalagda inkommande anslutningar
Utgående anslutningar i schemalagd tid/realtid
1.14 Autentisering
Autentiseringen medAlumio API är säkrad med Google OAuth. När användare har skapats iAlumio kan de logga in i Alumo med flera olika metoder:
1. Google-konto Microsoft
2. Socialt konto (företagskonton stöds inte)
3. Azure AD, SAML, Okta, ADFS, OpenID, LDAP, Google Workspace (endast Enterprise-licenser)
4. Registrering av ett nytt Alumio
För extra säkerhet krävs multifaktorautentisering (MFA) för att logga in i Alumio .
Som standard läggs en kunddomän till i kundens Alumio . Användare med ett tilldelat Google-konto kommer automatiskt att tillhandahållas till plattformen. Konfigurationen avgör om användaren har visningsrättigheter eller rättigheter att skapa och/eller redigera.
1.15 JSON
Alumio använder JSON för att erbjuda ett tydligt dataformat att kommunicera med. Schemana används för att bestämma hur användarinmatning ska se ut, hur konfigurationsobjekt ska definieras, hur formulär ska renderas etc. Dessa scheman skapar ett tydligt och konsekvent applikationsgränssnitt.
1.16 Typer av dataenheter
Dataenheter för fördefinierade element är standardiserade så långt det är möjligt. Detta innebär attAlumio har en mellanliggande standard för många typer av dataenheter (t.ex. order, produkter, kreditnotor, personer etc.). Att ha dessa mellanliggande standarder minskar komplexiteten i gränssnittet mot (delvis) kända system, minskar de mutationer som krävs för de givna uppgifterna och den övergripande komplexiteten i konfigurationen av dataflöden.
1.17 Symfony - Alumio ramverk för utveckling
Alumio är utvecklat på Symfony, som erbjuder många färdiga och generiska funktioner som har implementerats iAlumio. Symfonys beroendeinjektion kopplar samman alla större komponenter iAlumio .
Alumio huvudkomponenter är i huvudsak de funktioner som kan utökas med hjälp av vårt modulära system. Detta inkluderar komponenter som autentisering, Alumio dependency injection, OpenAPI, loggning, inkommande, utgående och många fler. Symfony erbjuder också mer vanliga komponenter som kan implementeras som Doctrine.
Uppfinn inte hjulet på nytt:Alumio använder Symfony-bibliotek för generiska funktioner"
Om Symfony: Itär världens ledande ramverk med en stor uppsättning frikopplade och återanvändbara komponenter som några av de bästa applikationerna är byggda på. Symfony Community består av över 600.000 utvecklare från mer än 120 länder som omfamnar och främjar bästa praxis, standardisering och interoperabilitet för applikationer. Symfony är allt som du kan förvänta dig av ett ramverk: snabbhet, flexibilitet, återanvändbara komponenter etc.
1.18 OpenAPI/Swagger
Alumio exponerar sina funktioner genom OpenAPI, den moderna öppna standarden för API-definition. Varje åtgärd definieras och görs tillgänglig via detta API med tydliga scheman för att skicka och hämta data. Alla element som visas/redigeras i Alumio användargränssnitt analyseras via detta API. Även bearbetning av rutter kan utföras via API:et, t.ex. exekvering av en inkommande konfiguration och export av data från en given route.
Ange din e-postadress för att fortsätta läsa denna sida
2. Alumio säkerhet
Upptäck de höga säkerhetsstandarderna för vår integrationsplattform
Vår integrationsplattform flyttar data från ett system till ett annat, vilket kan innehålla kritisk information om ditt företag, finansrelaterade data och personlig och identifierbar information (PII) om dina kunder. Säkerheten för dina data måste garanteras.
Säkerhet finns i vårt DNA och är inbäddat från en teknisk nivå i varje Alumio . Säkerheten för våra produkter, vår infrastruktur och våra data är vår högsta prioritet. Vårt säkerhets- och riskhanteringsteam arbetar enligt branschstandarder för att säkerställa att dina data är säkra. För att säkerställa att vår efterlevnad och säkerhet uppfyller de högsta standarderna övervakar vi vår plattform i stor utsträckning. Vårt produktteam arbetar ständigt med att förbättra och uppdatera plattformen för att uppfylla de senaste säkerhetsstandarderna, för att ge våra kunders data bästa möjliga säkerhet.
2.1 Säkerhet genom design
Alumio integrationsplattform är byggd med hjälp av de bästa tekniska ramverken och säkra metoder för mjukvaruutveckling. Alla korrigeringar, nya funktioner och förbättringar släpps först efter flera rigorösa tester och en strikt granskningsprocess. Vårt testprogram består av automatiserad kodtestning avseende kodkvalitet, samt manuell testning där varje kodrad kontrolleras och testas av minst två seniora utvecklare.
Alumio io-ingenjörer utvecklar kärnapplikationen baserat på konceptet "Security-by-Design":
2.2 Överensstämmelse med säkerhetsstandarder
Alumio är stolta över sitt åtagande att skydda känslig information. Som ett bevis på detta har Alumio genomgått en rigorös implementeringsprocess och uppnått överensstämmelse med ISO 27001, en internationellt erkänd standard för ledningssystem för informationssäkerhet. Denna standard fastställer bästa praxis och riktlinjer för att upprätta, implementera, underhålla och kontinuerligt förbättra ledningssystem för informationssäkerhet för att säkerställa konfidentialitet, integritet och tillgänglighet för information.
2.3 Åtkomst till integrationsplattformen Alumio
Tillträdet förklarades:
Rollbaserad åtkomstkontroll (RBAC)
Våra medarbetare har åtkomst baserat på användarroller med begreppet "least privilege", vilket innebär att ingen åtkomst beviljas till en nivå som inte beskrivs som nödvändig i "rollen".
Säkerhet för Remote
Remote till Alumio kodbas och infrastruktur är endast möjlig efter inloggning på företagets VPN. Inloggning till Alumio kan ske genom en inloggningsprocedur med tvåfaktorsautentisering.
IP-vitlistning
Tillgång till Alumio kodbas och infrastruktur är endast möjlig efter inloggning på företagets VPN. Dessa IP-adresser är statiska och är vitlistade av våra systemadministratörer.
Tillgång till leverantörssupport
Leverantörsåtkomsten är baserad på Amazon Web Services säkerhetsåtgärder.
Spårning av användare
Alla användarinloggningar loggas, t.ex. inloggnings-ID (användarnamn, Fan-ID), datum/tid för senaste inloggning, plats för inloggning (t.ex. IP-adress), enhetsidentifierare (t.ex. MAC-adress). logs skickas till en plats med ett särskilt åtkomstkrav under en period på 8 veckor.
Regelbundna granskningar av åtkomst
Alumio har en process på plats som säkerställer att regelbundna åtkomstgranskningar kommer att hållas. Dessa kommer att meddela chefer om problem med offboarding, vilket gör det möjligt för Alumio att uppdatera våra processer och åtgärda eventuella ändringar som krävs.
Kryptering av hårddisk
Alumio är skyldiga att tillämpa hårddiskkryptering på sina lokala maskiner, vilket framgår av onboardingpolicyn för anställda.
Konfiguration av brandvägg
Alumio är skyldiga att tillämpa brandväggskonfiguration på sina lokala maskiner, vilket anges i onboardingpolicyn för anställda.
Anställda inom teknik, tjänster, support och drift (i princip alla som har tillgång till något som anses vara säkerhetskänsligt) måste använda företagets VPN med multifaktorautentisering aktiverad för att lagra och generera alla referenser som används för att utföra arbetsuppgifter.
Anställda inom teknik med tillgång till produktionssystem måste också genomgå olika nivåer av säkerhetsutbildning minst en gång om året. Alla våra medarbetare beviljas alltid endast tillgång till det minimala antal applikationer eller system som behövs för att utföra deras arbetsuppgifter.
2.4 Säkerhet för nätverk och infrastruktur
Ansvarsområden:
Amazon Web Services är ansvarig för:
Elastic är ansvarig förAmöjlig för:
Amazon Web Services är ansvarig för:
Alumio följer riktlinjerna och bästa praxis för följande säkerhetsstandarder:
2.5 Nätverk: datalagring och datahantering
All kommunikation från och till Amazon Web Services och Alumio datacenter använder minst SSL 256-bitars kryptering och sker via HTTPS, port 443.
Standardinställningar:
Data vid rest:
Data under transport:
2.6 Lagring och bearbetning av data
Alumio har tre sätt att lagra data:
Loggning
Förvandlingsspår
Förvaring
2.7 Automatiserad kommunikation av data
Alumio överför automatiskt följande information till Amazon Web Services datacenter:
Online Status:
Utskick:
Spårningsinformation:
Uppdateringar av integrationsprocessen:
2.8 Användarinitierad kommunikation av data
På begäran av en behörig användare kommunicerar Alumio följande till Alumio datacenter:
Information om utförandet av en integrationsprocess, inklusive total exekveringstid, loggning för varje steg i processen och felmeddelanden vid exekveringsfel. API-data eller task logs (meddelanden via routes = uppgifter) sparas i 2 veckor. Serverrelaterade logs sparas i en månad. Båda är konfigurerbara efter behov baserat på den Alumio som köpts.
Alumio erbjuder möjligheten att tillhandahålla export av logs. Varje behörig användare kan exportera task logs.
Alumio off-site gör säkerhetskopior av följande:
När processer byggs för specifika anslutningar kan information om databasscheman överföras för att definiera regler för mappning av fält. Inga faktiska data överförs.
2.9 Säkerhet för datakommunikation i lokalerna
Inga inkommande brandväggsportar behöver vara öppna för att Alumio integrationsplattform ska kunna kommunicera med datacentret. Alumio integrationsgränssnitt initierar alltid anslutningen; Amazon Web Services datacenter skickar aldrig data automatiskt till Alumio integrationsplattform (eller privat värdlösning). När Alumio initierar en anslutning använder it en SSL-handskakning för att autentisera datacentret innan data överförs. Alumio använder det digitala certifikat som automatiskt skapas under registrering och autentisering.
3. Alumio infrastruktur
Läs mer om vad som gör vår integrationsplattform skalbar, säker och framtidssäkrad
Alumio integrationsplattform är en molnbaserad lösning som levereras i en infrastruktur med en enda hyresgäst i den region där vår kund finns. Oavsett om itär Europa, Asien eller USA, erbjuder Alumio snabb, säker och kompatibel driftsättning av vår integrationsplattform. Alumio licensmodell inkluderar hosting/applikation (management) och uppdateringar. Alumio tillhandahåller nätverk, servrar, lagring, operativsystem (OS), databas och andra tjänster för att vara värd för konsumentens köpta Alumio .
Hostinginfrastrukturen är en viktig aspekt som påverkar plattformens skalbarhet. Alumio levererar högpresterande hostinginfrastrukturer som är redo för världsomspännande utrullning till små och medelstora företag och internationella företag.
3.1 Övervakning
I jämförelse med ESB är iPaaS en molnbaserad plattform som använder en relativt lätt arkitektur och inte behöver någon lokal installation. Medan både ESB och iPaaS är specialiserade på att integrera legacy systems, kan iPaaS flexibelt ansluta till många fler stora eller små SaaS, molnapplikationer och datakällor, både i lokala miljöer och i molnmiljöer.
Medan ESB implementerar en komplex meddelandearkitektur för att ansluta applikationer, antar iPaaS en API-första strategi. Detta hjälper iPaaS att bygga snabbare och mer flexibla integrationer, som enkelt kan ändras eller genomgå datatransformation, utan att dataintegriteten eller affärskontinuiteten går förlorad.
Som tidigare nämnts måste en ESB dessutom drivas av erfaren IT som är noggrant utbildad och tränad i att implementera it. iPaaS tillhandahåller däremot ett molnbaserat webbgränssnitt som både utvecklare och vanliga användare (CTO:er, projektledare, juniora utvecklare) kan samarbeta med på distans för att utveckla, styra och orkestrera integrationer.
3.2 Säkerhetskopior
För att förhindra dataförlust är it nödvändigt att göra regelbundna säkerhetskopior. Till skillnad från många leverantörer väljer Alumio säkerhetskopiering baserad på filbaserad säkerhetskopieringsteknik. Detta ger Alumio möjlighet att återställa även en enskild fil. It kan avsevärt minska återställningstiden och ger mer komfort för utvecklare som letar efter specifika filer.
Alumio använder R1Soft, som är marknadsledande på marknaden för avancerade backup-program. Som standard förutsätter säkerhetskopian 1 återställningspunkt, som kompletteras med "ändringarna" från återställningsmomentet. Dessa backuper görs utanför din molnmiljö och är främst avsedda för att snabbt få tillgång till en komplett kopia av din miljö vid en eventuell katastrof. Säkerhetskopian är en fullständig säkerhetskopia och kommer att skrivas varje natt till en NAS-server (Network Attached Storage) i nätverket, men utanför din molnmiljö. Denna backup kan användas om din server oväntat skulle gå sönder. Inom Alumio standard servicenivåer görs backupen 1 gång per dag och lagras i 7 dagar.
Alumio kan återställa varje dag inom denna period. Dessutom är it möjligt att utöka och intensifiera backupschemat, skicka backuperna till din fysiska plats och skapa flera återställningspunkter.
3.3 Katastrofåterställning
Alumio säkerställer att återställning alltid kan ske vid allvarliga driftstörningar. Katastrofåterställning tar tid. Därför skiljer sig den tid som planeras per SLA-variant. Standard SLA anger att Alumio behöver mellan 1 - 2 timmar under kontorstid för att påbörja återställning av din data. Den tid som krävs för att återställa applikationen i sin helhet beror på storleken på din applikation (antal GB) men är +/- 1 timme per 10 GB data som ska återställas. Alumio infrastrukturhantering förlitar sig också på Amazon Disaster Recovery och Elastic Disaster Recovery policy och procedurer.
3.4 Regioner och strategier för driftsättning
När din instans av Alumio driftsätts väljer it en primär driftsättningsregion för ditt företag baserat på ditt val. Din primära driftsättningsregion innehåller all din Alumio och är där dina huvudsakliga organisationsprocesser äger rum. Detta gäller hostinginfrastrukturen som levereras av Amazon Web Services och Elastic Stack.
3.5 Driftsättning i flera regioner
Alumio rekommenderar Enterprise businesses som en klustrad lösning för en högpresterande infrastruktur som är redo för utrullning över hela världen.
Den högpresterande infrastrukturen är ett Kubernetes-baserat system för att automatisera utrullning, skalning och hantering av containeriserade applikationer inom flera regioner.
3.6 Skalbarhet
wise är it lika skalbart som Amazon Web Services kan erbjuda. De funktioner som utvecklats i Alumio är utformade med skalbarhet i åtanke. All logik kan dock ersättas med anpassad logik för att förbättra prestanda och därmed skala upp.
Skalning kan göras enligt inställningar, och dessa kan sättas upp per region (t.ex. ett land). Detta är dock troligen inte nödvändigt.
Att ha skalbarhet medför viss komplexitet när det gäller konfigurationen av Alumio . Annars är den enda begränsningen begränsningarna för hosting.
4. Alumio
Säkerställa kontinuitet i verksamheten och hög drifttid för programvaruanslutningar
Det finns flera andra viktiga aspekter av Alumio integrationsplattform som bidrar till att förbättra dess prestanda, säkerhet och tillförlitlighet:
4.1 Robust lagrings- och kösystem
Datapaket som "in-process data" lagras tillfälligt i vårt robusta kösystem, beroende på typ av transformation och valt Alumio , i MySQL, Elastic, Apache spark, Google GCP eller Amazon Redshift.
De används för att garantera bearbetning i stor skala för alla enskilda sidor med data i transit. Om något system går offline möjliggör arkitekturen ovan en elegant paus och återupptagande av flödesbearbetningsaktiviteter utan förlust av data.
4.2 Stora datamängder
Alumio är byggt som en högpresterande integrationsplattform för att hjälpa externa applikationer att kopplas samman och hantera stora datamängder. Data omvandlas till mindre paket som kallasAlumio tasks". Dessa kan flöda genom vårt system på ett skalbart sätt till externt anslutna applikationer via vårt API, med stöd av vår robusta köningsmekanism.
4.3 DevOps
Alumio har ett komplett DevOps-team som övervakar Alumio 24/7. DevOps-teamet har personer på flera platser och varje teammedlem är fullt utrustad för att arbeta på distans eller från ett Alumio .
4.4. Användning av kodstandarder
Alumio kärnteam har definierat en mjukvaruutvecklingsprocess för att säkerställa att Alumio bibehåller skalbarhet, tillförlitlighet och är 100% tillgängligt. SDLC är den process som följs för varje programvaruprojekt (komponent) i Alumio . Varje projekt består av en detaljerad plan som beskriver hur man utvecklar, underhåller, ersätter och ändrar eller förbättrar specifik programvara. Denna metodik säkerställer kvaliteten på Alumio integrationsplattform.
Alumio utvecklar och förbättrar sina applikationer genom att använda sunda SDLCmetoder (Software Development Lifecycle) som t.ex:
Affärsresultaten av Alumio arkitektur & säkerhet
En nästa generations integrationsplattform för snabba, flexibla och framtidssäkrade integrationer
Nu när vi har utforskat Alumio arkitektur, säkerhetsdesign, skalbara infrastruktur och prestandafördelar på djupet, låt oss sammanfatta hur allt detta samverkar för att driva det som Alumio integrationsplattform tillhandahåller. Här är några av de viktigaste användningsområdena och fördelarna som Alumio iPaaS (integrationsplattform som tjänst) är utformad för att tillhandahålla:
Alla dataflöden i integrerade system görs synliga och tillgängliga i ett användarvänligt gränssnitt, vilket förhindrar problem med svarta lådor och möjliggör enkla konfigurationer.
Se till att data synkroniseras och bearbetas i realtid, omvandla data på ett flexibelt sätt och använd datakartläggning och datarouting för att minska dubblering och förbättra noggrannheten.
Ett robust övervaknings- och loggningssystem hjälper till att snabbt upptäcka och meddela integrationsfel och API-konflikter, vilket sparar kostnader och tid på felsökning.
Minska manuellt arbete och datainmatning genom att automatisera processer som produktoptimering, rekrytering, fakturering, lagerhantering, marketing, kundsupport och mycket mer.
Flytta och förenhetliga data från legacy systems med ETL, migrera anpassade fält och anpassade objekt och implementera förkonfigurerade anslutningar för att integrera legacy systems med molnapplikationer.
Organisera alla integrationer och data från en intuitiv instrumentpanel. Lägg till eller ersätt programvaruintegrationer på ett smidigt sätt. Ta bort datasilos och öka plattformens resurser i takt med att dina integrationer växer.
Anslut data och system från alla partners, leverantörer och kunder med hjälp av anpassade standardprotokoll och format som JSON, Edifact, X12, CSV, XML och cXML.
Skapa datasjöar eller helt enkelt samla all data från olika uppkopplade system för att bli ett hyperlärande, "digital-first and data-driven" företag.
Undvik systemavbrott och säkerställ kontinuitet i verksamheten med hjälp av cachning, databuffring och återaktiveringsprocedurer för dina integrationer och IT .
Samla alla dina data och anslutna system på ett säkert molnutrymme, få full datakontroll och följ viktiga sekretesslagar som GDPR, SOC2, CCPA, FERPA, HIPAA med flera.
