Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: provide recommendation for strategies #3531

Merged
merged 4 commits into from
Apr 29, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 27 additions & 1 deletion docs/concepts.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,4 +46,30 @@ A Canary deployment exposes a subset of users to the new version of the applicat
[![How Canary deployments work](concepts-assets/canary-deployments.png)](concepts-assets/canary-deployments.png)

The picture above shows a canary with two stages (10% and 33% of traffic goes to new version) but this is just an example. With Argo Rollouts you can define the exact number of stages
and percentages of traffic according to your use case.
and percentages of traffic according to your use case.

## Which strategy to choose

In general Blue/Green is the easier strategy to start with, but also the more limited. We recommend you start with Blue/Green deployments first and as you gain confidence for your metrics and applications switch to Canaries.

You also need to examine if your application can handle canaries or not.

* Blue/Green always works because only one application is active at a time. Not all applications can have different versions running in parallel at the same time (which is what canaries are doing)
Copy link
Contributor

@meeech meeech Apr 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my only issue here is it muddies the fact that progressive canary also has a no traffic manager option. the way its emphasized implies canary doesnt

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

( i just saw the note at the bottom, but comment still stands)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok. I will update to make it clear.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thansk. I guess my issue was the big WITHOUT traffic manager, implying its a necessity for canary.

* Blue/Green is simpler because it works WITHOUT a traffic manager. Not all people like service meshes, and not all people have an ingress that is supported by Argo Rollouts
* Blue/Green also works with services that use queues and databases (workers that fetch tasks)

Here is a summary table for the two approaches.

Copy link
Contributor

@meeech meeech Apr 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| | Blue/Green | Canary |
| | Blue/Green | Canary w/Service Mesh |

or some other annotation to make clear. because no traffic shaping canary addresses some of the ease of adoption issue. which keeping benefits

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. But the big blocker is that Canary needs your application to have 2 instances that are both receiving live traffic at the same time. And not all apps can do this. The traffic manager is important but completely unrelated to that requirement.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair. I guess we rank that a bit different (in terms of ease). but i guess there's a big bag of gotchas/tradeoffs, and I get this is meant as an intro guide, so I'll try to avoid getting bogged in details.

| | Blue/Green | Canary |
|--------------------------:|:-------------------------:|:--------------------------:|
| Ease of adoption | Low | High |
| Flexibility | Low | High |
| Needs traffic provider | No | Yes |
| Works with queue workers | Yes | No |
| Works with shared/locked resources | Yes | No |
| Traffic switch | All or nothing | Gradual percentage |
| Failure Blast Radius | Massive impact | Low impact |

!!! note
It is possible to have canaries without a traffic provider. The routing will be coarse and based
on the number of active pods. A traffic provider will give you many more routing options.
Loading