Comment on page
Plan your deployment
This page is your first stop when considering a deployment of Cinchy v5.
This section will guide you through the considerations and the prerequisites before deploying version 5 of the Cinchy platform.
The pages in this section include:
- Deployment Architecture Overview: This page explores your two high-level options for deploying Cinchy, on Kubernetes or on VM, and why Cinchy recommends a Kubernetes deployment. It also walks you through selecting a database to run your deployment on and some sizing considerations.
- Kubernetes Deployment Architecture: This page provides Infrastructure (for both Azure and AWS), Cluster, and Platform component overviews for Kubernetes deployments. It also guides you through considerations about your cluster configuration.
Use the following checklist when planning for your Cinchy v5 deployment. Each item links to the appropriate documentation page.
The main differences between a Kubernetes based deployment and an IIS deployment are:
- Kubernetes offers the ability to elastically scale.
- IIS limits certain components to running single instances.
- As all caching is in memory in an IIS deployment, if multiple instances are online for redundancy there is point to point communication between them (HTTP requests on the server IPs) required to maintain the cache.
- Performance is better on Kubernetes because of Kafka/Redis
- Prometheus/Grafana and OpenSearch aren't available in an IIS deployment
- The Maintenance CLI runs as a CronJob in Kubernetes while this needs to be orchestrated using a scheduler for an IIS deployment.
- Upgrades are simpler with the container images on Kubernetes.
If you will be running on Kubernetes, please review the following checklist:
- How many clusters will you need?
- Will you be sharing from an existing cluster?
- Will you be running multiple environments on a single cluster?
- Will you be using Cinchy's recommended cluster components or your own?
Starting in Cinchy v5.4, you will have the option between Alpine or Debian based image tags for the listener, worker, and connections. Using Debian tags will allow a Kubernetes deployment to be able to connect to a DB2 data source, and that option should be selected if you plan on leveraging a DB2 data sync.
- When installing or upgrading your platform, you can use the following Docker image tags for the listener, worker, and connections:
- "5.x.x" - Alpine
- "5.x.x-debian" - Debian
If you will be running on IIS, please review the following checklist: