bassamtabbara

Interesting research from MIT on the LLM inference market (~$35-60B in 2025) reveals surprising dynamics that challenge both the “AI is a commodity” and “winner-take-all” narratives. Approximately $25B in annual spending — roughly 70% of the market — represents potential inefficiency.

I think [1] is a good definition of the architectural pattern (outside of networking applications). It’s the one we use within the crossplane community [2]

[1] https://aws.amazon.com/builders-library/avoiding-overload-in...

[2] https://crossplane.io

disclaimer: I'm a maintainer on Crossplane.

OAM is an optional feature of crossplane - you don't have to use it if you don't want to

[disclosure: I started the crossplane project and ceo/founder at upbound]

If you look at the governance of Crossplane [1], you'll see the three original maintainers of Crossplane (all Upbound employees) will be bootstrapping the steering committee and have a 2 year term, 2 others are currently being added without upbound affiliation. We believe this bootstrapping period is important to ensure that the project remains true to its vision, and to build trust and rapport with new folks joining the project. After the bootstrap period ends, the community will vote new members in. This is the same way Kubernetes and the CNCF Technical Oversight Committee were bootstrapped.

Upbound will have a commercial solution around Crossplane, but our commercial goals are not at odds with creating a strong open source community with strong governance. For Crossplane to be successful it's going to take a village, this is why we're donating it to the CNCF.

[1] https://github.com/crossplane/crossplane/blob/master/GOVERNA...

I made a similar argument [1][2] about tipping the cloud computing market from vertical to horizontal integration. One important aspect of this transformation is to maintain the feel of an integrated cloud provider, and not let the customer/end-user deal with the cost of heterogeneity [3].

[1] https://www.youtube.com/watch?v=GOssXrkNYxM

[2] https://speakerdeck.com/bassam/opening-up-the-cloud-with-cro...

[3] https://crossplane.io

note also it has "k" in the name (despite it being at the end). So it's legit.

Hehe. We considered a nautical theme at one point but thought it was a bit overdone :-) (I’m a maintainer on rook)

> How does this work in a world where developer administer their own services?

in that world the developer plays admin too, and can configure crossplane as an admin.

+1 we really wanted to leverage the ecosystem and have something that is immediately familiar when we decided to use kube-apiserver (and etcd) for crossplane. I think the K8S resource model [1] goes well beyond container orchestration

[1] https://docs.google.com/document/d/1RmHXdLhNbyOWPW_AtnnowaRf...

Great response! Regarding naming we did not want to tie the company to a single project, not did we want the project to feel like a vendor driven project. So we went with different names completely :-)

Yes, indeed. There appears to be an overlap in general principles (even in use-case example). From what it appears, KEP sig was "published/released" (not sure what is the right term here) on the GitHub 3 days ago, we did not see this. We will definitely reach out for further discussion.

hi bassam here (CEO @ Upbound). Our business model is still firming up, but we're thinking we would be hosting crossplanes among other things. We want the crossplane project to be community driven (and not vendor driven) and welcome other contributors (see our governance model).

scarejunba, this bassam (one of the maintainers on crossplane).

when you ask for a DB you get an instance of RDS/CloudSQL/etc., in other words you are using the managed services of your cloud provider.

we're just getting started with cross-cloud scenarios. would love your feedback on https://github.com/crossplaneio/crossplane

Hi, this bassam (one of the maintainers on crossplane). We describe the relationship in our arch doc here https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9.... The following snippet is from that doc:

The AWS Service Operator is a recent project that implements a set of Kubernetes controllers that are able to provision managed services in AWS. It defines a set of CRDs for managed services like DynamoDB, and controllers that can provision them via AWS CloudFormation. It is similar to Crossplane in that it can provision managed services in AWS. Crossplane goes a lot further by offering workload portability across cloud multiple cloud providers, separation of concern, and a scheduler for workload and resources.

I heard it was a surprise to almost everyone at RedHat.

There's also this one https://github.com/ianlancetaylor/demangle

disclaimer: I work on project Rook.

Yes building a whole new data path is complicated and takes many years to get right. Its also somewhat of a moving target with new storage technologies appearing on the scene (like SMR drives, NVME, and persistent memory).

It would be much more effective for the community to coalesce around a common data path just like we coalesce around kernels. Something like Ceph is a great start, its battle-tested and has storage vendors (like Intel, Samsung, SanDisk and others) updating/optimizing it for new kinds of storage.

The focus on simplicity and integration into cloud-native environments is critical however and Torus' vision was spot on. Kudos to the CoreOS team for raising the bar on this.