Het Alumio
Architectuur en beveiliging
Hoe werkt het Alumio-integratieplatform?
Alumio is een cloudgebaseerd, low-code „Integration Platform as a Service” (iPaaS). Als API-gestuurde oplossing helpt Alumio meerdere systemen, software, applicaties en gegevensbronnen met elkaar te verbinden, zowel op locatie als in de cloud.
Als low-code oplossing biedt Alumio een gebruiksvriendelijke interface voor zowel ontwikkelaars als zakelijke gebruikers om alle integraties op één visuele interface te creëren, te monitoren en te beheren: zonder aangepaste code en met eenvoudige klik-en-configuratie-opties. Alumio biedt ook ontwikkelaarsvriendelijke functies om gegevens flexibel in kaart te brengen en te transformeren, complexe workflows te automatiseren, randgevallen aan te pakken en connectorpakketten te implementeren (of zelfs te bouwen) om snellere verbindingen en aangepaste integraties te bouwen.
Het Alumio-integratieplatform, dat alle integratie en gegevens op één speciale cloudruimte centraliseert en een infrastructuur met één tenant biedt, is gebouwd om bedrijven te helpen bij het ontwikkelen, beheren en orkestreren van veilige IT-ecosystemen op een schaalbare manier. Het helpt bij het synchroniseren van gegevens tussen alle geïntegreerde systemen, voorkomt datasilo's en vermindert duplicatiefouten. Alumio biedt gegevensbeveiliging die voortdurend wordt verbeterd en bijgewerkt, garandeert minimale downtime en is uitgerust met reactiveringsprocedures, gegevenscaching en buffermogelijkheden om de bedrijfscontinuïteit te allen tijde te garanderen.
Hoewel al het bovenstaande voldoende kan zijn om Alumio vanuit een zakelijk oogpunt uit te leggen, is het voor technische professionals belangrijk om de architectuur te verkennen waarop Alumio is gebouwd, om te begrijpen hoe het echt werkt.
Wat omvat de Alumio-architectuur en beveiligingsinfrastructuur?
Om een diepgaand inzicht te bieden in wat het Alumio low-code integratieplatform tot een flexibele, schaalbare en toekomstbestendige oplossing maakt, biedt deze whitepaper een technische diepgaande duik in:
De Alumio-architectuur
De beveiliging van het Alumio-platform
De Alumio-infrastructuur
De prestatiekenmerken van Alumio
1. De Alumio-architectuur
Ontdek de interne werking van ons toekomstbestendige integratieplatform
Alumio is ontworpen als een API-gestuurde iPaaS (Integration Platform as a Service) van de volgende generatie die helpt bij het creëren, monitoren en beheren van toekomstbestendige integraties en IT-ecosystemen. Om deze visie te bereiken en te belichamen, volgt de architecturale benadering achter het Alumio-platform de volgende ontwerpprincipes:
Dependency injection
Ontkoppelde architectuur
PHP-FIGUUR
Zeshoekig ontwerp
1.1 De integratie-interface
De gebruiksvriendelijke webinterface van Alumio is ontwikkeld in React en is losgekoppeld van de backend. Hierdoor kan front-end development grotendeels onafhankelijk zijn van de backend-ontwikkeling binnen het platform. De gebruikersinterface draait lokaal in de browser van de gebruiker en communiceert rechtstreeks met de backend via OpenAPI via HTTPS. De gebruikersinterface implementeert de authenticatie die door de backend wordt aangeboden en leest de configuratie, (UI) -schema's, enz. uit de backend.
De bedrijfslogica van de gebruikersinterface en de backend scheiden”
De gebruikersinterface van Alumio interpreteert de gegevens die door de backend worden verzonden en formatteert deze in views, formulieren, validaties, enz. Alle gegevens die worden uitgewisseld tussen de gebruikersinterface en de backend worden geformatteerd met JSON.
1.2 Afhankelijkheidsinjectie (DI)
Bij traditionele softwareontwikkeling wordt afhankelijkheidsinjectie gebruikt om problemen en het gebruik van objecten te scheiden. Alumio past de Dependency Injection-benadering toe op de ontwikkeling en/of configuratie van platformspecifieke componenten (HTTP/SOAP/Database/FileSystem-clients, abonnees, transformatoren, uitgevers, enz.). Hierdoor kan de configuratie opnieuw worden gebruikt zonder belemmeringen in de software te veroorzaken.
De Alumio Dependency Injection zorgt ervoor dat de configuratie kan worden geoptimaliseerd”
In de praktijk betekent dit dat bijvoorbeeld één HTTP-client kan worden geconfigureerd voor veel verschillende verbindingen, ongeacht of ze gegevens ophalen of verzenden. De afhankelijkheidsinjectie helpt de configuratie en het onderhoud dat nodig is voor een Alumio-project te verminderen.
1.3 Aspectgericht programmeren (AOP)
Alumio implementeert AOP (Aspect-Oriented Programming), wat betekent dat het verschillende soorten bedrijfslogica van elkaar onderscheidt. Logging van applicatieverwerking wordt automatisch geïmplementeerd dankzij AOP, wat betekent dat voor elke client, transformator en andere objecten logboekregistratie kan worden ingeschakeld zonder dat binnen deze objecten een logfunctie hoeft te worden ontwikkeld. De AOP-pointcuts zijn ook beschikbaar voor eindgebruikers van Alumio, die vervolgens DI-plug-ins kunnen toevoegen aan de meegeleverde pointsneden.
1.4 Configuratie van integraties
Alumio heeft verschillende configuratietypen die hieronder worden beschreven, namelijk:
Configuratie van systeeminterfaces op afstand
Integratiespecifieke configuratie
Configuratie voor algemene doeleinden
1.5 Configuratie om te communiceren met systemen op afstand
Alumio biedt verschillende generieke client-configuratie-opties om te communiceren met systemen op afstand.
Configuratie van systeeminterfaces op afstand
Configureer HTTP-clients en gebruik ze om te communiceren met HTTP-eindpunten met behulp van HTTP-compatibele methoden. Verzoeken kunnen worden uitgebreid om postgegevens te bevatten. Authenticatiemethoden zoals OAuth 2.0 kunnen op een HTTP-client worden geconfigureerd met DI.
GEPEUPEL
Configureer databaseclients, variërend van MySQL tot Oracle, om databasegegevens op te halen en te posten, opgeslagen procedures uit te voeren, enz.
SOAP
Configureer clients om verbinding te maken met een SOAP-service om gegevens op te halen en te posten met behulp van algemeen beschikbare aanvraagmethoden. Alumio biedt een oplossing om zich aan te passen aan de inherente verschillen tussen SOAP-services, zoals het toevoegen van een aangepaste authenticatie-envelop of wijzigingen in de berichtstructuur.
Bestandssystemen
Configureer bestandssystemen om bestanden te lezen en te schrijven op services zoals FTP, SFTP, AWS S3, HTTP, enz. Bestandssysteeminteracties worden stateloos uitgevoerd.
1.6 Configuratie om integraties te behouden
Integraties tussen systemen op afstand worden onderhouden via ten minste één route, bestaande uit een inkomende configuratie en een uitgaande configuratie. Integraties kunnen verder worden uitgebreid door transformatoren te gebruiken, die kunnen worden toegepast op routes, inkomende configuraties en uitgaande configuraties. De elementen worden hieronder in detail beschreven:
Configuratie van systeeminterfaces op afstand
Inkomende configuratie
Een binnenkomende configuratie maakt gebruik van een configuratie met een externe systeeminterface (SOAP, REST, FTP, enz.) om gegevens te produceren voor het volgende deel (en) van de route (s) waarvoor ze zijn geconfigureerd. Aan een inkomende configuratie kunnen transformatoren worden gekoppeld om de geproduceerde gegevens te manipuleren voordat de gegevens worden doorgegeven.
Opmerking: in dit stadium kunnen alle buitenlandse bestandsindelingen (XML, CSV, EDI) worden geconverteerd naar JSON, aangezien Alumio met het JSON-schema werkt.
Het is mogelijk om één binnenkomende configuratie op meerdere routes te gebruiken, wat een efficiënter IT-landschap mogelijk maakt door gegevens één keer te ontvangen en deze daarna naar meerdere systemen op afstand te sturen.
Uitgaande configuratie
Bij uitgaande configuraties kunnen transformatoren worden aangesloten om de ontvangen gegevens te manipuleren voordat de gegevens naar systemen op afstand worden verzonden.
Opmerking: in dit stadium kunnen de JSON-gegevens opnieuw worden geconverteerd naar andere bestandsindelingen (XML, CSV, EDI enz.)
Transformatorconfiguratie
Transformatie maakt gegevensselectie/-reductie, vertaling/toewijzing, codering, berekening, sorteren/ordenen, samenvoegen/samenvoegen/opzoeken uit andere bronnen, aggregatie, genereren van surrogaatsleutels, transponeren/draaien van array-/objectsleutels en -waarden en validatie mogelijk.
Transformers kunnen ook worden gebruikt om volledige datapunten uit inkomende configuraties te filteren, waardoor onnodige wachtrij-items worden voorkomen.
1.7 Configuratie voor algemeen gebruik
Integraties tussen systemen op afstand worden onderhouden via ten minste één route, bestaande uit een inkomende configuratie en een uitgaande configuratie. Integraties kunnen verder worden uitgebreid door transformatoren te gebruiken, die kunnen worden toegepast op routes, inkomende configuraties en uitgaande configuraties. De elementen worden hieronder in detail beschreven:
Omgevingsvariabelen
Opslag
Configureer databaseclients, variërend van MySQL tot Oracle, om databasegegevens op te halen en te posten, opgeslagen procedures uit te voeren, enz.
1.8 Wachtrij
Alle gegevens die het platform binnenkomen en voorbereid zijn om te worden verwerkt door een uitgaande configuratie, worden beschikbaar in de wachtrij. Deze wachtrijitems zorgen ervoor dat geconfigureerde routes inspecteerbaar zijn en geven de taakstatus weer om te laten zien welk werk is gedaan en wat niet.
Er zijn meerdere manieren waarop een item in de wachtrij kan worden weergegeven: geplande inkomende configuraties, webhook-oproepen naar het platform en proxyaanvragen via het platform. Veel hiervan zijn realtime of kunnen als zodanig worden geconfigureerd. Elk item in de wachtrij bevat configuratiegegevens: waar de gegevens vandaan komen en waar ze naartoe gaan.
De items in de wachtrij tonen ook de gegevens die ermee verbonden zijn. Ten slotte geven de items in de wachtrij weer welke logboekregistratie is gedaan aan de inkomende kant en aan de uitgaande kant. Deze logboeken kunnen fouten bevatten en bieden toegang tot foutopsporingsinformatie, zoals HTTP-fouten.
1.9 Loggen
Alumio registreert alle gegevens en gebeurtenissen tijdens de verwerking van inkomende en uitgaande gegevens. Gevoelige gegevens, zoals API-wachtwoorden, worden automatisch uit de loggegevens en versleutelde omgevingsvariabelen gefilterd. Loggegevens worden verzameld en gesynchroniseerd met een Elastic Stack. De loginformatie wordt weergegeven voor elke gemaakte taak en elke abonneer-/publicatieactie in Alumio.
Triggers kunnen binnen de Elastic Stack worden gemaakt op basis van de loggegevens. Dit kan worden gebruikt als monitoring. Er kan bijvoorbeeld een waarschuwing worden verzonden wanneer meerdere taken binnen een uur mislukken.
1.10 Toezicht
Configureer triggers om beheerders op de hoogte te houden van de status van integraties, of taken (wachtrij-items) vastlopen, niet kunnen worden gepubliceerd, enzovoort. Het is mogelijk om Alumio-monitoringmeldingen via e-mail te ontvangen.
1.11 Bewerker
De meeste integraties worden uitgevoerd in twee afzonderlijke processen, een voor binnenkomende gegevens en een voor de verwerking van de gegevens. De verwerking wordt meestal gestart met behulp van een planner, anders wordt deze gestart als onderdeel van een realtime actie vanwege de configuratie-instellingen, die vervolgens samen met het proces voor binnenkomende gegevens wordt uitgevoerd.
De processor is een configureerbaar element waarmee het platform het maximale aantal taken (wachtrij-items) kan instellen dat voor een bepaalde route moet worden verwerkt. Door een maximaal aantal taken in te stellen, kan het platform overbelasting van de ontvangende systemen op afstand voorkomen. Dit zorgt ervoor dat de belangrijkste integraties blijven werken terwijl andere integraties wachten.
1.12 Opslag van toepassingen
Alumio gebruikt Elastic Stack en MySQL om toepassingsgegevens en logboeken op te slaan. De logboeken die tijdens de uitvoering van Alumio worden geproduceerd, worden naar Elastic Stack gestuurd en daar geïndexeerd om ervoor te zorgen dat de logboeken snel toegankelijk zijn vanuit de Alumio-interface. Dankzij AOP zijn deze logboeken erg gedetailleerd en kunnen ze worden aangepast naarmate het platform evolueert.
Configuratie, omgevingsvariabelen, taken en gebruikers worden opgeslagen in MySQL. Naarmate Alumio evolueert, worden de MySQL-gegevensstructuren onderhouden met migraties, zodat bestaande projecten kunnen worden geüpgraded naar de nieuwste versie van het platform.
1.13 Verwerkingsverbinding
Inkomende verbindingen geactiveerd (webhooks)
Met webhooks kunnen systemen geautomatiseerde berichten of informatie naar Alumio sturen. Het is een krachtige manier om automatisch gegevens van de ene app naar de andere te pushen.
Transparante realtime verbindingen (HTTP-proxy)
Geplande inkomende verbindingen
Geplande/realtime uitgaande verbindingen
1.14 Authenticatie
Authenticatie met de Alumio API is beveiligd met Google OAuth. Zodra gebruikers zijn aangemaakt in Alumio, kunnen ze op verschillende manieren inloggen bij Alumo:
1. Google Microsoft-account
2. Sociaal account (zakelijke accounts worden niet ondersteund)
3. Azure AD, SAML, Okta, ADFS, OpenID, LDAP, Google Workspace (alleen voor Enterprise-licenties)
4. Een nieuw Alumio-account registreren
Voor extra beveiliging is Multi-Factor Authentication (MFA) vereist om in te loggen op de Alumio-omgeving.
Standaard wordt een klantdomein toegevoegd aan de Alumio-instantie van de klant. Gebruikers aan wie een Google-account is toegewezen, worden automatisch naar het platform gestuurd. De configuratie bepaalt of de gebruiker rechten heeft die alleen kunnen worden weergegeven of kunnen worden aangemaakt en/of bewerkt.
1.15 JSON-schema
Alumio maakt gebruik van JSON-schema's om een duidelijk gegevensformaat aan te bieden om mee te communiceren. De schema's worden gebruikt om te bepalen hoe gebruikersinvoer eruit moet zien, hoe configuratieobjecten moeten worden gedefinieerd, hoe formulieren moeten worden weergegeven, enz. Deze schema's zorgen voor een duidelijke en consistente toepassingsinterface.
1.16 Typen gegevenseenheden
Data-entiteiten voor vooraf gedefinieerde elementen worden zoveel mogelijk gestandaardiseerd. Dit betekent dat Alumio een tussenstandaard heeft voor veel soorten data-entiteiten (bijv. bestellingen, producten, kredietnota's, personen, enz.). Het gebruik van deze intermediaire standaarden vermindert de complexiteit van de koppeling met (gedeeltelijk) bekende systemen, waardoor de benodigde mutaties op de gegeven gegevens en de algehele complexiteit van het configureren van gegevensstromen worden verminderd.
1.17 Symfony - Het Alumio-ontwikkelingskader
Het Alumio-framework is ontwikkeld op Symfony, dat veel kant-en-klare en generieke functies biedt die binnen Alumio zijn geïmplementeerd. De afhankelijkheidsinjectie van Symfony verbindt alle belangrijke componenten van Alumio met elkaar.
De belangrijkste Alumio-componenten zijn in wezen de functies die kunnen worden uitgebreid met behulp van ons modulaire systeem. Dit omvat componenten zoals authenticatie, de Alumio-afhankelijkheidsinjectie, OpenAPI, logboekregistratie, inkomend, uitgaand en nog veel meer. Symfony biedt ook meer gebruikelijke componenten die geïmplementeerd kunnen worden, zoals Doctrine.
Vind het wiel niet opnieuw uit: Alumio gebruikt Symfony-bibliotheken voor generieke functies”
Over Symfony: Het is's werelds toonaangevende framework met een groot aantal ontkoppelde en herbruikbare componenten waarop enkele van de beste applicaties zijn gebouwd. De Symfony-community bestaat uit meer dan 600.000 ontwikkelaars uit meer dan 120 landen die beste praktijken, standaardisatie en interoperabiliteit van applicaties omarmen en promoten. Symfony is alles wat je van een framework mag verwachten: snelheid, flexibiliteit, herbruikbare componenten, enz.
1.18 OpenAPI/Swagger
Alumio stelt zijn functies bloot via OpenAPI, de moderne open standaard API-definitie. Elke actie wordt gedefinieerd en beschikbaar gemaakt via deze API met duidelijke schema's voor het verzenden en ophalen van gegevens. Alle elementen die in de gebruikersinterface van Alumio worden weergegeven/bewerkt, worden via deze API geparseerd. Zelfs de verwerking van routes kan via de API worden uitgevoerd, zoals het uitvoeren van een binnenkomende configuratie en het exporteren van gegevens van een bepaalde route.
Voer uw e-mailadres in om deze pagina verder te lezen
2. De beveiliging van het Alumio-platform
Ontdek de hoogwaardige beveiligingsnormen van ons integratieplatform
Ons integratieplatform verplaatst gegevens van het ene systeem naar het andere, die kritieke informatie over uw bedrijf, financiële gegevens en de persoonlijke en identificeerbare informatie (PII) van uw klanten kunnen bevatten. De veiligheid van uw gegevens moet gegarandeerd zijn.
Beveiliging zit in ons DNA en is vanaf technisch niveau ingebed in elk Alumio-proces. De beveiliging van ons product, onze infrastructuur en gegevens is onze topprioriteit. Ons beveiligings- en risicobeheerteam werkt volgens de industriestandaarden om ervoor te zorgen dat uw gegevens veilig zijn. Om ervoor te zorgen dat onze compliance en beveiliging voldoen aan de hoogste normen, houden we ons platform uitgebreid in de gaten. Ons productteam werkt voortdurend aan het verbeteren en updaten van het platform om te voldoen aan de nieuwste beveiligingsnormen, om onze klantgegevens de best mogelijke beveiliging te bieden.
2.1 Beveiliging door ontwerp
Het Alumio-integratieplatform is gebouwd met behulp van de beste technologische frameworks en veilige praktijken voor softwareontwikkeling. Alle fixes, nieuwe functies en verbeteringen worden pas vrijgegeven na verschillende strenge tests en een streng beoordelingsproces. Ons testprogramma bestaat uit geautomatiseerde codetests met betrekking tot de codekwaliteit, evenals handmatige tests waarbij elke coderegel wordt gecontroleerd en getest door ten minste twee senior ontwikkelaars.
De ingenieurs van Alumio ontwikkelen de kernapplicatie op basis van het concept 'Security-by-Design':
2.2 Naleving van beveiligingsnormen
Alumio is trots op zijn toewijding om gevoelige informatie te beschermen. Als bewijs hiervan heeft Alumio een rigoureus implementatieproces ondergaan en de naleving van ISO 27001 bereikt, een internationaal erkende norm voor managementsystemen voor informatiebeveiliging. Deze standaard bevat beste praktijken en richtlijnen voor het opzetten, implementeren, onderhouden en continu verbeteren van beheersystemen voor informatiebeveiliging om de vertrouwelijkheid, integriteit en beschikbaarheid van informatie te waarborgen.
2.3 Toegang tot het Alumio-integratieplatform
De toegang werd uitgelegd:
Op rollen gebaseerde toegangscontrole (RBAC)
Onze medewerkers hebben toegang op basis van gebruikersrollen met het concept van de minste bevoegdheden, dus er wordt geen toegang verleend tot een niveau dat in de 'rol' niet als noodzakelijk wordt beschreven.
Beveiliging voor toegang op afstand
Toegang op afstand tot de Alumio-codebase en -infrastructuur is alleen mogelijk na aanmelding bij de VPN van het bedrijf. Inloggen op de Alumio-applicatie kan worden bereikt door een inlogprocedure met tweefactorauthenticatie.
IP-whitelisting
Toegang tot de Alumio-codebase en -infrastructuur is alleen mogelijk na aanmelding bij de VPN van het bedrijf. Deze IP-adressen zijn statisch en worden door onze systeembeheerders op de witte lijst gezet.
Toegang tot ondersteuning van leveranciers
De toegang tot de leverancier is gebaseerd op de beveiligingsmaatregelen van Amazon Web Services.
Gebruikers volgen
Alle aanmeldingsacties van gebruikers worden geregistreerd, zoals inlog-ID's (gebruikersnaam, Fan-ID), datum/tijd van de laatste aanmelding, de locatie van de aanmelding (bijvoorbeeld: IP-adres), apparaat-ID (bijvoorbeeld: MAC-adres). De logboeken worden gedurende een periode van 8 weken naar een locatie met een speciale toegangsvereiste gestuurd.
Beoordelingen met regelmatige toegang
Alumio beschikt over een proces dat ervoor zorgt dat er regelmatig toegangsbeoordelingen worden gehouden. Deze zullen managers op de hoogte brengen van problemen met offboarding, zodat Alumio onze processen kan bijwerken en eventuele noodzakelijke wijzigingen kan herstellen.
Versleuteling van de harde schijf
Alumio-medewerkers zijn verplicht om versleuteling van de harde schijf toe te passen op hun lokale machines, zoals vermeld in het onboardingbeleid voor werknemers.
Firewall-configuratie
Alumio-medewerkers zijn verplicht om een firewallconfiguratie toe te passen op hun lokale machines, zoals vermeld in het onboardingbeleid voor werknemers.
Medewerkers in engineering, services, support en operations (in principe iedereen die toegang heeft tot alles wat als beveiligingsgevoelig wordt beschouwd) moeten het VPN van het bedrijf gebruiken met multifactor-authenticatie ingeschakeld, om alle inloggegevens op te slaan en te genereren die worden gebruikt om functies uit te voeren.
Technische medewerkers met toegang tot productiesystemen moeten ook minstens jaarlijks verschillende niveaus van beveiligingstraining volgen. Al onze medewerkers krijgen altijd slechts toegang tot het minimale aantal applicaties of systemen dat nodig is om hun functies uit te voeren.
2.4 Beveiliging van netwerk en infrastructuur
Verantwoordelijkheden:
Amazon Web Services is verantwoordelijk voor:
Elastic is verantwoordelijk voor Able voor:
Amazon Web Services is verantwoordelijk voor:
Alumio volgt de richtlijnen en beste praktijken van de volgende beveiligingsnormen:
2.5 Netwerk: gegevensopslag en gegevensverwerking
Alle communicatie van en naar het datacenter van Amazon Web Services en Alumio maakt gebruik van minimaal SSL 256-bit encryptie en verloopt via HTTPS, poort 443.
Standaardinstellingen:
Gegevens in rust:
Gegevens die onderweg zijn:
2.6 Opslag en verwerking van gegevens
De Alumio-integratie heeft drie manieren om gegevens op te slaan:
Loggen
Transformatiespoor
Opslag
2.7 Geautomatiseerde communicatie van gegevens
Alumio verzendt automatisch de volgende informatie naar het datacenter van Amazon Web Services:
Status online:
Mailings:
Trackinginformatie:
Updates van het integratieproces:
2.8 Door de gebruiker geïnitieerde communicatie van gegevens
Op verzoek van een geautoriseerde gebruiker communiceert het Alumio-platform het volgende aan het Alumio-datacenter:
Informatie over de uitvoering van een integratieproces, waaronder de totale uitvoeringstijd, logboekregistratie voor elke stap van het proces en foutmeldingen bij het mislukken van de uitvoering. API-gegevens of taakgerelateerde logboeken (berichten via routes = taken) worden gedurende 2 weken bewaard. Servergerelateerde logboeken worden gedurende één maand bewaard. Beide kunnen naar behoefte worden geconfigureerd op basis van de aangeschafte Alumio-editie.
Alumio biedt de mogelijkheid om de export van serverlogboeken te verzorgen. Elke geautoriseerde gebruiker kan taakgerelateerde logboeken exporteren.
Alumio off-site maakt back-ups van het volgende:
Bij het bouwen van processen voor specifieke connectoren kan informatie over het databaseschema worden verzonden om regels voor veldtoewijzing te definiëren. Er worden geen echte gegevens verzonden.
2.9 Beveiliging van datacommunicatie op locatie
Er hoeven geen inkomende firewallpoorten open te staan om het Alumio-integratieplatform met het datacenter te laten communiceren. De Alumio-integratie-interface initieert altijd de verbinding; het datacenter van Amazon Web Services pusht nooit automatisch gegevens naar het Alumio-integratieplatform (of een particulier gehoste oplossing). Wanneer de Alumio-functie een verbinding initieert, wordt een SSL-handdruk gebruikt om het datacenter te authenticeren voordat gegevens worden verzonden. Alumio maakt gebruik van het digitale certificaat dat automatisch wordt aangemaakt tijdens registratie en authenticatie.
3. De Alumio-infrastructuur
Ontdek meer over wat ons integratieplatform schaalbaar, veilig en toekomstbestendig maakt
Het Alumio-integratieplatform is een cloudgebaseerde oplossing, geleverd in een infrastructuur met één huurder in de regio van onze klant. Of het nu Europa, Azië of de VS is, Alumio zorgt voor een snelle, veilige en conforme implementatie van ons integratieplatform. Het Alumio-licentiemodel omvat hosting/applicatie (beheer) en updates. Alumio levert de netwerken, servers, opslag, besturingssysteem (OS), database en andere diensten om de door de consument gekochte Alumio-editie te hosten.
De hostinginfrastructuur is een essentieel aspect dat de schaalbaarheid van het platform beïnvloedt. Alumio levert hoogwaardige hostinginfrastructuren die klaar zijn voor wereldwijde uitrol naar het MKB en internationale ondernemingen.
3.1 Toezicht
In vergelijking met ESB's is iPaaS een cloudgebaseerd platform dat een relatief lichte architectuur gebruikt en geen installatie op locatie vereist. Hoewel zowel ESB's als de iPaaS gespecialiseerd zijn in de integratie van oudere systemen, kan de iPaaS flexibel verbinding maken met veel meer grote of kleine SaaS, cloud-apps en gegevensbronnen, zowel op locatie als in de cloud.
Hoewel ESB's een complexe berichtenarchitectuur implementeren om toepassingen met elkaar te verbinden, hanteert de iPaaS een API-first-benadering. Dit helpt de iPaaS om snellere en flexibelere integraties te bouwen, die eenvoudig kunnen worden aangepast of een datatransformatie kunnen ondergaan, zonder verlies van gegevensintegriteit of bedrijfscontinuïteit.
Bovendien moet een ESB, zoals eerder aangegeven, worden beheerd door ervaren IT-personeel dat zorgvuldig is opgeleid en opgeleid om de ESB te implementeren. De iPaaS biedt daarentegen een webinterface in de cloud waaraan zowel ontwikkelaars als burgergebruikers (CTO's, projectmanagers, junior ontwikkelaars) op afstand kunnen samenwerken om integraties te ontwikkelen, te beheren en te orkestreren.
3.2 Back-ups
Om gegevensverlies te voorkomen, is het noodzakelijk om regelmatig back-ups te maken. In tegenstelling tot veel andere providers kiest Alumio voor back-ups op basis van op bestanden gebaseerde back-uptechnologie. Dit geeft Alumio de mogelijkheid om zelfs een enkel bestand te herstellen. Het kan de hersteltijd aanzienlijk verkorten en biedt meer comfort voor ontwikkelaars die op zoek zijn naar specifieke bestanden.
Alumio maakt gebruik van R1Soft, marktleider in de markt voor hoogwaardige back-upsoftware. Standaard gaat de back-up uit van 1 herstelpunt, dat wordt aangevuld met de 'wijzigingen' vanaf het herstelmoment. Deze back-ups worden buiten je cloudomgeving gemaakt en zijn vooral bedoeld om in geval van een calamiteit snel toegang te krijgen tot een volledige kopie van je omgeving. De back-up is een volledige back-up en wordt elke nacht naar een NAS-server (Network Attached Storage) in het netwerk geschreven, maar buiten uw cloudomgeving. Deze back-up kan worden gebruikt als je server onverwachts uitvalt. Binnen de standaard serviceniveaus van Alumio wordt de back-up 1 keer per dag gemaakt en 7 dagen bewaard.
Alumio kan binnen deze periode elke dag herstellen. Daarnaast is het mogelijk om het back-upschema uit te breiden en te intensiveren, de back-ups naar uw fysieke locatie te sturen en meerdere herstelpunten te creëren.
3.3 Noodherstel
Alumio zorgt ervoor dat er bij ernstige storingen altijd herstel kan plaatsvinden. Noodherstel kost tijd. Hierdoor verschilt de tijd die gepland is per SLA-variant. In de standaard-SLA staat dat Alumio tijdens kantooruren tussen de 1 en 2 uur nodig heeft om te beginnen met het herstellen van uw gegevens. De tijd die nodig is om de applicatie in zijn geheel te herstellen, is afhankelijk van de grootte van uw toepassing (aantal GB), maar bedraagt +/- 1 uur per 10 GB aan gegevens die moeten worden hersteld. Het beheer van de Alumio-infrastructuur is ook afhankelijk van het beleid en de procedures van Amazon Disaster Recovery en Elastic Disaster Recovery.
3.4 Implementatieregio's en -strategie
Wanneer uw exemplaar van het Alumio-platform wordt geïmplementeerd, kiest het op basis van uw keuze een primaire implementatieregio voor uw bedrijf. Uw primaire implementatieregio bevat al uw Alumio-gegevens en is waar uw belangrijkste organisatieprocessen plaatsvinden. Dit betreft de hostinginfrastructuur die wordt geleverd door Amazon Web Services en Elastic Stack.
3.5 Implementatie in meerdere regio's
Alumio raadt Enterprise-bedrijven aan als een geclusterde oplossing voor een hoogwaardige infrastructuur die klaar is voor wereldwijde uitrol.
De hoogwaardige infrastructuur is een op Kubernetes gebaseerd systeem voor het automatiseren van de implementatie, schaalvergroting en beheer van gecontaineriseerde applicaties binnen meerdere regio's.
3.6 Schaalbaarheid
Wat hosting betreft, is het net zo schaalbaar als Amazon Web Services kan bieden. De functies die in Alumio zijn ontwikkeld, zijn ontworpen met het oog op schaalbaarheid. Alle logica kan echter worden vervangen door aangepaste logica om de prestaties te verbeteren en zo op te schalen.
Schaalvergroting kan worden gedaan volgens de instellingen, en deze kunnen per regio (bijvoorbeeld een land) worden ingesteld. Dit is echter waarschijnlijk niet vereist.
De schaalbaarheid brengt enige complexiteit met zich mee wat betreft de configuratie van de Alumio-setup. Anders zijn de beperkingen van de hosting de enige beperking.
4. De prestaties van Alumio
Zorgen voor bedrijfscontinuïteit en uitstekende uptime voor softwareconnectiviteit
Er zijn nog meer essentiële aspecten van het Alumio-integratieplatform die helpen om de prestaties, beveiliging en betrouwbaarheid aanzienlijk te verbeteren:
4.1 Robuust opslag- en wachtrijsysteem
Datapakketten als 'in-process data' worden tijdelijk opgeslagen in ons robuuste wachtrijsysteem, afhankelijk van het type transformatie en het gekozen Alumio-pakket, naar MySQL, Elastic, Apache spark, Google GCP of Amazon's Redshift.
Ze worden gebruikt om een grootschalige verwerking te garanderen van alle afzonderlijke pagina's met gegevens die worden verzonden. Als een systeem offline gaat, maakt de bovenstaande architectuur het mogelijk om de flowverwerkingsactiviteiten elegant te pauzeren en te hervatten zonder gegevensverlies.
4.2 Big data
Alumio is gebouwd als een krachtig integratieplatform om externe applicaties te helpen verbinden en big data te verwerken. Gegevens worden omgezet in kleinere pakketten die 'Alumio-taken' worden genoemd. Deze kunnen via onze API op een schaalbare manier door ons systeem stromen naar extern verbonden applicaties, ondersteund door ons robuuste wachtrijmechanisme.
4.3 DevOps
Alumio heeft een volledig DevOps-team dat 24/7 het Alumio-platform bewaakt. Het DevOps-team heeft mensen op meerdere locaties en elk teamlid is volledig uitgerust om op afstand of vanuit een Alumio-kantoor te werken.
4.4. Codestandaarden gebruiken
Het kernteam van Alumio heeft een softwareontwikkelingsproces gedefinieerd om ervoor te zorgen dat Alumio schaalbaar en betrouwbaar blijft en 100% beschikbaar is. De SDLC is het proces dat wordt gevolgd voor elk Alumio-softwareproject (component). Elk project bestaat uit een gedetailleerd plan waarin wordt beschreven hoe specifieke software moet worden ontwikkeld, onderhouden, vervangen en gewijzigd of verbeterd. Deze methodiek waarborgt de kwaliteit van het Alumio-integratieplatform.
Alumio ontwikkelt en verbetert zijn toepassingen door gebruik te maken van gedegen praktijken voor de levenscyclus van softwareontwikkeling (SDLC), zoals:
De bedrijfsresultaten van de Alumio-architectuur en -beveiliging
Een integratieplatform van de volgende generatie voor snelle, flexibele en toekomstbestendige integraties
Nu we de Alumio-architectuur, het beveiligingsontwerp, de schaalbare infrastructuur en de prestatievoordelen diepgaand hebben onderzocht, kunnen we samenvatten hoe dit alles samenkomt om de mogelijkheden van het Alumio-integratieplatform te versterken. Hier zijn enkele van de belangrijkste zakelijke toepassingen en voordelen die het Alumio iPaaS (Integration Platform as a Service) is ontworpen om te bieden:
Alle gegevensstromen van geïntegreerde systemen worden zichtbaar en toegankelijk gemaakt op een gebruiksvriendelijke interface, waardoor problemen met de black box worden voorkomen en eenvoudige configuraties mogelijk zijn.
Zorg ervoor dat gegevens in realtime worden gesynchroniseerd en verwerkt, transformeer gegevens flexibel en maak gebruik van datamapping en routering om duplicatie te verminderen en de nauwkeurigheid te verbeteren.
Een robuust bewakings- en logboeksysteem helpt bij het snel detecteren en melden van integratiefouten en API-conflicten, waardoor kosten en tijd worden bespaard bij het oplossen van problemen.
Verminder handmatig werk en gegevensinvoer door processen zoals productoptimalisatie, aanwerving, facturering en facturering, voorraadbeheer, marketing, klantenondersteuning en meer te automatiseren.
Verplaats en verenig gegevens van oudere systemen met ETL, migreer aangepaste velden en aangepaste objecten en implementeer vooraf geconfigureerde connectoren om oudere systemen te integreren met cloud-apps.
Organiseer alle integraties en gegevens vanuit één intuïtief dashboard. Voeg op een flexibele manier software-integraties toe of vervang ze. Ontgrendelt datasilo's en vergroot de platformbronnen naarmate je integraties groeien.
Verbind de gegevens en systemen van alle partners, leveranciers en klanten met behulp van standaard aangepaste protocollen en formaten zoals JSON, Edifact, X12, CSV, XML, cXML.
Creëer datalakes of verzamel eenvoudig alle gegevens van verschillende verbonden systemen om een hyperlerend, „digitaal en datagedreven” bedrijf te worden.
Voorkom systeemuitval en zorg voor bedrijfscontinuïteit met cachemogelijkheden, gegevensbuffering en reactiveringsprocedures voor uw integraties en IT-ecosysteem.
Centraliseer al uw gegevens en verbonden systemen op één veilige cloudruimte, krijg volledige controle over uw gegevens en voldoe aan belangrijke privacywetgeving zoals GDPR, SOC2, CCPA, FERPA, HIPAA en meer.
