Services/SyncCutoverOptions

Prayer

Pros:

• No cost
• No engineering work on client or server
• Might actually be fine

Cons:

• Will eventually break, depending on how long replacement takes
• May not actually be fine

Need to study growth curves (iops and disk space) to better understand feasibility of this option.

Permutation: shutting of new registrations would almost ensure the viability of maintenance

Order and rack up new machines in a colo (phx or one of our others) in order to scale to 1.1 needs.

Pros:

• What the system was designed to do.
• No changes needed to client or server.
• Scales up on demand.

Cons:

• Additional hardware ask for machines that may not be needed long-term
• Hardware lead time
• Operational overhead in racking and installing

Do the work needed to get 1.1 storage running on AWS.

Pros:

• Infintely scalable on demand.
• No client changes needed.

Cons:

• Some throwaway server/deployment work
• Technical hurdle of replicating LDAP into the AWS cluster
• Legal concerns may require auditing data in the LDAP to make sure it was properly purged before we started using it

Port 1.1 to AWS and registration to mySQL

Pros:

• Kills a bunch of LDAP-related technical debt
• Dodges any need to audit LDAP
• No client changes
• Scalable on demand

Cons:

• Large amount of throwaway server deployment work, including disruption to the current infrastructure
• Will need extensive QA for something short-term

Cut over to sync 2.0 on AWS. Leave 1.1 in place

Pros:

• Solves a lot of technical debt
• Solves colo issue
• Gets the one flag day out of the way

Cons:

• Identity not viable
• Lots of client work
• Flag day for upgrade to 2.0 and no backwards compat

This is not technically an option. It's the end goal, but it's clear there's going to be some changes needed before we get here

Cut over to sync 2.0 on AWS. Tokenserver supports basic auth.

Pros:

• No dependency on identity
• Nice half-way solution to where we want to be
• 2.0 is fully scalable on AWS
• No need to replicate into AWS

Cons:

• Client work
• Server work on tokenserver (can also do the mysql registration cutover here)
• Full flag day (1.1 and 2.0 can't cross operate). Will still need another flag day on identity changeover

Cut over to sync 2.0 on AWS. Tokenserver supports basic auth. Phoenix colo dual supports 1.1 and 2.0.

Pros:

• No dependency on identity
• AWS scalability/no replication
• Not disruptive to current users

Cons:

• Client work.
• Partial flag day for new users (can't also use 1.1) and still doesn't avoid full flag day on identity switch.
• Can't implement storage format upgrades for clients using both 1.1 and 2.0 (so probably a bunch of client code to dance around that)