The Alumio
Architecture & Security
How does the Alumio integration platform work?
Alumio is a cloud-based, low-code “integration Platform as a Service” (iPaaS). Being an API-led solution, Alumio helps connect multiple systems, software, applications, and data sources - across on-premises and cloud environments.
As a low-code solution, Alumio provides a user-friendly interface for both developers and business users to create, monitor, and manage all integrations on one visual interface: without custom code and with simple click-and-configure options. Alumio also presents developer-friendly features to flexibly map and transform data, automate complex workflows, tackle edge cases, and implement (or even build) connector packages to build faster connections and custom integrations.
Centralizing all integration and data on one dedicated cloud space and providing single-tenant infrastructure, the Alumio integration platform is built to help businesses develop, govern, and orchestrate secure IT ecosystems in a scalable way. It helps synchronize data across all integrated systems, prevents data silos, and reduces duplication errors. Providing data security that’s constantly improved and updated, Alumio guarantees minimal downtime and comes equipped with reactivation procedures, data caching, and buffering capabilities, to ensure business continuity during all times.
While all of the above may be sufficient to explain Alumio from a business point of view, for technical professionals it is important to explore the architecture that Alumio is built on, in order to understand how it truly works.
What comprises the Alumio architecture and security infrastructure?
To offer an in-depth understanding of what makes the Alumio low-code integration platform a flexible, scalable, and future-proof solution, this white paper provides a technical deep dive into:
The Alumio architecture
The Alumio platform security
The Alumio infrastructure
The Alumio performance features
1. The Alumio architecture
Discover the inner workings of our future-proof integration platform
Alumio is designed to be a next-gen, API-driven enterprise iPaaS (integration Platform as a Service) that helps create, monitor, and manage future-proof integrations and IT ecosystems. To achieve and embody this vision, the architectural approach behind the Alumio platform follows the following design principles:
Dependency injection
Decoupled architecture
PHP-FIG
Hexagonal design
1.1 The integration interface
The Alumio user-friendly, web interface is developed in React and is decoupled from the backend. This enables front-end development to be mostly independent of the backend development within the platform. The user interface runs locally in the browser of the user and communicates directly to the backend via OpenAPI over HTTPS. The user interface implements the authentication offered by the backend and reads configuration, (UI) schemas, etc. from the backend.
Separating business logic of the user interface and the backend”
The Alumio user interface interprets the data sent by the backend and formats it in views, forms, validations, etc. All data exchanged between the user interface and the backend is formatted using JSON.
1.2 Dependency Injection (DI)
In traditional software development, dependency injection is used to separate concerns and the use of objects. Alumio applies the dependency injection approach to the development and/or configuration of platform-specific components (HTTP/SOAP/database/filesystem clients, subscribers, transformers, publishers, etc.). This enables configuration to be reused without causing impediments in the software.
The Alumio Dependency Injection ensures that configuration can be optimized”
Practically this means that, for example, one HTTP client can be configured for many different connections, independent of whether they are retrieving or sending data. The dependency injection helps reduce the configuration and maintenance that is required for an Alumio project.
1.3 Aspect-oriented programming (AOP)
Alumio implements AOP (Aspect-Oriented Programming), which means it separates different types of business logic from each other. Logging of application processing is automatically implemented because of AOP, meaning that each client, transformer, and other objects can have logging enabled without needing to develop a logging functionality within these objects. The AOP pointcuts are available to end-users of Alumio as well, who can then add DI plugins to the supplied pointcuts.
1.4 Configuration of integrations
Alumio has several configuratio types that are described below, namely:
Remote-system-interfacing configuration
Integration-specific configuration
General purpose configuration
1.5 Configuration to interface with remote systems
Alumio offers several generic client-configuration options to interface with remote systems.
Remote-system-interfacing configuration
Configure HTTP clients and use them to interface with HTTP endpoints using HTTP-compliant methods. Requests can be expanded to contain post-data. Authentication methods like OAuth 2.0 can be configured on an HTTP client using DI.
PDO
Configure database clients ranging from MySQL to Oracle to fetch and post database data, execute stored procedures, etc.
SOAP
Configure clients to connect to a SOAP service to fetch and post data using commonly available request methods. Alumio offers a solution to adapt to the inherent differences between SOAP services, like adding a custom authentication envelope or changes to the message structure.
Filesystems
Configure filesystems to read and write files on services like FTP, SFTP, AWS S3, HTTP, etc. Filesystem interactions are performed stateless.
1.6 Configuration to maintain integrations
Integrations between remote systems are maintained using at least one route, consisting of an incoming configuration and an outgoing configuration. Integrations can further be expanded upon using transformers, which can be applied to routes, incoming configurations, and outgoing configurations. The elements are described in detail below:
Remote-system-interfacing configuration
Incoming configuration
An incoming configuration uses remote-system-interface configuration (SOAP, REST, FTP, etc.) to produce data for the next part(s) of the route(s) they are configured for. An Incoming configuration can have transformers attached to them to manipulate the produced data before the data is passed on.
Note: at this stage, any foreign file formats (XML, CSV, EDI) can be converted to JSON, since Alumio works with the JSON schema.
It is possible to use a single incoming configuration in multiple routes, enabling a more efficient IT landscape by receiving data once and sending it to multiple remote systems afterward.
Outgoing configuration
Outgoing configurations can have transformers attached to them to manipulate the received data before the data is sent to remote systems.
Note: at this stage, the JSON data can be converted again to other file formats (XML, CSV, EDI etc.)
Transformer configuration
Transformation allows data selection/reduction, translation/mapping, encoding, calculation, sorting/ordering, merging/joining/lookup from other sources, aggregation, generation of surrogate keys, transposing/pivoting of array/object keys and values, and validation.
Transformers can also be used to filter out entire data points produced by incoming configurations, preventing unnecessary queue items.
1.7 General-purpose configuration
Integrations between remote systems are maintained using at least one route, consisting of an incoming configuration and an outgoing configuration. Integrations can further be expanded upon using transformers, which can be applied to routes, incoming configurations, and outgoing configurations. The elements are described in detail below:
Environment variables
Storage
Configure database clients ranging from MySQL to Oracle to fetch and post database data, execute stored procedures, etc.
1.8 Queue
All data that enters the platform and is prepared to be processed by an outgoing configuration becomes available within the queue. These queue items ensure configured routes are inspectable and display the task status to show what work has been done, and what has not.
There are multiple ways for a queue item to appear: scheduled incoming configurations, webhook calls to the platform, and proxying requests through the platform. Many of these are real-time or can be configured as such. Each queue item contains configuration data: where the data originated from and where it is going.
The queue items also display the data that is connected to them. Finally, the queue items display what logging has been done on the incoming side and on the outgoing side. These logs can contain errors and allow for access to debug information like HTTP errors.
1.9 Logging
Alumio logs all data and events during the processing of incoming and outgoing data. Sensitive data like API passwords are automatically filtered out of the log data and encrypted environment variables. Log data is collected and synchronized to an Elastic Stack. The log information is displayed for each task created and each subscribe/publish action in Alumio.
Triggers can be created within the Elastic Stack based on the log data. This can be used as monitoring. For example, an alert can be sent when a number of several tasks fail within a single hour.
1.10 Monitoring
Configure triggers to update maintainers about the health of integrations, whether tasks (queue items) are getting stuck, failing to publish, and so forth. It’s possible to get Alumio monitoring notifications via email.
1.11 Processor
Most integrations run in two separate processes, one for incoming data and another to process the data. The processing is usually started using a scheduler, otherwise, it is started as part of a real-time action due to configuration settings, which is then executed together with the process for incoming data.
The processor is a configurable element that enables the platform to set the maximum number of tasks (queue items) to be processed for a given route. Setting a maximum number of tasks enables the platform to prevent overloading the receiving remote systems. This ensures that the most important integrations keep working while other integrations wait.
1.12 Application storage
Alumio uses Elastic Stack and MySQL to store application data and logs. The logs produced during the execution of Alumio are sent to Elastic Stack and indexed there to ensure logs are quickly accessible from the Alumio interface. Thanks to AOP these logs are very granular and can be adjusted as the platform evolves.
Configuration, environment variables, tasks, and users are stored in MySQL. As Alumio evolves, the MySQL data structures are maintained with migrations to enable existing projects to be upgraded to the latest version of the platform.
1.13 Processing connection
Triggered incoming connections (Webhooks)
Webhooks allow systems to send automated messages or information to Alumio. It’s a powerful way to automatically push data from one app to another.
Transparent real-time connections (HTTP Proxy)
Scheduled incoming connections
Scheduled/Real-time outgoing connections
1.14 Authentication
Authentication with the Alumio API is secured with Google OAuth. Once users have been created in Alumio they can log into Alumo using multiple methods:
1. Google account Microsoft
2. Social account (Business accounts are not supported)
3. Azure AD, SAML, Okta, ADFS, OpenID, LDAP, Google Workspace (Enterprise licenses only)
4. Registering a new Alumio account
For extra security, Multi-Factor Authentication (MFA) is required to log in to the Alumio environment.
By default, a customer domain is added to the Alumio instance of the customer. Users with a Google account assigned will be automatically provisioned to the platform. Configuration determines if the user has view-only or create and/or edit rights.
1.15 JSON schema
Alumio uses JSON schemas to offer a clear data format to communicate with. The schemas are used to determine what user input should look like, how configuration objects should be defined, how forms should be rendered, etc. These schemas make for a clear and consistent application interface.
1.16 Data entity types
Data entities for predefined elements are standardized as much as possible. This means that Alumio has an intermediate standard for many data entity types (e.g., orders, products, credit memos, people, etc.). Having these intermediate standards reduces the complexity of interfacing with (partially) known systems, reducing the mutations needed on the given data and the overall complexity of configuring data flows.
1.17 Symfony - The Alumio Development Framework
The Alumio framework is developed on Symfony, which offers many out-of-the-box and generic features that have been implemented within Alumio. Symfony’s dependency injection connects all major components of Alumio together.
Major Alumio components are essentially the features that can be expanded upon using our modular system. This includes components like authentication, the Alumio dependency injection, OpenAPI, logging, incoming, outgoing, and many more. Symfony also offers more common components to be implemented like Doctrine.
Don’t re-invent the wheel: Alumio uses Symfony libraries for generic features”
About Symfony: It’s the world's leading framework with a large set of decoupled and reusable components upon which some of the best applications are built. The Symfony Community consists of over 600,000 developers from more than 120 countries that are embracing and promoting best practices, standardization, and interoperability of applications. Symfony is everything that you would come to expect from a framework: speed, flexibility, reusable components, etc.
1.18 OpenAPI/Swagger
Alumio exposes its features through OpenAPI, the modern open standard API definition. Every action is defined and made available through this API with clear schemas for sending and retrieving data. All elements displayed/edited in the Alumio user interface are parsed through this API. Even processing of routes can be performed via the API, like executing an incoming configuration and exporting data from a given route.
Please enter your email to continue reading this page
2. The Alumio platform security
Uncover the high-level security standards of our integration platform
Our integration platform moves data from one system to another, which could contain critical information about your company, finance-related data, and the personal and identifiable information (PII) of your customers. The security of your data must be assured.
Security is in our DNA and embedded from a technical level into every Alumio process. The security of our product, infrastructure, and data is our top priority. Our security and risk management team works as per industry standards to ensure that your data is safe. To ensure our compliance and security meet the highest standards we extensively monitor our platform. Our product team constantly works on improving and updating the platform to meet the newest security standards, to give our customer data the best possible security.
2.1 Security by design
The Alumio integration platform is built using best-of-breed technology frameworks and secure software development practices. All fixes, new features, and enhancements are only released after several rigorous tests and a strict review process. Our testing program consists of automated code testing regarding code quality, as well as manual testing where every code line is checked and tested by at least two senior developers.
Alumio engineers develop the core application based on the concept of ‘Security-by-Design':
2.2 Compliance with security standards
Alumio prides itself on its commitment to safeguarding sensitive information. As a testament to this, Alumio has undergone a rigorous implementation process and achieved compliance with ISO 27001, an internationally recognized standard for information security management systems. This standard sets out best practices and guidelines for establishing, implementing, maintaining, and continuously improving information security management systems to ensure the confidentiality, integrity, and availability of information.
2.3 Access to the Alumio integration platform
The access explained:
Role-Based Access Control (RBAC)
Our employees have access based on user roles with the concept of least privilege, so no access is granted to a level that is not described as needed in the ‘role’.
Remote access security
Remote access to the Alumio codebase and infrastructure is only possible after logging in to the company’s VPN. Logging in to the Alumio application can be achieved by a two-factor authentication login procedure.
IP Whitelisting
Access to the Alumio codebase and infrastructure is only possible after logging in to the company’s VPN. These IP addresses are static and are whitelisted by our system administrators.
Vendor support access
The vendor access is based on Amazon Web Services Security measures.
User tracking
All user login actions are logged, like login IDs (username Fan ID), date/time of last login, location of login (e.g.: IP address), device identifier (eg: MAC address). The logs are pushed to a location with a special access requirement for a period of 8 weeks.
Regular access reviews
Alumio has a process in place that ensures regular access reviews will be held. These will notify managers of issues with offboarding, enabling Alumio to update our processes and remediate any changes necessary.
Hard drive encryption
Alumio employees are obligated to apply hard drive encryption on their local machines, as stated in the onboarding policies for employees.
Firewall configuration
Alumio employees are obligated to apply firewall configuration on their local machines, as stated in the onboarding policies for employees.
Employees in engineering, services, support, and operations (basically anyone with access to anything deemed security sensitive) are required to use the company VPN with multifactor authentication enabled, to store and generate all credentials used to perform job functions.
Engineering employees with access to production systems are also required to undergo varying levels of security training at least annually. All our employees are always only granted access to the minimal number of applications or systems needed to perform their job functions.
2.4 Security of network & infrastructure
Responsibilities:
Amazon Web Services is responsible for:
Elastic is responsible forAble for:
Amazon Web Services is responsible for:
Alumio follows the guidelines and best practices of the following security standards:
2.5 Network: data storage & data handling
All communication from and to the data center of Amazon Web Services and Alumio uses a minimum SSL 256-bit encryption and occurs via HTTPS, port 443.
Default settings:
Data at rest:
Data in transit:
2.6 Data storage and processing
The Alumio integration has three ways of storing data:
Logging
Transformation trail
Storage
2.7 Automated communication of data
Alumio automatically transmits the following information to the Amazon Web Services data center:
Online Status:
Mailings:
Tracking Information:
Integration Process Updates:
2.8 User-initiated communications of data
If requested by an authorized user, the Alumio platform communicates the following to the Alumio data center:
Information about the execution of an integration process, including total execution time, logging for each step of the process, and execution-failure error messages. API data or task-related logs (messages via routes = tasks) are retained for 2 weeks. Server-related logs are retained for one month. Both are configurable as needed based on the Alumio edition purchased.
Alumio offers the ability to provide the export of server logs. Any authorized user is able to export task-related logs.
Alumio off-site makes backups of the following:
When building processes for specific connectors, database schema information can be transmitted to define field mapping rules. No actual data is transmitted.
2.9 On-premises data communication security
No inbound firewall ports need to be open for the Alumio integration platform to communicate with the data center. The Alumio integration interface always initiates the connection; the data center of Amazon Web Services never pushes data automatically to the Alumio integration platform (or privately hosted solution). When the Alumio feature initiates a connection, it uses an SSL handshake to authenticate the data center before transmitting data. Alumio uses the digital certificate automatically created during registration and authentication.
3. The Alumio Infrastructure
Explore more of what makes our integration platform scalable, secure, and future-proof
The Alumio integration platform is a cloud-based solution, delivered in a single tenant infrastructure in the region of our customer. Whether it’s Europe, Asia, or the USA, Alumio provides fast, secure, and compliant deployment of our integration platform. The Alumio license model includes hosting/application (management) and updates. Alumio provides the networks, servers, storage, operating system (OS), database, and other services to host the consumer's purchased Alumio edition.
Hosting infrastructure is a vital aspect that influences the scalability of the platform. Alumio delivers high-performance hosting infrastructures that are ready for worldwide rollout to SMBs and international Enterprises.
3.1 Monitoring
In comparison to ESBs, the iPaaS is a cloud-based platform that uses comparatively lightweight architecture and doesn’t need any on-premises installation. While both ESBs and the iPaaS specialize in integrating legacy systems, the iPaaS can flexibly connect with many more big or small SaaS, cloud apps, and data sources, across both on-premises and cloud environments.
While ESBs implement a complex messaging architecture to connect applications, the iPaaS adopts an API-first approach. This helps the iPaaS to build faster and more flexible integrations, which can be easily modified or undergo data transformation, without loss of data integrity or business continuity.
Furthermore, as indicated before, an ESB needs to be operated by experienced IT personnel that are carefully educated and trained in implementing it. In contrast, the iPaaS provides a cloud-based, web interface that both developers and citizen users (CTOs, project managers, junior developers) can remotely collaborate on to develop, govern, and orchestrate integrations.
3.2 Backups
To prevent data loss, it is necessary to make regular backups. Unlike many providers, Alumio opts for backups based on file-based backup technology. This gives Alumio the ability to restore even a single file. It can significantly reduce the restore time and offers more comfort to developers looking for specific files.
Alumio uses R1Soft, which is the market leader in the high-end backup software market. By default, the backup assumes 1 restore point, which is supplemented with the 'changes' from the restore moment. These backups are made outside your cloud environment and are primarily intended to quickly access a complete copy of your environment in the event of a calamity. The backup is a full backup and will be written every night to a NAS (Network Attached Storage) server in the network, but outside your cloud environment. This backup can be used if your server unexpectedly breaks down. Within the Alumio standard service levels, the backup is made 1 time per day and stored for 7 days.
Alumio can restore every day within this period. Additionally, it is possible to extend and intensify the backup schedule, send the backups to your physical location, and create multiple restore points.
3.3 Disaster recovery
Alumio ensures that recovery can always take place in the event of serious malfunctions. Disaster recovery takes time. As a result, the time that is planned differs per SLA variant. The default SLA states that Alumio requires between 1 - 2 hours during office hours to start recovering your data. The time required to recover the application in its entirety depends on the size of your application (number of GB) but is +/- 1 hour per 10 GB of data to be recovered. Alumio infrastructure management also relies on the Amazon Disaster Recovery and Elastic Disaster Recovery policy and procedures. iness needs.
3.4 Deployment regions and strategy
When your instance of the Alumio platform is deployed, it chooses a primary deployment region for your business based on your choice. Your primary deployment region holds all of your Alumio data and is where your main organization processes take place. This is in regard to the hosting infrastructure delivered upon Amazon Web Services and Elastic Stack.
3.5 Multi-region deployment
Alumio recommends Enterprise businesses as a clustered solution for a high-performance infrastructure that is ready for worldwide rollout.
The high-performance infrastructure is a Kubernetes-based system for automating deployment, scaling, and management of containerized applications within multiple regions.
3.6 Scalability
Hosting-wise, it is as scalable as Amazon Web Services can offer. The features developed in Alumio are designed with scalability in mind. However, all the logic can be replaced with custom logic to improve performance and thus scale up.
Scaling can be done as per setup, and those can be set up per region (eg. a country). However, this is most likely not required.
Having scalability brings some complexity regarding the configuration of the Alumio setup. Otherwise, the only restriction is the limitations of hosting.
4. The Alumio Performance
Ensuring business continuity and great uptime for software connectivity
There are several more essential aspects of the Alumio integration platform that helps greatly improve its performance, security, and reliability:
4.1 Robust storage and queuing system
Data packages as 'in-process data' are temporarily stored in our robust queuing system, depending on the type of transformation and chosen Alumio package, into MySQL, Elastic, Apache spark, Google GCP or Amazon's Redshift.
They are used to guarantee processing at scale for all the individual pages of data in transit. If any system goes offline, the architecture above allows for elegantly pausing and resuming flow-processing activities without loss of data.
4.2 Big Data
Alumio is built as a high-performance integration platform to help external applications to be connected and to handle big data. Data is transformed into smaller packages called 'Alumio tasks'. These can flow through our system in a scalable manner into externally connected applications via our API, supported by our robust queuing mechanism.
4.3 DevOps
Alumio has a full DevOps team monitoring the Alumio platform 24/7. The DevOps team has people in multiple locations and each team member is fully equipped to work remotely or from an Alumio office.
4.4. Using code standards
The Alumio core team has defined a software development process to ensure that Alumio maintains scalability, reliability, and is 100% available. The SDLC is the process that is followed for each Alumio software (component) project. Each project consists of a detailed plan describing how to develop, maintain, replace, and alter or enhance specific software. This methodology ensures the quality of the Alumio integration platform.
Alumio develops and improves its applications by using sound software-development lifecycle (SDLC) practices such as:
The business results of the Alumio architecture & security
A next-gen integration platform for fast, flexible, and future-proof integrations
Now that we’ve explored in-depth the Alumio architecture, security design, scalable infrastructure, and performance advantages, let’s summarize how this all comes together to power what the Alumio integration platform provides. Here are some of the key business use cases and benefits that the Alumio iPaaS (integration Platform as a Service) is designed to provide:
All data flows of integrated systems are made visible and accessible on a user-friendly interface, preventing black box issues and enabling easy configurations.
Ensure data is synchronized and processed in real-time, flexibly transform data, and utilize data mapping and routing to reduce duplication and improve accuracy.
A robust monitoring and logging system helps swiftly detect and notify integration errors and API conflicts, saving cost and time on troubleshooting.
Reduce manual work and data entry by automating processes like product optimization, hiring, billing & invoicing, inventory management, marketing, customer support, and more.
Move and unify data from legacy systems with ETL, migrate custom fields and custom objects, and implement pre-configured connectors to integrate legacy systems with cloud apps.
Organize all integrations and data from one intuitive dashboard. Add or replace software integrations in an agile way. Unlock data silos and increase platform resources as your integrations grow.
Connect the data and systems of all partners, suppliers, and customers using standard custom protocols and formats such as JSON, Edifact, X12, CSV, XML, cXML.
Create data lakes or simply gather all data from different connected systems to become a hyper-learning, “digital-first and data-driven” company.
Avoid system downtime and ensure business continuity with caching capabilities, data buffering, and reactivation procedures for your integrations and IT ecosystem.
Centralize all your data and connected systems on one secure, cloud space, get full data control, and comply with key privacy legislations like GDPR, SOC2, CCPA, FERPA, HIPAA, and more.
