Algorithmia is designed to be deployed in environments with the strictest of security requirements, and the infrastructure of each installation operates in complete isolation from other installations. Every Algorithmia instance (cluster) is provisioned with its own isolated database; resources (i.e., algorithms, data, and accounts) created on one cluster are not shared with other clusters.
Scenarios
Isolation between Algorithmia clusters is an intentional architectural decision. However, there are several use cases for provisioning multiple clusters and needing to share resources between them, or needing to share and move resource between accounts within a cluster. Some possible scenarios are listed below.
Development and production environments
Just like you might have development, staging, and production environments for an application that you deploy, you might choose to have a separate environment where you develop and test algorithm code before promoting it to a production environment that serves business and/or customer-facing applications.
You might do this to comply with security, auditability, and/or data sensitivity requirements; for example, you might want to grant access to your development environment to multiple teams across your company to maximize the number of users leveraging Algorithmia, while keeping access to your production environment tightly gated, perhaps limited to only a handful of specific individuals.
High availability (HA) and fault tolerance
In order to meet objectives for application availability and business continuity, you might choose to deploy redundant clusters of Algorithmia into multiple cloud provider regions. The resources on these individual clusters must then be kept in sync to support a failover scenario.
Development and production + HA
If you require both of the scenarios described above, you might provision more than two Algorithmia clusters. For example, you might have a cluster for development and two production clusters deployed into multiple public cloud regions. As noted above, resources must then be synced between clusters.
Changing Git repository hosts
When you create an algorithm, you must choose whether the source code will be hosted internally on the Algorithmia platform or using one of our supported source code management (SCM) providers. If you create an algorithm and choose to host the source code using the internal SCM system but you later decide to use another SCM provider, or if you need to change providers for any reason, you’ll need to migrate the resources to an algorithm backed by a repository on the new provider.
Troubleshooting
When you’re troubleshooting algorithm runtime issues and need to modify source code for debugging, it’s often preferable to make a separate copy for debugging. This way, you can make changes without worrying about modifying the original algorithm and needing to revert changes at the end, and you can run the algorithm for testing without worrying about the usage being attributed to the original account. Rather than attempting to debug in place, the ability to efficiently clone algorithms, either within or between clusters, can be useful in such scenarios.
Using organizations
It’s worth noting that by using orgs within your cluster, you can achieve some of the isolation and access control restrictions provided by having multiple clusters. For more information on how to use orgs to manage access to resources, see Organizations.
Next steps
Scenarios such as these require repeatable, automated processes for regularly migrating resources between clusters and for promoting production-ready code from development environments. The Migration Scripts page explores some of the considerations involved in migrating resources, and provides guidance for leveraging Algorithmia’s API and source code management system to support and manage repeatable workflows.