In this AI age the value of buying support can seem diluted. This is an exciting time where an AI agent or AI chat engine can give you an answer to a problem in seconds, even a complicated problem involving sophisticated software, configurations, and environments. However, there is a difference between an answer and a resolution. An answer can be wrong. But this might be just a temporary setback, because by prompting an AI tool more you could get better results and eventually reach a resolution. Even that might not be so different from your experience with a human support team in a ticketing system where there is often a back-and-forth exchange working toward a resolution. The main benefit of buying support in an AI age is accountability.
Accountability from incident to resolution
Accountability is what moves an incident to resolution. By buying software support you get a service level agreement (SLA) with LINBIT®. This includes a commitment to resolving problems and a timeline to do that. When you self support an open source software solution you get neither of those things, not from an AI vendor, nor from an in-house team. The responsibility to resolve issues stays within your organization. You or your in-house teams need to keep prompting an AI tool or persist themselves to resolve problems.
An example from LINBIT customer support
A pattern that is becoming more frequent in LINBIT customer support tickets highlights this. Some support tickets start with the customer already supplying complete problem analysis, often with the formatting and tone of AI-assisted work. The customer provides sound evidence of a problem, has reproduced the behavior, correlated log timestamps across nodes, and even proposed a change.
The conclusion is where these support requests often go wrong. The customer might claim that an event that happened after a failure is the cause of a problem, and proposes addressing that event. Read in order though, the cluster logs show that the failure started earlier. The proposed change would not have altered the outcome, and the actual resolution is a different configuration change elsewhere.
A LINBIT engineer reads the customer request, proposes an explanation, and asks for the complete cluster logs to better understand the context of the problem. Supplied with the logs, the engineer prompts an AI tool to build a timeline of events, with focus and follow-up questions guided by the engineer’s experience with this type of failure in other LINBIT client clusters. Based on the timeline shown in the logs and targeted follow-up requests for more output, the engineer develops an understanding about the failure pattern that allows the engineer to find the true root cause of the customer’s issue.
From there the engineer writes an analysis for the client, cites supporting log lines, and provides recommendations for changes that are tested and adhere to best practices of using LINBIT software. The engineer also notices that the timeline shown in the logs contradicts the explanation the engineer first proposed, so in the same reply the engineer withdraws the earlier explanation without the customer asking. This is unlike an AI tool that does not revisit a wrong answer on its own initiative. Without more prompting, a wrong answer stays.
Experience and judgment from the people who build the software
An AI tool can read the entirety of LINBIT documentation, knowledge base, blog, the LINBIT Community Forum, open source code, and mailing list archives. No LINBIT engineer’s head contains all of that knowledge. What the AI model lacks, even when supplemented with relevant documentation, is experience and judgment.
LINBIT engineers are intimately familiar with both LINBIT software and the many platforms (CloudStack, Kubernetes, OpenNebula, Proxmox VE, XCP-ng, and others) that the software can integrate with. The team has the experience of working daily, for nearly two decades, with production, enterprise deployments. Many of these are large and highly complex, running demanding configurations and intensive workloads that test the limits of the software.
The team can recognize deployment, configuration, environment, and other patterns, good and bad. This gives rise to judgment and reasoning skills informed by a big-picture perspective. AI tools are still lacking in this area.
A path from software bug to upstream fix
Not every problem is a software defect. A cluster can behave exactly as configured but the configuration can be wrong for the deployment. AI tools usually handle configuration problems well, because the relevant settings are documented publicly.
A defect in the software is different. DRBD® and LINSTOR® are open source, so you can write a patch yourself, possibly with help from an AI coding agent. What happens to that patch afterward is where the self support and paid support paths diverge.
For example, DRBD 9 ships as an out-of-tree kernel module1, and LINBIT builds kmod-drbd packages against specific kernel versions. A patch that you create and maintain locally has the same kernel dependency. You need to rebuild and retest it on every kernel update, and reconcile it with every DRBD release that changes the code you patched. For as long as you run the patch, you are its maintainer.
An AI tool can propose a correct patch, but it does not take responsibility for maintaining the patch after you apply it. Your maintainer role ends when the upstream project accepts the patch. From then on, the project maintains the change and includes it in every release. While you can submit a patch publicly upstream, a support contract gives you a direct path to the developers of DRBD and LINSTOR who can turn your patch into a software release in a timeline that better meets your needs as a LINBIT customer.
Design review for custom deployments
LINBIT solutions architects, developers, and support engineers have worked with many customers and use cases. They can help you design a deployment that fits your use case from the start. If your use case is novel, the LINBIT team can customize the deployment, and potentially make code revisions to better align with your needs. LINBIT customers can also sponsor more expansive feature requests, where feasible.
An AI coding agent can write a DRBD Reactor configuration or a LINSTOR API client for you, and that code might meet your needs. When the arrived-at code works, the issue is still accountability, plus the cost and time of maintaining it yourself. Someone has to update that code when a DRBD or LINSTOR upgrade changes the behavior underneath it, and someone has to answer for it when it breaks. Unlike a software patch, a custom configuration or an API client cannot be accepted upstream so you are responsible for maintaining these.
You know your environment and workloads better than LINBIT does. LINBIT knows its software and which deployment architectures have held up for other customers. LINBIT customers and LINBIT engineers can both use AI tools to benefit their part of the work. Specific architectures that LINBIT clients use are not published though. An organization that self supports with an AI tool does not have this information. For this reason, a custom deployment is more likely to keep working into the future if someone at LINBIT has reviewed the design before it goes into production. Reviewing new deployments before they go into production is standard LINBIT practice for customers.
Calculating the cost of self support
A software development and support company such as LINBIT spreads the cost of support over many customers. Traditionally, this means the cost of paying a support company will be less than supporting a solution in-house. In an AI age, this might not seem to be the case anymore. However, you need to consider the speed at which AI tools can give you answers against the speed at which they can give you resolutions. You pay for the time between an answer and a resolution in engineer hours and infrastructure downtime.
It is not only the salaries and your team’s time that contribute to calculating your costs to self support. You also need to consider the cost of diverting your team away from efforts that support your core business and revenue streams.
To match a 24×7 support tier, you need to add on-call duties, or rotate working hours to cover that. You also need to track releases, security advisories, and test upgrades, plus time to build and test packages. One person is not enough for these responsibilities so you need several engineers. This might be a challenge for a small business. Even if you have a competent team, if knowledge sits with one or two people, there is a risk that turnover disrupts your self support.
After calculating the cost of self support, reach out to the LINBIT team to compare against paid support options.
Prebuilt packages and customer repositories
LINBIT offers software packages so you do not have to build the software from source. Support customers get access to LINBIT customer software repositories, with prebuilt, signed packages and updates. While LINBIT also offers some of its software through an Ubuntu Personal Package Archive (PPA), and Debian and Proxmox VE public package repositories, LINBIT does not support packages from these repositories. They are intended for testing or homelabs. LINBIT only officially supports its signed packages in customer repositories.
Funding software that keeps your business running
Open source projects can stall. It is common to find a promising project in a blog or forum post, only to learn that nobody has developed it in years. In this era of AI-assisted coding, there is also no shortage of promising-sounding, hot-off-the-press software projects based on an interesting idea but lacking a development road map or a team to stay on maintenance tasks. Sadly, without long-term vision, many of these projects are likely to become abandoned, no matter how shiny an AI tool makes the README file or UI look.
Paying for support is what funds continued development of the software, which keeps it current with changes in kernels, platforms, and hardware. A company that continues to earn revenue from its software has a reason to continue improving it.
An AI subscription pays a model vendor, not the developers of DRBD and LINSTOR. When you ask an AI tool about DRBD or LINSTOR, it can draw on years of published source code, commit history, documentation, and mailing list archives. Paid support helped fund that material. A team that self supports with AI assistance benefits from both the software and that published record without funding either.
Choosing accountable support
AI tools can answer questions about DRBD and LINSTOR quickly and often correctly but they cannot be accountable for those answers. A LINBIT support contract gives you a responsible party that is committed in writing to resolving your problem, that answers for its advice, and that works with you to take fixes upstream. For high availability, software-defined storage, and disaster recovery in production, that accountability is the main reason to buy support.
If you use or are evaluating LINBIT software, including DRBD, LINSTOR, DRBD Reactor, LINSTOR Gateway, or LINSTOR with Kubernetes, CloudStack, OpenNebula, Proxmox VE, XCP-ng, or other platforms, contact the LINBIT team to discuss support options. You can also review LINBIT open source projects at the LINBIT GitHub organization.
-
The LINBIT team is working to put DRBD 9 in the mainline Linux kernel.↩︎
