How are we enhancing our support offering with EOD?

How are we enhancing our support offering with EOD?

Last year, we talked to many users and potential support customers, either because they contacted us (direct talks with technical pre-sales) or at conferences and meetups (talks at the booth). There was a “standard set” of questions and requirements when it came to running Open-Source Software in general and OpenSearch in particular for mission-critical systems.

  • There is a demand for professional support
  • There is a demand for 24/7 support
  • Companies favor long-term support over the latest and greatest features
    • Once production clusters are up and running, some companies will prefer running a stable environment for longer periods over experimenting with bleeding-edge features and frequent updates.
  • Bugs and security issues
    • As with any OSS project, companies have to rely on the community and maintainers for fixes and releases
    • Companies have only limited control over this process:
      • “What if the issue I reported is not being worked on?”
      • “What if the issue I reported was deprioritized in favor of other issues?”
      • “What if it takes too long until the issue is fixed?”
  • Release Cadence
    • Even if an issue was fixed and the PR accepted, customers still need to wait for the next official OS release
  • CVEs
    • CVEs are a big issue. Some companies have strict policies, and if a CVE is detected, you are not allowed to use that software in production

To support our customers as best as possible, we need to be able to answer all the questions mentioned above. We need to guarantee our customers that we can promptly provide them with bug fixes, CVE fixes, and other security-related fixes, guaranteed by SLAs, and bound by contract.

To do so, we need to be able to apply fixes and build OpenSearch releases outside the official OpenSearch release cadence (“hot fixes”). This must be possible on our own CI/CD infrastructure to meet our guaranteed SLAs. This will become part of our support offering and will be named “Eliatra OpenSearch Distro.”

Scenario 1

A customer detects a new issue that has not yet been reported on the OpenSearch Issue Tracker, or no fix for the issue is available yet.

  • We will analyze and fix the issue
  • We provide the customer with a build that contains the fix as soon as possible
  • We contribute the fix back to the community so it can be included in the next official OS release

Scenario 2

A customer detects an issue that is already known and being worked on. In this case, a PR may or may not already exist.

  • We will cherry-pick the existing fix
  • We provide the customer with a build that contains the fix as soon as possible
  • We contribute back to the community by collaborating on the PR: Suggestions, feedback, improvements, code