Rendered at 18:58:57 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ssousa666 3 hours ago [-]
Nice write up. I have been working on an airgapped k8s-based, robotics simulation platform for awhile and this is one of the most accurate and coherent writings I've found on the subject.
I'll definitely be sharing this with my team.
s0ss 4 hours ago [-]
To me, BYOC will always mean "bring your own computer", which is amusing in this context.
hmaxdml 3 hours ago [-]
I thought that fell under BYOD (device) :)
collabs 2 hours ago [-]
In my mind, BYOD is like being able to use my own iPhone or laptop to connect to some corporate network. I think of this "device" as a client and I think of byoc as being able to run some application or constellation of applications on my own device or in a vendor neutral way on some cloud like a podman compose or something similar... Like not dependant on a particular vendor's "native" capabilities
tonyhart7 3 hours ago [-]
apparently computer + k8s connected to internet is considered cloud now
majormajor 2 hours ago [-]
"BYOC" deployment plans often require more than just k8s. "S3-compatible object store" is the most common one, IME. Or other sorts of scalable storage systems.
("Why does the vendor not just include that in the k8s they send you?" Usually because it's easier for them to leave everything about physical storage to the env maintainers.)
ClosedPistachio 4 hours ago [-]
Actual title is "BYOC Anywhere: The Spectrum of Bring Your Own Cloud Deployments"
nickmonad 2 hours ago [-]
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 value in them, but my experience doesn't always line up with it. 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. Our platform is quite load bearing for our largest customers, and in some cases directly in their revenue stream. There is no way they would ever let us push updates without going through their own internal controls of validation, testing, and sign-off. One could definitely argue these controls aren't entirely founded in reality, but corporate reality isn't always the reality you and I might share.
Besides the issue of automatic updates, we struggle with wild configuration differences that need pretty direct involvement with the customer. Security groups in AWS are just one example of this: some customers allow all internal VPC traffic between services, and others are quite strict in that every service needs a perfectly scoped security group with inbound/outbound rules. These have to be provisioned with their own tools built by their own teams under their own version control. We just ask for a configuration file in a well known location that defines these IDs we can reference in the CloudFormation.
So knowing that we essentially have to operate in the self-hosted model, CloudFormation becomes our mechanism for defining consistent deployments. For us to switch over to something like k8s just to fit into the model a BYOC-enablement tool like this wouldn't be worth it.
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. Taking an existing multi-tenant SaaS architecture and shoving it into this model, even with the ideal BYOC vendor-maintains-control-plane scenario is no small task. Even when you're talking about large enterprise BYOC deployments, you may only have a few thousand daily active users, which is dramatically less than what most SaaS vendors design for when operating in their own multi-tenant environments. ("Web scale" and all that.) At that point, I think engineering teams need to take a serious look at their architecture, and realize just how far they can get with fewer services, fewer machines, and fewer "event driven" architectural decisions. The deployment model _should_ be a forcing function for simpler architecture and system design, but I realize that's not a given. I think what I'm trying to say is that, knowing BYOC done well requires designing for it from the beginning, a well understood daily load profile and operational context kind of eliminates (or at least dramatically reduces) the need for tools like this, and that self-hosting isn't the worst possible outcome.
4 hours ago [-]
peter_d_sherman 2 hours ago [-]
This is a great document for understanding all of the terminology/considerations relative to cloud computing buyers -- a must read for cloud computing buyers, salespeople, or really, anyone else in that space...
I'll definitely be sharing this with my team.
("Why does the vendor not just include that in the k8s they send you?" Usually because it's easier for them to leave everything about physical storage to the env maintainers.)
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 value in them, but my experience doesn't always line up with it. 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. Our platform is quite load bearing for our largest customers, and in some cases directly in their revenue stream. There is no way they would ever let us push updates without going through their own internal controls of validation, testing, and sign-off. One could definitely argue these controls aren't entirely founded in reality, but corporate reality isn't always the reality you and I might share.
Besides the issue of automatic updates, we struggle with wild configuration differences that need pretty direct involvement with the customer. Security groups in AWS are just one example of this: some customers allow all internal VPC traffic between services, and others are quite strict in that every service needs a perfectly scoped security group with inbound/outbound rules. These have to be provisioned with their own tools built by their own teams under their own version control. We just ask for a configuration file in a well known location that defines these IDs we can reference in the CloudFormation.
So knowing that we essentially have to operate in the self-hosted model, CloudFormation becomes our mechanism for defining consistent deployments. For us to switch over to something like k8s just to fit into the model a BYOC-enablement tool like this wouldn't be worth it.
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. Taking an existing multi-tenant SaaS architecture and shoving it into this model, even with the ideal BYOC vendor-maintains-control-plane scenario is no small task. Even when you're talking about large enterprise BYOC deployments, you may only have a few thousand daily active users, which is dramatically less than what most SaaS vendors design for when operating in their own multi-tenant environments. ("Web scale" and all that.) At that point, I think engineering teams need to take a serious look at their architecture, and realize just how far they can get with fewer services, fewer machines, and fewer "event driven" architectural decisions. The deployment model _should_ be a forcing function for simpler architecture and system design, but I realize that's not a given. I think what I'm trying to say is that, knowing BYOC done well requires designing for it from the beginning, a well understood daily load profile and operational context kind of eliminates (or at least dramatically reduces) the need for tools like this, and that self-hosting isn't the worst possible outcome.