Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BYOC Anywhere: The Spectrum of Bring Your Own Cloud Deployments

omnistrate.com

Post reply on HN
Print view View original

21–22 of 22 posts

Re: BYOC Anywhere: The Spectrum of Bring Your Own Cloud Deployments

#21

Post by hodgesrm »

nickmonad wrote: post #11

I work on a pretty large BYOC deployment that we market as such, but is squarely in the "self-hosted" / on-prem model. We don't maintain any connection back to our environment and updates are driven by customers. It's pretty difficult for all the reasons you can likely think of. This space is quickly becoming a bit saturated, as these "BYOC enablement" tools and platforms are starting to crop up, and I can see the va…

> I'm actually really interested in hearing about a large enterprise running vendor code that would even entertain the idea the vendor could automatically update the entire deployment without their direct involvement.

A better word than "involvement" is "knowledge." We operate BYOC installations of managed ClickHouse and allow customers to pick upgrade windows. It's not that different from doing upgrades yourself. It's also important to remember that SaaS products upgrade without user intervention and often without user knowledge. That's one of the characteristics of the SaaS model.

> I think the most important aspect here though, and the most subtle one, is the issue of deployment and operational complexity. For BYOC to work well, the vendor really should be designing for it from the beginning.

This is definitely correct. We made a design decision early on that environments for managed databases (i.e., the data plane) are dedicated Kubernetes clusters for each tenant. Data plane services fit in the single K8s cluster and can be installed in 20 minutes or less over the network.

The Omnistrate article makes a great point that there are different flavors of BYOC depending on how much control users want. We have two variants: (a) fully managed stack in its own VPC where we install and run everything and (b) managed databases on user-supplied Kubernetes.

Re: BYOC Anywhere: The Spectrum of Bring Your Own Cloud Deployments

#22

Post by nickmonad »

kkgupta wrote: post #19
nickmonad wrote: post #11

I work on a pretty large BYOC deployment that we market as such, but is squarely in the "self-hosted" / on-prem model. We don't maintain any connection back to our environment and updates are driven by customers. It's pretty difficult for all the reasons you can likely think of. This space is quickly becoming a bit saturated, as these "BYOC enablement" tools and platforms are starting to crop up, and I can see the va…

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…

> 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/, 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.

Post reply on HN