RFC 9: Move to Cloud Based Spice Server

[Kelvinrr]

• Feature/Process Name: Cloud-based LTS Spice Server
• Start Date: 9/14/23
• RFC PR: N/A
• Author: Kelvin Rodriguez

Summary

New cloud-based SpiceServer is available as an open beta and is planned to replace the existing URL.

This new URL is located at https://astrogeology.usgs.gov/apis/ale/v0.9.1/spiceserver/

New URL is used via spiceinit with

spiceinit from=<cube> web=true url=https://astrogeology.usgs.gov/apis/ale/v0.9.1/spiceserver/

This RFC is a request for soliciting feedback from beta testers and proposal for a timeline for sunsetting the old service for this new cloud-based service.

Motivation

The current service located at https://services.isis.astrogeology.usgs.gov/cgi-bin/spiceinit.cgi has been running for a long time on an older version of ISIS (5.0.2). It is also located on premises and doesn't have access to much compute resources. Moving the service to AWS as a Fargate deployments affords us elasticity and a deployment process that matches other cloud services. This should also give us higher availability and support for more simultaneous spiceinit processes.

Proposed Solution / Explanation

The spice server is already deployed, this is a request is to solicit beta testers and to collect feedback on the new spice server and discuss update process for the service and a sunset strategy for the old server.

New versions would be published using the URL format: astrogeology.usgs.gov/apis/ale/<ale_version>/spiceserver/

This is a AWS solution using a Fargate service deployed via an internal CloudFormation code (AWS's infrastructure-as-code solution). It is running the latest ISIS LTS version at the time of writing (8.0.1). It uses an ALE url as the ALE dependency is the component completing much of the spiceinit work in newer versions of ISIS. This service will aim to stay backwards compatible with older versions of ISIS and updated as new ALE and LTS releases are pulled that affect ISIS camera models.

If no new issues concerning the beta server is raised for 2 months, we will move to set it to the default URL for web spiceinit. A warning when the old server is used, the old server will stay up for a year after the merging of the PR changing the URL before it is sunset. If major issues are raised after going out of beta, we would revert the change and reconsider how to move forward.

Drawbacks

This would complicate the ISIS release process and now the developer responsible for the release would also need to consider how the release affects the spiceserver and update the spiceserver ISIS version. The deployment is also more complex, as we now need to optimize costs vs performance and determine internally strategies for scaling the service as demand changes.

Alternatives

The alternative is to leave the old spiceserver as is. We would instead use efforts to create alternative services on the existing on premises machine to support newer ISIS versions.

Unresolved Questions

• It is unclear what the best auto-scaling solution is for the service. It is at a fixed scale to support thousands of requests at a time, as the service is used, we can observe what actual usages are and create an auto-scaler based on these metrics.

Future Possibilities

As ALE becomes more powerful as a service, we could replace this endpoint with a version that does not use ISIS as a compatibility layer while still being backwards compatible with older ISIS versions.

[jlaura]

It has been over a month with no comments on the RFC. I would move to accept the RFC and start the transition.

[jlaura]

[Kelvinrr]

Im going to close this. Issue open at: #5327