Documentation
Services
Keep-The-Lights-On

Keep-The-Lights-On

Explanation

KTLO is managed service offering meant for workloads that are slowly winding down or are no longer being actively developed, and have stable or decreasing usage patterns.

KTLO effectively replaces the existing managed service level of DevOps-as-a-Service with a purely reactive cooperation while maintaining core operational aspects of the platform management. This ensures that the platform reliability remains guaranteed at a lower cost..

What’s included

The KTLO offer includes everything to give you peace of mind on core Platform operations and Platform reliability:

  • Fully managed Platform: Platform updates and improvements, monitoring, operations
  • First line, reactive break/fix support included on all managed components and applications using them. Delivered over Slack and Github to named Support contacts.

Optional/additional:

  • 24/7 response for monitoring and P1 escalations
  • Changes like configuration changes, components (de-)provisioning, etc, advice and guidance (T&M or SoW-based)

Transition and cooperation

Transitioning to KTLO

Transitioning from regular DevOps-as-a-Service to KTLO. This needs to be executed during the DevOps-as-a-Service period (full service):

  1. All ongoing projects, GH issues, etc are cleaned up and closed, especially those that will not progress under KTLO
  2. Skyscrapers does a Platform and workload review (max 4. hours) with the customer to
    • ensure everything is stable and in a maintainable state
    • opportunities for lowering costs, turning of unneeded resources, resizing certain workloads are identified

During KTLO

  • All communication and cooperation is done through named support contacts only.
  • No other users are supported nor get access to Slack, GH, etc.
  • No status calls
  • Quarterly check-in to stay in touch and see if all is good

Termination of KTLO

In case the KTLO cooperation is terminated, a hand-over can be done. We want to ensure you have a clear and risk-free path forward. Depending on your specific needs and plans, we have different options for an Offboarding Project (payable project).

Reverting back to DevOps-as-a-Service

Going back to full DevOps-as-a-Service is possible. We handle such a transition as a new project and agreement, and a re-onboarding will be done. The drift of the environment and practices that happened throughout the KTLO period is a major factor in the cost determination of this re-onboarding.

Details on Payable Services

Based on our Skyscrapers Responsibility Model and Service Definition, a non-limitative overview of what tasks and responsibilities could be payable services (€) under the KTLO SLA:

Platform Components

  • Provisioning, de-provisioning of Platform Components following best-practices
  • Implement configuration changes (per support request or pull request)
  • Cloud Managed: Major upgrades of Components
  • Deploy only + Managed Level: all become payable services

Platform Operations

  • Review PR’s coming from non-SkS teams

Platform Optimisation and Planning

  • Cost monitoring, analysis and optimisation
  • Platform capacity planning and scaling
  • Review and optimise cloud account for best-practices

Developer training and support

  • Platform usage training for developers Deliver guidance on cloud native application best-practices and recommendations

Support on Customer Data and CI/CD based tasks/deliverables

Other requests may be deemed payable by Skyscrapers. In this case Skyscrapers will inform the customer beforehand.

KTLO Service Terms

The following terms extend on the standard Skyscrapers Terms & Conditions:

  1. Definitions
    • Breaking changes: Required updates to the Platform to ensure operational efficiency and reliability of the Platform that may break functionality of Customer Workloads.
    • “Customer Workload”: a workload is a service or application that is developed and operated by the Customer and deployed to the Platform.
    • “Platform”: a deployment of a Skyscrapers Platform Blueprint into the cloud account of the Customer, deployed and managed by Skyscrapers as part of the Services
    • “Skyscrapers Platform Blueprint” The blueprint architecture, consisting of pre-integrated open-source technologies and cloud services, developed and evolved by Skyscrapers that enables Customer Workloads to operate.
  2. Skyscrapers will notify the Customer on upcoming Breaking Changes.
  3. The customer has the responsibility to update Customer Workloads to be compatible with these upcoming Breaking Changes.
    • If the Customer cannot implement these updates on time, Customer accepts the responsibility that Customer workload may break and Skyscrapers cannot be held responsible for any consequences.
    • The Customer can request to hold back on Breaking Changes for a limited time, which Skyscrapers at its discretion may accept.
    • In case Breaking Changes are on hold, no other updates (incl. security updates) will be rolled by Skyscrapers and Skyscrapers cannot be held responsible for any consequences caused by the Platform not being up to date.
    • In case Breaking Changes are on hold for too long Skyscrapers may determine the platform unmanageable in which case Skyscrapers has the right to terminate the agreement with 1 month of notice.
Last updated on