3 ms·
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
by kkgupta 2mo ago
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/ 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..
- nickmonad 2mo ago> 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. As it stands today, we have an AWS-only product (for better or worse) so we can accomplish this already with CloudFormation. It's not the best "control plane" as far as updates and rollbacks go, but it works pretty well for our needs. Obviously, trying to do the same across multiple cloud providers, would mean bringing in a different tool. At that point, the vendor's architecture would need to be neutral as well. > 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/ https://byocanywhere.org/, WDYT? I think that website is a solid resource. Those are certainly important issues to solve that all surround the actual vendor code itself, and I can see value in making an attempt to solve it. It's just my experience that every customer wants to do it differently. I'm just not sure how much slower and painful our contract negotiation would have been if we had to also sell them on a particular process other than "you provision these things with your own tools, and we'll hand you CloudFormation templates". Maybe other companies offering BYOC are better at selling the whole package, not just the "platform" itself.