The operational challenges that you highlighted with BYOC makes sense and they need to be addressed.
- On upgrades, agree that “vendor managed” shouldn’t mean “the vendor can push arbitrary code whenever it wants” especially with the supply chain risks. Our experience is that vendor should make the new upgrade available and notify the customer, customer can run its change-control pipeline and approve the version, the control plane automates rollout/health-check/rollback, etc. To your point, automation only removes the operational toil but not the governance.
- Same with the networking, IAM, etc. A BYOC platform can’t always assume it owns the customer environment or one size fit all. Some customers will let you provision everything; others will insist networking/security infrastructure comes from their own Terraform/CloudFormation pipelines and give you IDs or interfaces to consume. I think a good BYOC model has to make that boundary explicit.
- Also, rewriting your app onto Kubernetes just to fit a BYOC platform would be backwards. Agree that the BYOC tooling should adapt to existing application architecture, not dictate it.
I am not sure if simplifying the application removes the need for this tooling as much of the complexity lies with establishing the enterprise trust boundary across accounts with things like identity, networking, permissions, artifact approval, upgrades, drift, auditability, governance controls, and eventually exit. This website tries to cover it in detail: https://byocanywhere.org/, WDYT?
Finally, I feel that there is a value in shrinkwrap software deployment model especially if one has the requirement of a relatively small number of very large, disconnected installations, and high-touch support. BYOC model make more sense if you want to scale or customers like to preserve customer control and managed experience like Databricks, Anyscale, Snowflake..
- On upgrades, agree that “vendor managed” shouldn’t mean “the vendor can push arbitrary code whenever it wants” especially with the supply chain risks. Our experience is that vendor should make the new upgrade available and notify the customer, customer can run its change-control pipeline and approve the version, the control plane automates rollout/health-check/rollback, etc. To your point, automation only removes the operational toil but not the governance.
- Same with the networking, IAM, etc. A BYOC platform can’t always assume it owns the customer environment or one size fit all. Some customers will let you provision everything; others will insist networking/security infrastructure comes from their own Terraform/CloudFormation pipelines and give you IDs or interfaces to consume. I think a good BYOC model has to make that boundary explicit.
- Also, rewriting your app onto Kubernetes just to fit a BYOC platform would be backwards. Agree that the BYOC tooling should adapt to existing application architecture, not dictate it.
I am not sure if simplifying the application removes the need for this tooling as much of the complexity lies with establishing the enterprise trust boundary across accounts with things like identity, networking, permissions, artifact approval, upgrades, drift, auditability, governance controls, and eventually exit. This website tries to cover it in detail: https://byocanywhere.org/, WDYT?
Finally, I feel that there is a value in shrinkwrap software deployment model especially if one has the requirement of a relatively small number of very large, disconnected installations, and high-touch support. BYOC model make more sense if you want to scale or customers like to preserve customer control and managed experience like Databricks, Anyscale, Snowflake..