Deployment Planning Overview and Checklist

This page is your first stop when considering a deployment of Cinchy v5.

1. Overview

There are various things to consider before deploying Cinchy v5.

The pages in this Deployment Planning section will guide you through the considerations you should think about and the prerequisites that you should implement 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 we recommend a Kubernetes deployment. It also walks you through the important decision of selecting a database to run your deployment on, as well as 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 concerning your cluster configuration.

  • IIS Deployment Architecture: This page provides Infrastructure and Platform component overviews for IIS (VM) deployments.

• Deployment Prerequisites: This page details important prerequisites for deploying Cinchy v5.

2. Deployment Planning Checklist

We have provided the following checklist for you to use when planning for your Cinchy v5 deployment. Each item is linked to the appropriate documentation page to provide more insight and clarity.

• Will you run on Kubernetes or a VM?

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, in the event that multiple instances are stood up 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 are not 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:

• Which database will you use?
• Define your sizing.
• Define your cluster configuration.
• 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?

• Define your object storage requirements.

  • Create an S3 compatible bucket.
• Create your SSL Certs (With the option to use Self-Signed).
• Define your Secrets Management, if desired.
• Define whether you will use Cinchy's Docker Images or your own.

  • If using Cinchy’s, pull the images.

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 either 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

• Access the deployment repositories and copy them into your own repo (Github or similar).

If you will be running on IIS, please review the following checklist:

• Ensure that you have an instance of SQL Server 2017+
• Ensure that you have a Windows Server 2012+ machine with IIS 7.5+ installed
• For v5.4+:

  • Install .net core Hosting bundle Version 6.0

    • Specifically, install: ASP.NET Core/.NET Core Runtime & Hosting Bundle

• For v5.0-5.3:

  • Install .net core Hosting bundle Version 3.1 - found here​

    • Specifically, install: ASP.NET Core/.NET Core: Runtime & Hosting Bundle​
• Ensure that you review the minimum web server hardware recommendations
• Ensure that you review the minimum database server hardware recommendations
• Define your application storage requirements.
• Ensure you have access to the release binary.