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.

The same platform 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.

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

The hub and the sites#

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

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 three or five servers for high availability, at Weik.io or in your own cloud.

A site is wherever integrations run: a server in your network, a virtual machine in your cloud account or a cloud agent beside the hub. Each site has a small message server and an agent, and the agent starts one Java process for each running integration. A site opens no inbound port. It 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 three or five for high availability, and it publishes port 443. Three sites connect to it: a factory site inside a customer network, a site in the customer's Azure account and cloud agents in Weik.io Cloud. Each site has a leaf node and an agent that 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 site accepts an inbound connection.

Show full size

One installation is built for hundreds of integrations and tens of agents. Concepts explains each part in a few sentences.

Which part do I need#

Start from what you want to do. Each row leads to the first docs page of the part that does it.

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