-
Epic
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
RDS Upgrades
-
Future Sustainability
-
False
-
-
False
-
Unset
-
In Progress
-
59% To Do, 0% In Progress, 41% Done
-
-
-
Review the CRCPLAN parent feature for additional context, including the feature overview, goals, user stories and use cases, acceptance criteria, designs, dependencies, risks, assumptions, pending questions and documentation callouts.
Summary and goal
This epic is to migrate three existing services—{}pdf-generator{}, *chrome-services, and **quickstarts—to an optimized **Graviton* instance on AWS. The primary goal is to achieve significant cost savings and performance improvements by leveraging the ARM-based Graviton architecture. The migration will involve re-building Docker images with multi-architecture support and deploying them to the new infrastructure. This initiative aligns with our broader strategy to optimize cloud spending and improve application efficiency.
Acceptance Criteria
These conditions must be met for the epic to be considered complete. This provides a detailed definition of scope and the expected outcomes, written from a user's point of view.
- The {}pdf-generator{} service is successfully running on a Graviton instance.
- The {}chrome-services{} service is successfully running on a Graviton instance.
- The {}quickstarts{} service is successfully running on a Graviton instance.
- Rollback procedures are documented in case of any issues with the new instances.
Checklist
| Checklist Item | Required | Notes or Comments |
|---|---|---|
| Workstream or external team dependencies? | N | |
| ADR Required? | N | |
| Testing plans | N | |
| Known dependencies? | N |
Open Questions
* {}Q:{} What is the specific target for cost savings? {}A:{} Initial analysis suggests a {}20-30% reduction{} is achievable. We'll set the AC at a minimum of 20%.Capture any open questions and resolutions related to the epic goal or acceptance criteria. Add any additional details, questions or decisions that need to be made or addressed.
- {}Q:{} Are there any known compatibility issues with the ARM architecture for our current software dependencies? {}A:{} Initial research indicates the primary dependencies (Java, Node.js) have excellent ARM support. We need to verify any native libraries used by the services.
- {}Q:{} How will we handle the cutover to the new instances? {}A:{} We'll use a {}canary deployment{} or {}blue/green deployment{} strategy to minimize risk and allow for easy rollback.