[acdha]

I'm trying to be charitable here, can you expand on that and explain why that's not an invalid comparison? For example, the word immediately after your quote was “S3”. That's not something the CNCF can solve for you since one of those is a service and the other is an application you can run — at the very least you need an _extensive_ ops and security if you're relying on it as much as S3 – and, assuming you're talking about Rook, you're comparing it to one of the largest, highest-scaling services in existence but here's what you're on the hook to do if you do it yourself:

* Kubernetes

* High-level storage services: Ceph, Cassandra, NFS

* Lower-level storage for whatever you pick for the previous point

Each of those, and the combined service you build, needs staffing for operations, monitoring, security, etc. support. If you follow any security standards or are in a regulated industry, you're on the hook for documenting compliance on all of those, too, especially if you need to be able to demonstrate things like immutability.

You certainly can do this but that's a number of full-time jobs requiring expertise. If you have enough storage usage you can potentially justify the savings over the rates you'd be able to negotiate but that's a big up-front cost which you hope but are not guaranteed to recoup.

[ryanjkirk]

Don't forget Minio for S3.

I took your previous comment to be about on-prem cloud technology. It exists and does not need to be "cloned". If you were taking about staffing resources, we've pretty well established you're going to need staffing to manage both cloud and on-prem tech.

You need to document whether it's on-prem or in the cloud.

[acdha]

I excluded Minio because that's not branded as a CNCF project but that doesn't make the comparison less invalid: if you're building an S3 replacement, you will need to spend a lot of money up front hiring people, buying hardware, and building an equivalent service. That's a significant 7+ figure commitment just to get to the point of saying that you have an equivalent service.

If you buy storage by the petabyte or use a large enough amount of network egress, you can definitely make that money back but it's a major commitment.

[ryanjkirk]

Again, you don't need to build an S3 replacement; you can deploy it onto k8s. This is the same skill set whether in a public or private cloud.

Agree, I don't think anyone is buying SANs that don't need them. If you're spending 7 figures on your AWS bill, you should be looking into other options.

[acdha]

> Again, you don't need to build an S3 replacement; you can deploy it onto k8s. This is the same skill set whether in a public or private cloud.

That is building an S3 replacement. You aren't writing every line of code personally but you are selecting components, configuring them, operating the service, and testing it, which is a major commitment. Simply running k8s at an equivalent level is a non-trivial commitment.

> Agree, I don't think anyone is buying SANs that don't need them. If you're spending 7 figures on your AWS bill, you should be looking into other options.

Note that the 7 figure commitment I mentioned was what you'd need to build an S3 equivalent. Simply having 24x7 staffing and hardware easily puts you in that range.

[ryanjkirk]

Nobody is arguing that a startup needs a datacenter; that is a ridiculous straw man. I'm well aware of the costs, having managed multiple colos as well as multiple cloud footprints. I also know you can lease most hardware, if you prefer not to depreciate assets.

You're casting this as a much more complicated concept than it is. It is essentially the same old "build vs buy" argument. No, it does not make sense to manage a datacenter to run a single wordpress blog, nor does it make sense for a telco to run their infra on top of a public cloud. These are all truisms.

My point stands that if you have a seven-figure AWS bill, you already have plenty of associated staffing costs. Once you hit the break-even point between the two, you can decide whether you want to continue to pay linearly, or go down the path of increasing RoI.