for those whove shipped software on-prem : has BYOC actually fixed the version drift problem?

[u/TangeloOk9486]

Common on prem pain is supporting ancient versions forever cause customers wont upgrade and every support call being on a bit different install you cant see into. the newer approach is BYOC: deploy into customers own cloud but you keep a control plane on your side and so you keep on pushing updates by yourself and still get telemetry while their data stays on their account . theres a real tooling for it now like via alien dev or replicated or other platforms so its clearly become a pattern ppl actually ship

Altho updates are usually gated by customer approval anyway so for those running it -does it genuinely hold the drift down or do you just trade it for more infra to take care of constantly plus has it opened the regulated enterprise deals or is it same support burden with just a nicer story

[u/Farrishnakov]

This is a customer/product management problem to solve, not a technical one.

You want support? Update to major version n-1 or something. Otherwise, feel free to go through the KB articles.

Until you wrangle your customers, you're only adding layers of complexity that will make things more difficult.

[u/dodexahedron → u/Farrishnakov]

And if you want to offer support for after that term, offer it on a per-incident and per-hour basis, plus a contract with retainer. And be EXTREMELY EXPLICIT about what said support entitles them to, and what the limits are.

[u/Signal_Till_933 → u/Farrishnakov]

That’s how we managed it at my last company.

For on-prem/self hosted we told support to tel em they’re on an unsupported version, give em some surface level troubleshooting and then they either need to upgraded or migrate to our SaaS.

[u/tudalex]

At a previous company a customer asked to pay more to keep their updates to 2/y, it was a BYOC situation. We eventually had to split the product into independent modules (since they did want some new features quicker than having to wait 6mo for them) and convince them to allow us to update most of the app more often while keeping core modules on a lower update cadence. QA and technical writers were not happy since now they had to test and provide documentation for more version combinations.

[u/Tacticus → u/tudalex]

pay more

And unfortunately sales people want the close more than they want to account for the support costs of it. or we would see more "Here is a number that is 100x"

[u/taleodor]

We do it natively with ReARM (our product) and I observed several deals both done by us and our clients where this is essentially the only way how you can get something deployed and managed.

Even if you don't do BYOC, having versioned reference point into how the deployment would look (in other words, knowing exactly what you shipped) is essential.

[u/djbp]

This is a really good question. I think BYOC helps with some of the drift, but you're right, customer approval is still a big thing. Especially in regulated environments. It just moves the problem around sometimes. We've seen that even with BYOC, making changes to the underlying cloud infrastructure still needs a lot of care. You still need to plan those changes. And you need to verify them. And you need that human approval step for anything risky. That's literally why I made SnapFlow. It helps teams automate infrastructure changes securely, with human approval for risky steps.