Some customers ask whether it is possible to host ClinSpark themselves using their servers (‘on prem’) or in their own AWS accounts ('hybrid', ‘customer cloud’). This is not something we are able to support.

Key reasons for not offering customer hosting

1. It results in a poorer support experience

2. It complicates onboarding, resulting in a poorer experience

3. It complicates upgrades, resulting in a poorer experience

4. Offerings of this type may be limited to certain capabilities and features

5. On prem offerings are expected to have fewer / slower release cycles

More detail

Offering ClinSpark on customer clouds has a number of impacts.

1. Our ability to provide support is impeded, tickets are harder to resolve because we have limited access

2. Initial environment setup and upgrades are complicated by working with customer’s toolsets and internal IT departments – activities that might take a few hours in our AWS account often end up taking weeks/months of effort because of the additional teams involved

3. Our engineers and support staff may be required to be trained and ‘signed-off’ on customer policies and SOPs prior to gaining access, which significantly adds to administrative overheads

In addition

1. We don’t currently have, and would need to create documentation, aimed at administrators setting up environments in on prem or customer cloud environments.

2. Our preference is to use Infrastructure as Code (IaC) to manage all environments. We would need to prepare documentation for multiple different IaC solutions to support whichever toolset the customer requires.

3. Access into customer managed environments for support purposes is complex. We are missing key tools to effectively support these environments - publishing system logs, exporting certain configurations etc.

4. Customer managed environments also need to be suitably monitored. We have our own tools for monitoring. Customers are likely to have their own, different toolsets. We would need to prepare documentation or other artifacts to aid configuration of such tooling.

5. Any discussion of monitoring also extends to security management. We have and continue to invest in tooling and controls to ensure good security practices. We won’t necessarily have the features/documentation etc. to allow customers to implement their specific toolset.

6. The tooling that we have and plan to build for configuration management, usage tracking, billing etc. all rely on our ability to connect directly to instances that we’re managing. Supporting customer installed and managed environments would require us to build more complex solutions into the platform - these don’t exist today.

7. Adding new API gateways, and supporting ‘big data’ platforms etc. becomes increasingly complex as we’d need to address all the extras needed to allow customers to utilise such features within their environments.