Deployment Planning Guide
Last updated
Last updated
The below context diagram provides a high-level overview of:
All of Cinchy's available components and how they integrate with other applications within a customers organization.
The deployment architecture of the Cinchy platform
Interaction points involving end users
Note that certain components and configurations are optional and dependent upon the usage pattern of the platform, these will be called out in the table below the diagram which provides a description of each component.
# | Component | Description | Technology Stack | Dependencies |
1 | Cinchy Web Application | This is the primary application for Cinchy, providing both the UI for end users as well as the REST APIs that serve application integration needs. The back-end holds the engine that powers Cinchy's data / metadata management functionality. | ASP.NET MVC 5 |
|
2 | Cinchy IdP | This is an OpenID Connect / OAuth 2.0 based Identity Provider that comes with Cinchy for authenticating users. Cinchy supports user & group management directly on the platform, but can also connect into an existing IdP available in the organization if it can issue SAML tokens. Optionally, Active Directory groups may be integrated into the platform. When SSO is turned on, this component is responsible for federating authentication to the customer's SAML enabled IdP. This centralized IdP issues tokens to all integrated applications including the Cinchy web app as well as any components accessing the REST based APIs. | .Net Core 2.1 |
|
3 | Cinchy Database | All data managed on Cinchy is stored in a MS SQL Server database. This is the persistence layer | MS SQL Server Database |
|
4 | Cinchy CLI | This is Cinchy's Command Line Interface that offers utilities to get data in and out of Cinchy. One of these utilities is a tool to sync data from a source into a table in Cinchy. This is able to operate on large datasets by leveraging an in-built partitioning capability and performs a reconciliation to determine differences before applying changes. Another commonly used utility is the data export, which allows customers to invoke a query against the Cinchy platform and dump the results to a file for distribution to other systems requiring batch data feeds. | .NET Core 2.0 |
|
5 | ADO.NET Driver | For .NET applications Cinchy provides an ADO.NET driver that can be used to connect into the platform and perform CRUD operations on data. | .NET Standard 2.0 |
|
6 | Javascript SDK | Cinchy's Javascript SDK for front-end developers looking to create an application that can integrate with the Cinchy platform to act as it's middle-tier and backend. | Javascript JQuery | |
7 | Angular SDK | Cinchy's Angular SDK for front-end developers looking to create an application that can integrate with the Cinchy platform to act as it's middle-tier and backend. | Angular 5 |
The Cinchy application components are all designed to be agnostic to whether a customer chooses to use Virtual Servers, Physical Machines, or a Cloud environment. For the web components the underlying platform dependency is Windows Servers, these can be provisioned on any of the 3 platforms, including Cloud when using IaaS. The same is true for the database server.
Minimum Web Server Hardware Recommendations
2 x 2 GHz Processor
8 GB RAM
4 GB Hard Disk storage available
Minimum Database Server Hardware Recommendations
4 x 2 GHz Processor
12 GB RAM
Hard disk storage dependent upon use case. Note that Cinchy maintains historical versions of data and performs soft deletes which will add to the overall storage requirements.
Clustering considerations are applicable to both the Web and Database tiers in the Cinchy deployment architecture.
The web tier can be clustered by introducing a load balancer and scaling web server instances horizontally. Each node within Cinchy uses an in-memory cache of metadata information, and expiration of cached elements is triggered upon data changes that would impact that metadata. Data changes processed by one node wouldn't immediately be known to other nodes without establishing connectivity between them. For this reason the nodes must be able to communicate over either http or https through an IP based binding on the IIS server that allows cache expiration messages to be broadcast. The port used for this communication is different from the standard port that is used by the application when a domain name is involved. Often for customers this means that a firewall port must be opened on these servers.
The database tier relies on standard MS SQL Server failover clustering capabilities.
The web application is responsible for all interactions with Cinchy be it through the UI or connectivity from an application. It interprets/routes incoming requests, handles serialization/deserialization of data, data validation, enforcement of access controls, and the query engine to transform Cinchy queries into the physical representation for the database. The memory footprint for the application is fairly low as caching is limited to metadata, but the CPU utilization grows with request volume and complexity (e.g. insert / update operations are more complex than select operations). As the user population grows or request volume increases from batch processes / upstream system API calls there may be a need to add nodes.
The database tier relies on a persistence platform that scales vertically. As the user population grows and request volume increases from batch processes / upstream system API calls the system may require additional CPU / Memory. Starting off in an environment that allows flexibility (e.g. a VM) would be advised until the real world load can be profiled and a configuration established. On the storage side, Cinchy maintains historical versions of records when changes are made and performs soft deletes of data which will add to the storage requirements. The volume of updates occurring to records should be considered when estimating the storage size.
Outside of log files there is no other data generated & stored on the web servers by the application, which means backups are generally centered around the database. Since the underlying persistence platform is a MS SQL Server, this relies on standard procedures for this platform.
