Blog Post: Configuring Sidekiq for GitLab for specialized deployments; lessons from gitlab.com and elsewhere (Aug 25)

Triage (REQUIRED)

The Inbound Marketing team prioritizes requests that drive results and meet our goals of generating organic traffic and inquiries.

Please note that there is a different process for when you want to announce something via the blog. Please see announcement requests in the handbook and open an announcement request issue instead of a blog post issue.

Generally speaking, engineering blog posts that are tutorials/how-tos or which share how we built or debugged something, are popular with our audience. If your proposed blog post is aligned with our Attributes of a successful blog post guidelines, you can skip straight to your proposal.

If you are pitching something outside of those guidelines, please fill in the below to help us prioritize. You can check out examples of high- and low-performing blog posts to help with your rationale.

This issue fulfills one of these goals:

  • Drive traffic to our website
  • Convert traffic into leads
  • Thought leadership/share expertise
  • Build relationships with potential customers
  • Drive long-term results (please explain below in your proposal)
  • Announcement
    • Link to announcement request issue (required, see https://about.gitlab.com/handbook/marketing/corporate-marketing/#requests-for-announcements)
  • Cross-functional support
    • Link to OKR (required if this box is checked)

Proposal

What: A deep dive into configuring Sidekiq for GitLab for larger scale or complex/specialized requirements. Also a recap of our recent work in this area for gitlab.com (they're closely related, and the latter informs the former).

Why: Over the last few years we (Infrastructure for gitlab.com) hae gone through a number of subtle and not so subtle architectural changes in how we keep Sidekiq running at gitlab.com scale. There was a blog post last year (https://about.gitlab.com/blog/2020/06/24/scaling-our-use-of-sidekiq/) about the work to that point, and we're (Scalability team) just now nearing the end of a project to rework some of this again (basically the "next piece of work" from the last paragraph of that blog post, although the details have changed quite a bit since then). As such I'd like to:

  1. Cover what we actually did and why,
  2. Present a few additional examples drawn from other deployments (within GitLab, so it's not inherently private) to show how it's not only huge deployments that sometimes need careful attention, and
  3. Provide an holistic overview of where/when customers might need to think about customizing their Sidekiq deployment, and how to do so. Suitable documentation already exists (I think; I'll double check that) but this will be a more narrative experience than raw technical documentation can or should be.

To be very clear, not many of our customers will ever need to do this sort of specialized config, but it's technically interesting (in my view, at least 😄) and there's possibly some relatively small deployments with unusual edge cases that might benefit from the knowledge I'm hoping to share, who might not otherwise even realize/think they need to, and are suffering in silence.

It'll take me a few weeks to find the time to write it fully, and I'm in no particular rush (it's not time sensitive) so perhaps it's best not to schedule it formally yet. It's also going to be fairly long (it's not a trivial subject, no matter how tight the editing), if that matters.

Also I need to work on the title, it's a bit wordy as yet.

Roles and Responsibilities

Person Role
@cmiskell requestor
@person editor
@person approver (optional)

Checklist

  • If you have a specific publish date in mind (please allow 3 weeks' lead time)
    • Include it in the issue title and apply the appropriate marketing milestone (e.g. Mktg: 2021-03-28)
    • Give the issue a due date of a minimum of 2 working days prior
    • If your post is likely to be >2,000 words, give a due date of a minimum of 4 working days prior
  • If time sensitive
    • Add ~"Blog: Priority" label and supplied rationale in description
  • Indicate if supporting an event or campaign
  • Indicate if this post requires additional approval from internal or external parties before publishing (please provide details in a comment)

Production

  • Requestor to complete issue template (Triage, Proposal, Roles and Responsibilities, Checklist )
  • Issue sent through triage for consideration (pitch, planning/in progress, review, scheduled)
  • Issue assigned to requestor to draft blog post and open MR
  • MR created and linked to issue - issue is now deprecated in favor of MR and will close once MR is complete
Edited by Sara Kassabian