The build and deployment scope of work

The Full Build and deployment of a business application, services and managed services on GCP involve:

• The build of the cloud infrastructure including:
  • The Landing Zone transversal for multiple applications
  • The cloud infrastructure specific to each application
• The deployment of the business application software on the infrastructure
• The build of the operations layer including:
  • The selection and configuration of tooling used for operations, including GCP tooling services
  • The configuration and deployment of exporters of observability metrics, logs, agents, backup and other operational parameters necessary to the operations
• The integration into OBS administration backend including:
  • Provision and connectivity for administrative access to the cloud platform
  • Integration of GCP monitoring alerting towards OBS Level 1 / 2 & 3 supervision tooling
  • Integration of troubleshooting procedures into operations Knowledge Database
  • Configuration and provision of OBS ITSM tooling for Incident Tickets and Change Requests handling.
  • Configuration and provision of OBS portal for access to contractual documents and billing.

At the end of the build, all pre-requisites shall be available and ready to meet the criteria for the run (ref chapter 7.1.3 Criteria for the run of a managed cloud native service component).

 

Depending on the project status and on customer’s request, the remaining Scope of Work for the build to meet the criteria for the run may be the full build or a partial build. The scope of work of the build is discussed during the pre-sale phase.

 

The customer may retain or delegate part of the Build responsibilities to OBS:

• The Build of the Cloud Infrastructure layer (IaC)
• The Build of the Operations layer
• The integration into OBS administration backend tooling

The Build effort estimation is custom and depends on the Scope of Work of the project. Upon customer’s request, OBS can provide Cloud Expert resources and Service Reliability Engineer prestation to join and strengthen customer’s development team.

 

While the build effort and its estimate can be custom, for sake of simplification and budgetary anticipation by the customer, OBS has pre-defined 4 models of build for a managed cloud native resource:

• Model “No build”: no build requested from OBS – resource is not managed.
• Model “Backend build”: OBS is only requested to integrate in its administration backend. The customer takes care of all other aspects of the build
• Model “Operations build”: OBS is requested the build of the operations layer and the integration in its administration backend. The customer takes care of the build of the infrastructure and software deployment
• Model “Full build”: OBS is requested to build the infrastructure with IaC, to build the operations layer and to integrate in its administration backend. The customer takes care of the Software.

As far as the Scope of Work is concerned, building the first cloud native resource of a given type usually involves a larger effort than building a subsequent resource of same type, as the Infrastructure as Code might be mostly reused. This possibility depends on the cloud native resource considered.

 

As result, each build model distinguishes:

• The effort and price of build for the first resource of a given type
• The effort and price of build for the subsequent resource of the same type

For the Scope of Work differ from the models, a custom scope of work shall be estimated.

• Project management and coordination during the build phase

During the build phase, a Scope of Work is defined for Project Management and Service Implementation Coordination to ensure efficient execution of the project between the customer and OBS.

Optionally, the project may require Cloud Expert Services and Service Reliability Engineering.

Those services are charged based on time and material.

• Cloud Expert Services for migration

The project may require migration of the workloads to GCP. OBS will propose Cloud Expert Services for migration to GCP based on the specific migration Scope of Work in addition to the Managed Services.

• Criteria for assessing the model of build for a resource

When the build effort is uncertain from pre-sales documentation, an assessment is proposed at the beginning of the build project by OBS Cloud Expert Services. During this assessment, the following tasks are performed:

• Collection of the architecture diagrams with dependencies, HLD, LLD of applications, and infrastructure to be managed and any other useful information.
• Check of the inventory of resources to be deployed and managed.
• Review for each of the dependence the remaining work requested to OBS for completing the build to reach readiness for the run. Review the criteria for a resource build to qualify to a given model of build. Hence determining for each resource which build model applies: No build, Backend build, Operations Build or Full Build.
• Confirmation that the pre-required tools for operations are in place (or alternatively agreeing on a specific scope of work for different tooling if agreeable).
• Establishing requested responsibilities defined between the customer and OBS (RACI) for build and for the run.
• Identifying potential limitations on the managed application service if criteria are not met.

 

• Criteria for qualifying as “backend build” model SoW for a resource:

The “backend build” scope of work model for a resource is used for:

• a resource/service in scope for managed service for which the infrastructure is already built and deployed by the customer leveraging Infrastructure-as-Code.
• And, for which GCP tooling is fully configured and operational prior to transition under customer’s responsibility. The tooling used shall be:
  • Cloud Monitoring & Cloud logging for supervision with proper alerts defined
  • GCBDR properly configured and functional
  • VM Manager & Patch Management configured for VM patching
  • Remedial and troubleshooting procedures on known incident are defined and provided
  • Recovery procedures to be used are defined and provided by the customer
• And, customer provides documentation i.e. schema, HLD and DAT/LLD, architecture explaining how availability & HA, monitoring, security policies and access control, backup, disaster recovery, baseline security, SLA are achieved.

The build effort provided by OBS in the “backend build” includes integrating the alarms from GCP Monitoring to the OBS backend systems, capturing the procedural guides provided by the customer into the OBS knowledge repository of operations, and operations readiness. It includes

as well getting the administrative backend, the OBS ITSM, the portal and billing readiness for operations.

• Criteria for qualifying as “operations build” model SoW for a resource:

The “operations build” scope of work model for a resource is used for:

• a resource/service in scope for managed service for which the infrastructure is already built and deployed by the customer leveraging Infrastructure-as-Code.
• And, customer provides documentation i.e. schema, HLD and DAT/LLD, architecture explaining how availability & HA, monitoring, backup, disaster recovery, baseline security, SLA are achieved.
• And, agreement reached between the customer and OBS to use the GCP and OBS backend tooling.

The build effort provided by OBS in the “operations build” includes that of the “backend build” plus the configuration and deployment of GCP tooling thanks to Infrastructure as Code and of OBS backend i.e.:

• Cloud Monitoring & Cloud logging for supervision with alerts
• GCBDR configuration and deployment
• Update Manager configuration for VM patching
• Anti-virus configuration for VM
• Use of standard remedial and troubleshooting procedures on known incident for the cloud native service.
• Use of standard recovery procedures for the cloud native service.

For further details on the operations per service, please refer to Chapter 9: detailed description per cloud service.

• Criteria for qualifying as “full build” model SoW for a resource:

The “full build” scope of work model for a resource is used for:

• a resource/service in scope for managed service not yet built and deployed.
• And, customer provides documentation i.e. schema, HLD and DAT/LLD, architecture explaining how availability & HA, monitoring, backup, disaster recovery, baseline security, SLA are achieved.
• And, agreement reached between the customer and OBS to use the GCP and OBS backend tooling.

The build effort provided by OBS in the “full build” includes that of the “backend build” plus that of the “operational build” plus

• The configuration of the Landing Zone and the infrastructure of the resource leveraging Infrastructure as Code.

For further details on the operations per service, please refer to Chapter 9: detailed description per cloud service.

For further details of Infrastructure as Code for full build model, please refer to chapter Infrastructure as code methodology.

• Mitigation in case of pre-requisites or criteria not met:

The assessment may reveal that criteria are not met for qualifying to a given build model. Then 3 options are possible:

• the scope of work shall be revisited with a more appropriate build model. This may affect the duration of the project and efforts.
• the customer may remedy to the missing criteria. This may affect the duration of the project and project management and coordination efforts.
• the customer and OBS may agree to live with some limitations in the management capabilities and responsibilities due to the missing criteria.

Would the project be delayed and would resources effort be overspent by OBS as result of pre-requisites and criteria under customer’s responsibility not being met, then OBS would be entitled to charge the overspent effort based on time and material.