Why Odin?

This article comprehensively shows the unique propositions of Odin which Playground still doesn't provide.

Playground is the current deployment platform used across Dream11. However, with Odin's latest version rolling out, Dream11 and other DS companies using Playground will move to Odin. At this point, it becomes important to know what Odin offers and why one should use Odin.

In this article, we are going to cover the difference between the two platforms as highlights.

1. Consistent tooling for all types of environments: Developers do not need to maintain and understand two types of changes required to run on Kubernetes and AWS env. Odin provides a consistent service definition that is used across the environments.

2. Define clear service boundaries: Odin forces to define clear service boundaries which sorta the responsibilities and owners of the components. There will not be any dangling components and every component will have to be part of some or other service.

3. Atomic service deployment: Either the service deploys successfully(here deployment means components are created, those are up and running, and functionally working fine) or it fails. There is no partial deployment state.

4. Pre-baking of the service: When service is released by the service owner, images are built and stored in the artifact at that time. While releasing the service, the service owner is giving a guarantee that everything is working fine i.e whatever was tested is still working fine. In the deploy step, Odin just runs the images created by the service owner, so there is a higher success rate of deployments.

5. Service as a BlackBox: Within odin, users of the service(non-service-owners) do not have to know the components required to provide the service. They can simply specify the service name and version/label and everything is provisioned by Odin which will be in up and running state for them.

6. Consistent deployments: In Odin, everything is versioned and when the user releases a service we take a snapshot of the configs at that time, so doesn’t matter when we deploy or where we deploy the deployments will be consistent.

7. Versioned Artifact: In Odin, services are versioned; any code change in any branch doesn’t impact the already deployed services.

8. Easy Maintainability: Developers do not need to maintain the provisioning-related things like dockerfile etc.

9. Purpose-based component provisioning: For functional testing, developers can provision containers which reduces service deployment time and cost drastically. And for performance-based testing, developers can provision actual infra required. This provides freedom to choose the component provisioning to the users.

10. Rule-based releases: Odin provides rule-bases releases e.g., developers can tag the service like qa_approved, perf_approved, and service will be deployed in an env only if these tags are assigned to the service.