SaaS Operational Model
Table of Contents
- Overview
- Operational Responsibility
- Infrastructure Operations
- Space Operations
- Fabric and Studio Version Lifecycle
- Deployment Operations
- Monitoring and Diagnostics
- Operational Escalation
- Related Documentation
Overview
K2cloud SaaS separates responsibility for operating the K2cloud platform and runtime infrastructure from responsibility for operating the customer's K2view implementation.
At a high level:
K2view
↓
Operates K2cloud and the runtime infrastructure
Customer
↓
Manages the K2view implementation through K2cloud
K2view operates the Kubernetes-based platform on which customer Spaces run. Customers manage their Projects, Spaces, application configuration, deployments, access, and runtime validation through K2cloud and the applications within their Spaces.
Operational Responsibility
The primary responsibility boundary is:
For the broader K2cloud responsibility model, see Shared Responsibility Model.
Infrastructure Operations
K2view is responsible for operating the infrastructure underlying K2cloud SaaS.
Customers therefore do not directly manage:
- Kubernetes clusters,
- Kubernetes nodes,
- cluster lifecycle,
- ingress infrastructure,
- or the infrastructure supporting K2cloud SaaS observability.
This removes the need for customer operations teams to manage the Kubernetes platform directly.
It does not remove the customer's responsibility for its K2view implementation and application operations.
Space Operations
Authorized customers manage the lifecycle of their Spaces through K2cloud Orchestrator.
Depending on the Space type, these operations can include:
- creating Spaces,
- reviewing Space status,
- pausing and resuming Studio Spaces,
- restarting Fabric Spaces,
- deploying environments,
- deploying Project content,
- reviewing Space Details,
- upgrading or rolling back Fabric and Studio versions,
- and deleting Spaces.
K2view operates the infrastructure required to execute these operations. The customer determines when the corresponding application-level operation should be performed.
Fabric and Studio Version Lifecycle
K2view manages publication and distribution of Fabric and Studio images for K2cloud SaaS.
Available Fabric Images are published to Projects and can be selected for the applicable Space Profiles.
The operational lifecycle is:
K2view publishes the Fabric Image
↓
Project Manager selects the approved version
↓
Eligible Space identifies the available upgrade
↓
Authorized Space Owner initiates the upgrade
↓
Customer validates the application
This preserves the SaaS responsibility boundary:
- K2view manages image publication and distribution.
- Customers control when their Spaces move to an available version and validate the resulting application behavior.
For detailed procedures, see Upgrading Fabric and Studio with K2cloud.
Deployment Operations
Customers control deployment of their K2view implementation.
The built-in deployment workflow is:
Approved Git Tag
↓
Deploy Environment
↓
Activate Environment
↓
Deploy Project
↓
Validate Runtime
K2view operates the platform on which these deployment operations execute. The customer remains responsible for determining:
- what version is approved,
- when it should be deployed,
- where it should be deployed,
- and whether the resulting application operates correctly.
See K2cloud Deployments and Lifecycle.
Monitoring and Diagnostics
K2cloud SaaS provides integrated monitoring and logging capabilities for customer Spaces.
Customers can use the available K2cloud capabilities to review runtime activity and logs.
Space Details separately provides Kubernetes-level diagnostics such as:
- pod state,
- pod details,
- pod logs,
- and Kubernetes events.
Customers can use these diagnostics without directly operating the underlying Kubernetes infrastructure.
K2view remains responsible for the SaaS platform and infrastructure. Customers remain responsible for understanding and validating the behavior of their K2view implementation.
See Monitoring and Logs and View Space Details.
Operational Escalation
When an issue occurs, the first objective is to determine whether it concerns:
- the customer's K2view implementation,
- application configuration or deployment,
- identity and authorization,
- or the K2cloud SaaS platform and infrastructure.
Customers use the available K2cloud application, monitoring, logging, and diagnostic capabilities to investigate their implementation.
Issues requiring investigation of the underlying SaaS platform or infrastructure are escalated to K2view.
This boundary allows customers to operate their K2view applications while K2view retains responsibility for operating the underlying K2cloud SaaS platform.
Related Documentation
SaaS Operational Model
Table of Contents
- Overview
- Operational Responsibility
- Infrastructure Operations
- Space Operations
- Fabric and Studio Version Lifecycle
- Deployment Operations
- Monitoring and Diagnostics
- Operational Escalation
- Related Documentation
Overview
K2cloud SaaS separates responsibility for operating the K2cloud platform and runtime infrastructure from responsibility for operating the customer's K2view implementation.
At a high level:
K2view
↓
Operates K2cloud and the runtime infrastructure
Customer
↓
Manages the K2view implementation through K2cloud
K2view operates the Kubernetes-based platform on which customer Spaces run. Customers manage their Projects, Spaces, application configuration, deployments, access, and runtime validation through K2cloud and the applications within their Spaces.
Operational Responsibility
The primary responsibility boundary is:
For the broader K2cloud responsibility model, see Shared Responsibility Model.
Infrastructure Operations
K2view is responsible for operating the infrastructure underlying K2cloud SaaS.
Customers therefore do not directly manage:
- Kubernetes clusters,
- Kubernetes nodes,
- cluster lifecycle,
- ingress infrastructure,
- or the infrastructure supporting K2cloud SaaS observability.
This removes the need for customer operations teams to manage the Kubernetes platform directly.
It does not remove the customer's responsibility for its K2view implementation and application operations.
Space Operations
Authorized customers manage the lifecycle of their Spaces through K2cloud Orchestrator.
Depending on the Space type, these operations can include:
- creating Spaces,
- reviewing Space status,
- pausing and resuming Studio Spaces,
- restarting Fabric Spaces,
- deploying environments,
- deploying Project content,
- reviewing Space Details,
- upgrading or rolling back Fabric and Studio versions,
- and deleting Spaces.
K2view operates the infrastructure required to execute these operations. The customer determines when the corresponding application-level operation should be performed.
Fabric and Studio Version Lifecycle
K2view manages publication and distribution of Fabric and Studio images for K2cloud SaaS.
Available Fabric Images are published to Projects and can be selected for the applicable Space Profiles.
The operational lifecycle is:
K2view publishes the Fabric Image
↓
Project Manager selects the approved version
↓
Eligible Space identifies the available upgrade
↓
Authorized Space Owner initiates the upgrade
↓
Customer validates the application
This preserves the SaaS responsibility boundary:
- K2view manages image publication and distribution.
- Customers control when their Spaces move to an available version and validate the resulting application behavior.
For detailed procedures, see Upgrading Fabric and Studio with K2cloud.
Deployment Operations
Customers control deployment of their K2view implementation.
The built-in deployment workflow is:
Approved Git Tag
↓
Deploy Environment
↓
Activate Environment
↓
Deploy Project
↓
Validate Runtime
K2view operates the platform on which these deployment operations execute. The customer remains responsible for determining:
- what version is approved,
- when it should be deployed,
- where it should be deployed,
- and whether the resulting application operates correctly.
See K2cloud Deployments and Lifecycle.
Monitoring and Diagnostics
K2cloud SaaS provides integrated monitoring and logging capabilities for customer Spaces.
Customers can use the available K2cloud capabilities to review runtime activity and logs.
Space Details separately provides Kubernetes-level diagnostics such as:
- pod state,
- pod details,
- pod logs,
- and Kubernetes events.
Customers can use these diagnostics without directly operating the underlying Kubernetes infrastructure.
K2view remains responsible for the SaaS platform and infrastructure. Customers remain responsible for understanding and validating the behavior of their K2view implementation.
See Monitoring and Logs and View Space Details.
Operational Escalation
When an issue occurs, the first objective is to determine whether it concerns:
- the customer's K2view implementation,
- application configuration or deployment,
- identity and authorization,
- or the K2cloud SaaS platform and infrastructure.
Customers use the available K2cloud application, monitoring, logging, and diagnostic capabilities to investigate their implementation.
Issues requiring investigation of the underlying SaaS platform or infrastructure are escalated to K2view.
This boundary allows customers to operate their K2view applications while K2view retains responsibility for operating the underlying K2cloud SaaS platform.
Related Documentation
