Learn how Sedai works with CI/CD integration to ensure changes to your codebase are regularly integrated, tested, and deployed.
The adoption of continuous deployment workflows is increasingly common in software delivery, with Git repositories serving as the source of truth for the declared state of applications in a runtime environment. This approach involves continuous monitoring of the runtime environment and synchronization of its state with the Git repository, ensuring that any changes in the source are seamlessly applied to the runtime environment.
While this approach has several advantages, it poses some challenges to systems like Sedai, which make runtime scaling decisions to enhance or maintain application performance and cost efficiency. This usually requires adjustments to resource allocation, limits, and scaling strategies. To address these differences in delivery models, Sedai provides multiple options for customers using GitOps workflows to leverage the benefits of continuous optimization and autonomous management:
This option closely resembles the configuration of auto scaling for a resource. In this approach, the declarative state of compute resources (such as AWS ECS, Lambda, or Kubernetes) excludes changes related to resource allocation and scaling (e.g., CPU, memory, replica count). Dynamic production runtime parameters, including the number of replicas, CPU, and memory, are not part of the source of truth (Git repository). Instead, Sedai, through mechanisms like auto scalers, manages the replica set and other resource allocation during runtime.
With this approach, there's no need for changes in the software delivery workflow for an environment. Sedai automatically detects releases made to resources. The CD workflow does not need to recognize the changes made by Sedai and can safely overwrite the resource allocation values as usual.
Sedai will automatically reset the resource configuration to the ideal values after detecting the release. However, this approach is effective only when the workflow overwrites values during new releases and may not work well with tools like Argo CD, which continuously monitor and synchronize the resource state based on the source of truth.
Sedai maintains ideal resource configurations once it has sufficient data to analyze application behavior. Customers can leverage Sedai (via REST APIs) to query the correct configuration for cloud resources and update configurations to tools like Argo CD or update the source of truth with the correct values.
This process can be performed periodically (poll-based) or triggered when there's a new release for a given workload. However, it may require additional scripting in the resource delivery workflow.
Sedai offers notifications for various events occurring within its platform, such as when Sedai makes changes to resource configurations. You can integrate your preferred webhook integrations to receive notifications with resource changes in JSON or YAML format.
This approach serves as an alternative to the poll-based approach, where Sedai notifies the configured channel about changes made or recommended by Sedai. The advantage lies in the timeliness of notification, eliminating delays in receiving information once a change is made by Sedai.
Sedai can periodically create pull requests (PRs) with all changes made by Sedai to all resources in a Git repository. The PR format can be either:
Sedai Standard Format
By default, these PRs contain data in a standard format that incorporates all modifications made by Sedai to the resources. Users can elect for the PRs to include the full WISB (including all changes made by Sedai and the unaltered configuration) or only the changes made by Sedai. Customers would then need to review the PRs using an automated or manual process and incorporate the changes in the correct locations in the Git repository holding the resource state.
Customer Specified Format
Alternatively, you can customize the configuration of the PR data format to align with the your preferred Git source format (such as Terraform Templates, Helm & Kubernetes YAMLs, etc.). To implement this customization, you will need to provide relevant files and variables governing the attributes managed by Sedai. Given the inherent flexibility and customization capabilities of IAC solutions, this type of integration is typically done direclty with the Sedai team.