Scipian Customer Onboarding

[nicklathe]

This is the start to the RFC for Scipian customer onboarding.

[ncronquist]

currently no process?

[nicklathe]

Yep, typo. Should be no process.

[ncronquist]

Is this feature generic customer onboarding or is it specifically onboarding with existing terraform infrastructure?

The rest of the document seems to lean towards onboarding with existing terraform infrastructure. For teams that are looking to onboard and use the terraform controller to create their infrastructure, I imaging the process would be pretty similar, minus the terraform importing, but can teams onboard to Scipian for non-terraform or infrastructure management use cases? For example, if they just wanted to use Scipian to deploy to their existing infrastructure?

[nicklathe]

This first RFC is meant to stay relatively generic, but focus on some internal needs for customers currently using scipctl and stack who will need to onboard to Scipian. This will include importing existing Terraform state, however this is not a requirement for Scipian, just a scenario we need to support in this first MVP.

[ncronquist]

If this is not specific to onboarding with existing terraform infrastructure, then we might want to note that part is optional here.

[nicklathe]

Agreed, it could say: "...creation of namespaces, RBAC rules, and optionally importing Terraform state..."

[ncronquist]

Missing space in eachother.

[nicklathe]

✅

[ncronquist]

In the motivation section here, we've covered why we're doing this, but we probably want to specifically layout the use cases (onboarding for deployments, onboarding without existing infra, onboarding with existing infra) and enumerate the expected outcomes. It seems like the outcomes should be:

• documented process for what a Scipian admin would need to do to onboard a new team (creating namespace and rbac roles)
• new scipian functionality to import existing terraform infrastructure (this might even require it's own separate rfc to really document out what the functionality will be and how it will be supported)

[nicklathe]

The steps to onboarding are laid out below, in the guide-level explanation. Should these steps be more explicit? I believe the guide-level section is the correct section to do this in.

[ncronquist]

This section is part that I'm wondering if it should be it's own RFC.

Does this section need to include parts about how the onboarding team will need to provide their own docker container with the appropriate secret and terraform information inside in order to interact with their imported terraform?

We specified scipctl here, but will this import be limited to infrastructure created by scipctl and stack or will it be open to any terraform infrastructure? What would supporting any terraform managed infrastructure mean for mapping the current Terraform state workspace structure to the Scipian expected structure?

[nicklathe]

I think that there's a line somewhere between getting Scipian ready for a new customer to use (RBAC, importing existing infra) and actually using Scipian. The latter will depend on good documentation, the former are steps we as Scipian developers/administrators need to have in place for a new customer.

I would have to check a version, but I believe we can take any version of Terraform after they introduced workspaces and runs. This should probably be documented as part of the using scipian documentation.

It should also be noted that this RFC is to support the onboarding of only a handful of internal customers we have right now. I expect more RFC's to follow as we iterate on this feature of Scipian in the future.

[nicklathe]

Specifically, this first RFC and onboarding process will focus on customers already using stack, as that is the immediate need right now.

[ncronquist]

I'm wondering if we should break this down even further. Maybe the most basic MVP should just be the RBAC rules and Namespace creation. That would be enough to allow a team to onboard to Scipian and start creating brand new infrastructure.

I think importing existing infrastructure is a really useful feature, but I'm concerned the cost will also be much higher to implement that feature and it might be worth having the first part done to unblock anyone who wants to get going with new infra.

[ncronquist]

The impact of not doing the RBAC rules and Namespace would be that multiple teams could not securely onboard onto a single Scipian cluster.

The impact of not doing the terraform importing would be that a team with existing infrastructure would need to create brand new infrastructure with Scipian.

[nicklathe]

I agree, I could do a better job of separating RBAC/Namespace creation and importing existing Terraform state, which is definitely an optional piece.

As for cost of implementing importing state, I'm not concerned about that. I wrote a quick proof of concept this week to test it out. Having a path for customers who don't want to tear down existing infra is an important piece of this onboarding process in my opinion.

[ncronquist]

I haven't had time to really go through these two references yet, but I wanted to get them noted just to see if there's anything we should be looking into:

• EPAM Cloud Terraform As A Service
• Hashicorp Case Study - Terraform-Powered Platform-as-a-Service - video

[nicklathe]

I'll take a look at these, but Scipian is a platform that extends much beyond infrastructure management (i.e. just Terraform). I haven't dug into these resources yet, but at a high level, these seem very focused on Terraform. Our goal is to iterate towards a place where we abstract Terraform away from the customer, and eventually even stop using it all together if it makes sense.

[dragan]

@nicklathe @ncronquist and I had a conversation in the last open office hours around splitting this up into two RFC's. Once RFC geared around the on-boarding process itself, also known as registration. Then the other RFC focusing on importing existing terraform state and etc. Let us know what you think? Thanks!

[nicklathe]

I could see this being split into two RFC's. The importing existing Terraform is an optional component anyways, so I could see it being part of this or it's own.

[dragan]

This looks good @nicklathe.

I know we talked about provider, but lets keep the scope of this RFC to just on-boarding. We'll create another RFC when capturing our thoughts for connecting scipian to a cloud provider like AWS.