Description
As Console evolves, there was an initial request to add the full provisioning state machine and orchestration flow directly into Console.
Original request:
device-management-toolkit/console#838
That proposal would allow Console to support provisioning workflows, including end-to-end TLS activation, without relying on RPS. However, this would significantly expand the responsibilities of Console and move the architecture toward a more monolithic design.
Mike's recommendation was to leverage the existing provisioning and orchestration capabilities already available in RPS rather than duplicating the state machine in Console.
This approach also aligns better with the long-term architectural direction of maintaining clear separation of responsibilities across services. As part of the future roadmap, MPS may be split into two services: an API service and an APF service. This would allow the API service to be updated more frequently while minimizing changes to the APF service, reducing the likelihood of CIRA connection disruptions caused by service upgrades. Leveraging the existing RPS orchestration model is more consistent with this disaggregated architecture direction than moving additional orchestration responsibilities into Console.
There have also been several optimization requests from the C2C/VFS team to improve the robustness, reliability, and performance of the existing RPS provisioning workflows. These enhancements are already planned or under consideration within RPS and would further strengthen the provisioning experience for customers using RPS-based deployments.
Given these ongoing investments in RPS, it is worth evaluating whether extending and validating the existing RPS orchestration model provides a better return than duplicating similar functionality within Console. This consideration is in addition to the architectural and deployment discussions outlined above. The Console orchestration proposal should be placed on hold until we evaluate and validate the Console + RPS deployment model.
Problem Statement
Today, Console and RPS are not validated as a supported cloud deployment architecture.
Customers who already use RPS for provisioning should be able to deploy Console alongside RPS without duplicating orchestration logic inside Console.
There are also overlapping areas that need clarification, particularly profile creation and ownership, since both RPS and Console expose similar profile management APIs.
Recommendation
Support a cloud deployment model where Console works with the existing RPS infrastructure.
RPS should remain responsible for provisioning orchestration and activation workflows, while Console focuses on device management, user workflows, and user experience.
Expected Behavior
Customers should be able to deploy Console and RPS together as a supported architecture.
The responsibilities between Console and RPS should be clearly defined, documented, and validated.
Acceptance Criteria
Validation
Description
As Console evolves, there was an initial request to add the full provisioning state machine and orchestration flow directly into Console.
Original request:
device-management-toolkit/console#838
That proposal would allow Console to support provisioning workflows, including end-to-end TLS activation, without relying on RPS. However, this would significantly expand the responsibilities of Console and move the architecture toward a more monolithic design.
Mike's recommendation was to leverage the existing provisioning and orchestration capabilities already available in RPS rather than duplicating the state machine in Console.
This approach also aligns better with the long-term architectural direction of maintaining clear separation of responsibilities across services. As part of the future roadmap, MPS may be split into two services: an API service and an APF service. This would allow the API service to be updated more frequently while minimizing changes to the APF service, reducing the likelihood of CIRA connection disruptions caused by service upgrades. Leveraging the existing RPS orchestration model is more consistent with this disaggregated architecture direction than moving additional orchestration responsibilities into Console.
There have also been several optimization requests from the C2C/VFS team to improve the robustness, reliability, and performance of the existing RPS provisioning workflows. These enhancements are already planned or under consideration within RPS and would further strengthen the provisioning experience for customers using RPS-based deployments.
Given these ongoing investments in RPS, it is worth evaluating whether extending and validating the existing RPS orchestration model provides a better return than duplicating similar functionality within Console. This consideration is in addition to the architectural and deployment discussions outlined above. The Console orchestration proposal should be placed on hold until we evaluate and validate the Console + RPS deployment model.
Problem Statement
Today, Console and RPS are not validated as a supported cloud deployment architecture.
Customers who already use RPS for provisioning should be able to deploy Console alongside RPS without duplicating orchestration logic inside Console.
There are also overlapping areas that need clarification, particularly profile creation and ownership, since both RPS and Console expose similar profile management APIs.
Recommendation
Support a cloud deployment model where Console works with the existing RPS infrastructure.
RPS should remain responsible for provisioning orchestration and activation workflows, while Console focuses on device management, user workflows, and user experience.
Expected Behavior
Customers should be able to deploy Console and RPS together as a supported architecture.
The responsibilities between Console and RPS should be clearly defined, documented, and validated.
Acceptance Criteria
Validation