Implementation Strategies and Recommendations

There are several potential deployment and implementation strategies that may be used with a customer depending on their deployment type, size, and complexity. Each deployment strategy involves different internal owners and timeline expectations.

Deployment Strategies

Deployment Strategy

Description

Owners

Cloud Deployment
  • Preferred deployment strategy
  • Once it is determined that the customer qualifies for Cloud, the CE or Sales will submit a Managed Instance Request to the Cloud Team to kick off the process
Cloud

CE

One-Click Deployment
  • Preferred on-prem deployment method
  • The production environment for the customer is created by the CE prior to transitioning ownership of the account to the TAM
  • The production environment could be initiated as part of a trial or POC, or it could be created following contract closure
CE
Jointly Deployed Implementation
  • If Cloud and One-Click are not options for the customer, the CE will Initiate an IE Request
  • Upon reviewing the request, the implementation team qualifies the customer for a jointly deployed instance and kicks off the process with the CE and Sales
  • This method is primarily used for on-prem Kubernetes deployments
CE

IE

TPM

One-Click Into Jointly Deployed Instance
  • This method is only used by customers that would like a production environment stood up quickly, their initial user set can be supported by a One-Click Deployment, but a full Kubernetes instance will be needed for expansion to the full set of users
  • The CE will stand up an initial One-Click production environment and transition the customer to the TAM for continued support
  • As the deployment reaches scalability or technical limits, the TAM engages the implementation team to coordinate a post-live, jointly deployed Kubernetes instance
CE

TAM

IE

TPM

One-Click Into Cloud Deployment
  • This method is only used by customers that would like a production environment stood up quickly and there are particular Cloud blockers that need to be resolved prior to the customer using a Managed Instance
  • The CE will stand up an initial One-Click production environment and transition the customer to the TAM for continued support
  • Once the Cloud Team completes the development required for the customer to use a Cloud deployment, the TAM engages the Cloud team to coordinate a transition to a Managed Instance
CE

TAM

Cloud

Deployment Recommendations

Customers should be directed towards using a managed instance on Sourcegraph Cloud. If this is not an option, they should then be evaluated for use of an on-prem one-click deployment. If this too is not an option, customers should deploy on-prem with Kubernetes. Only is very specific situations should customers be directed towards a Docker Compose deployment.

Deployment Decision Tree

Deployment Decision Tree

Link to Excalidraw

Description of Decision Tree Questions

Does the account qualify for a Cloud Instance?

  • Do Sourcegraph’s certification meet all requirements? - While Sourcegraph’s current certifications and compliances (i.e. SOC2) should be sufficient for a large number of customers, others may have hard certification requirements that Sourcegraph does not currently support (such as FEDRAMP, ISO 27001, and others). If you are uncertain of current certifications, reach out to the Cloud team.

  • Is Sourcegraph’s admin access acceptable? - Sourcegraph admins will need to access the customer’s Managed Instance. This may be a blocking issue for a customer. Currently, Sourcegraph admins authorize via Okta with 2FA. We don’t currently support MFA. This question is used to ensure that this access and authorization is acceptable for the customer.

  • Will Sourcegraph’s audit logging capabilities be acceptable - Some customers may have specific audit log or eDiscovery hard requirements. If a customer has a requirement and it isn’t immediately obvious whether or not it can be supported with a managed instance, reach out to the Cloud team to investigate.

  • Do no additional organizational Cloud blockers exist? - Certain organizations may have hard cloud blockers that are not captured by other questions. If you identify these blockers, begin by collaborating with the Cloud team. In situations where we cannot support the requirement (or development to support the requirement won’t be completed quickly enough for the customer), that customer of course cannot use Cloud in the immediate term.

  • NOTE - With any of these Cloud-related blocking questions, if you run into a hard requirement that isn’t currently supported for Managed Instances, reach out to the Cloud team. For many situations, it may be possible that the Cloud team can complete development to remove that blocker and help to qualify the customer for Cloud.

Is there a requirement for a currently unsupported hosting locale or code host that the organization is not willing to wait for Cloud development?

  • Certain organizations will have hosting locale requirements that aren’t currently supported. It typically takes the Cloud team about 1 month to stand up a new hosting locale. If this timeline works for the customer, great! Otherwise, they will need to move on to other deployment options.

  • Likewise, Cloud can currently support the same code host types as listed for self-hosted instances (Link to current code host support.). That being said, the code host must be publicly available (i.e. have a public IP and accept connections from all source addresses or have the ability to be configured to accept connections from a public IP). Without being publicly available, a Managed Instance currently cannot connect to a code host and is therefore not a viable option for that customer.

Does the account have more than 75GB of hosted code?

  • This question is used to determine whether or not the customer will use the Business or Enterprise Cloud pricing model. Any customer with more than 75GB or hosted code will be on the Enterprise pricing model.

Are any of your code hosts non-standard or non-cloud?

  • All code hosts must be standard, cloud-based offerings (GitHub Cloud, GitLab Cloud, BitBucket Cloud) in order for the customer to be on the Business pricing model. If any of the customer’s cloud hosts are non-standard or non-cloud, the customer will need to be on the Enterprise pricing model.

Does the account require priority SLAs, dedicated support, additional executors, or Private Instance Access?

  • A customer wanting any of these available options will need to be on the Enterprise Cloud model. For the executors specifically, Business customers are restricted to 2 exectors whereas Enterprise customers will have up to 4.

Does the organization have more than 20k users or 200k repos?

  • As of right now, AMI deployments can only scale up to these numbers of users and repositories. If an organization is above these numbers, they will need to deploy with Kubernetes.

Is there an organizational requirement for a cluster deployment?

  • Some organizations require enterprise products to be deployed on clusters. If this is the case, the customer should be directed to a Kubernetes deployment.

Will a Sourcegraph AMI instance work for the account?

  • Can the organization deploy Sourcegraph on AWS? - As of right now, Sourcegraph one-click AMIs need to be deployed on AWS. If the organization needs to deploy on any other cloud provider, they cannot use the one-click deployment option.

  • Has the organization had no historical technical or scaling issues when deploying on a single machine? - As a single-node option, customers may run into technical or scaling issues that may prevent them from using the one-click deployment option. When this happens, it should be recommended that the customer transitions to a Kubernetes deployment.

  • Do no other technical or organizational restrictions exist that prevent the use of a Sourcegraph AMI for the instance - This is a placeholder to capture any other technical or organizational blockers that disallow a customer from using the one-click deployment option. If you and the customer encounter issues or limitations of this deployment option, reach out the the Delivery team to discuss options and determine whether or not Kubernetes should be recommended.

Does the account qualify for a jointly deployed instance?

  • Has the account been evaluated by the implementation team for implementation services? - Prior to qualifying an account for implementation services, the CE and AE must coordinate with the implementation team to discuss the opportunity, need, and strategy.

  • Does the account take priority on the implementation backlog based on size, ARR, and TAM? - The implementation team will likely not be able to handle every Kubernetes deployment that comes down the pipeline. In order to prioritize the accounts on the jointly deployed backlog, the implementation team and leadership will primarily review the organizations size, the opportunities ARR, and the total addressable market of the account.

  • Are there contextual limitations requiring the account to user Sourcegraph implementation services? - Any additional contextual situations should be taken into account when determining the account priority and need for a jointly deployed instance. These include questions such as whether or not the account has a lack of deployment expertise, they have particularly unique set of deployment requirements, or they have a strategic purpose.

Is there an organizational requirement to use their own base AMI or does the organization use a cloud provider other than AWS?

  • If a customer uses a cloud provider other than AWS and does not need a full Kubernetes deployment, Docker Compose should continue to be recommended.
  • If a customer uses AWS but indicates that they require the use of their own base AMI (therefore requiring the use of Docker Compose), this should be questioned and discouraged. While this is still possible, Docker Compose is no longer recommended, and ideally any customer for whom Cloud and one-click doesn’t work should be deploying with Kubernetes.