Architecture Overview
Here we'll discuss the general architecture of the Jetic Platform and go into detail regarding the different components involved. For a more generic discussion of the platform, consider reading our Overview of the Jetic Platform.
The Jetic Platform is designed to streamline the process of creating, managing, and deploying software integrations in Kubernetes. This is achieved with our platforms backend application and with the help of some core services:
- A secured message broker
- The Camel Bridge: Our Kubernetes Operator
- A shared Kubernetes cluster: Used for new users and platform evaluation
The Jetic Platform Backend#
Our platforms backend application does a lot of heavy lifting to make the Jetic Platform possible. When it comes to the architecture of the platform, there are 2 core responsibilities from the backend.
Code Generation#
Our backend is responsible for taking integrations created in our Camel Studio and generating deployment ready Camel DSL code. The code is also bundled with resources you create and configure in the studio. This includes database and salesforce connections, custom beans, and more.
In addition to generating the code for your deployment, the backend also generates Yaml files that will be applied to your cluster. These Yaml files range from Kubernetes Deployments to Ingress resources, depending on the type of integration getting deployed.
Cluster Monitoring#
The backend application is configured to continually monitor various aspects of your deployed integrations. It listens for health metrics, deployment updates and will even stream both build and execution logs automatically. There is a constant monitoring of connectivity between the platform and your cluster in the form of a "heartbeat". This hearbeat ensures that all the data in your management dashboards is up to date in near real time.
Message Broker#
Our secured message broker acts as an intermediary between the Jetic Platform and a Camel Bridge. Since the Camel Bridge is installed within a Kubernetes cluster, the message broker is the only link of communication between our platform and any Kubernetes cluster.
Our message broker consists of a series of queues and topics for managing all the integrations deployed within your cluster. These include queues for deployments, cluster health checks, topics for log streaming, and more.
important
Each queue and topic is uniquely named and only subscribable from your cluster. This means that you can only authenticate to a predefined set of channels within the broker
Main Benefit#
Arguably the greatest benefit of using a message broker for communication between our platform and a users Kubernetes cluster is that you do not need to configure anything in order to establish a connection. This is because as long as you have the credentials to authenticate against the broker, you'll receive messages from our platform.
important
There is no need to open any ports, whitelist IPs, modify firewalls, or anything of the sort. Simply authenticate against our broker and you can communicate with our platform from within any cluster in any network!
Camel Bridge#
Our Camel Bridge is a small applicaition that follows the Kubernetes Operator design pattern and needs to be installed in your Kubernetes cluster. Once installed it will open a connection to our message broker and subscribe to the appropriate queues and topics unique to your cluster.
note
The bridge must be installed with credentials provided by our platform in order to connect to our message broker.
When your bridge receives messages from out platform via the message broker, it will need to utilize the Kubernetes API in order to interact with your cluster. The bridge is given just enough permission so that it can properly manage integrations in your cluster and nothing more.
tip
During Camel Bridge installation, you'll be able to see the Role & Permission Yaml that is being applied to your cluster for the bridge.
Since the bridge lives in your cluster, it will deploy integrations in the same network as all of your internal services and resources like databases, APIs, Git repositories, and more. This means you have a seamless deployment of integrations that can connect automatically connect directly to all of your resources!
Shared Cluster#
The Jetic Platform provides a multi-tentant, shared Kuberetes cluster for users that do not yet have their own cluster, or who simply want to evaluate the platform. This shared cluster allows multiple users to experiment with our platform and deploy integrations to a real cluster without having to provide their own.
The shared cluster is divided into namespaces and there is one for each user. This ensures that the integrations and resources of each user remain separate from one another. Despite sharing a cluster, a user can only view their own resources since their requests will be authenticated at the namespace level within our message broker.
The shared cluster is configured with temporary machines provided by the Google Cloud Platform. This means that at any moment the pods that your integrations are deployed in may be terminated.
warning
Because your underlying pods can be removed by Google at any moment do not deploy any critical or production integrations in our shared cluster. This cluster is only meant for evaluation so if you need a more permanent deployment solution please consider connecting your own cluster to our platform.
tip
For guides on connecting a cluster or even setting one up, please check out our Installation Guide documentation.