What is Weik.io

What Weik.io manages#

Integrations in Weik.io are Apache Camel routes in YAML, XML or Java, and they can use Camel’s components and kamelets. You keep them in Git and promote each version from devtest to production with the weikio CLI or the admin UI. Every integration has its own logs, metrics and traces. Weik.io is open source under the Apache License 2.0 and runs on your own servers, in your cloud or in Weik.io Cloud.

Weik.io manages four kinds of work, and each one is a document or a folder you keep in Git:

• Camel integrations: an integration is a folder of Camel files with its routes, beans, kamelets, properties and any jars it needs. weikio apply publishes it as an immutable version, and weikio deploy runs that version in an environment.
• Managed file transfer: a transfer moves files on a schedule between any two places rclone can reach, such as a supplier’s SFTP server and an Azure storage account. You write a short YAML document with a schedule, a source, a destination and an operation, and every file it moves is logged.
• API management: the gateway puts an HTTP API in front of an integration or any other system, with subscriptions, API keys, OpenID Connect tokens, client certificates and rate limits. Each environment answers on its own hostnames, and the platform obtains and renews their certificates.
• Events: integrations publish events into channels and other integrations read them, now or later, on any agent. Failed deliveries go to dead letters, and a channel with a type delivers to Slack, S3, SFTP, Kafka, JMS, HTTP or any other Camel sink. Every stored event carries CloudEvents 1.0 attributes.

All four come with observability: every Camel process sends its logs, metrics and traces through OpenTelemetry, you can forward all of it to Azure Monitor, Splunk or any OTLP receiver, and the platform raises problems for failing integrations and APIs.

The hub and the agents#

A Weik.io installation has one hub and any number of agents.

The hub runs the backend, with the HTTP API, the admin UI and the builder, the API gateway, the message server that stores every record of the platform, and the log, metric and trace stores. It runs on one server for a small installation and on as many as you need for high availability, whether on your own servers, in your cloud or in Weik.io Cloud. The servers of one hub can be in different data centres.

An agent runs your integrations wherever you install it: on a server in your network, on a virtual machine in your cloud account or as a cloud agent beside the hub. Each agent has a small message server beside it, and it starts one Java process for each running integration. Its host opens no inbound port. The agent makes two outbound connections to the hub on port 443, one for the platform’s own traffic and events and one for logs, metrics and traces.

The hub runs a message server, the backend, the gateway and the log, metric and trace stores on one server, or on as many as you need for high availability, and it publishes port 443. Agents in three places connect to it: at a factory inside a customer network, in the customer's Azure account and as cloud agents in Weik.io Cloud. Each agent has a leaf node beside it and starts one Java process per running integration, and it opens two outbound connections to the hub on port 443, wss for the leaf node and https for telemetry. No agent accepts an inbound connection.

Show full size

One installation runs hundreds of integrations and as many agents as you install. Concepts explains each part in a few sentences.

Which part do I need#

Each row starts from a task and links the first docs page of the part that handles it.

Every part shares the same projects, environments, roles and audit log, and a team that starts with file transfers can add APIs and events to the same installation.