1. OSBAPI is not widely known outside of the Cloud Foundry community it came from. In turn that's because Cloud Foundry is not widely known either. Its backers never bothered to market Cloud Foundry or OSBAPI to a wider audience.
2. It imposes a relatively high barrier to entry for implementers. You need to fill in a lot of capabilities before your service can appear in a conformant marketplace. With CRDs you can have a prototype by lunchtime. It might be crappy and you will reinvent a whole bunch of wheels, but the first attempt is easy.
3. Fashion trends. The first appearance of OSBAPI in Kubernetes-land used API aggregation, which was supplanted by CRDs. Later implementations switched to CRDs but by then the ship was already sailing.
4. RDD. You get more points for writing your own freeform controller than for implementing a standard that isn't the latest, coolest, hippest thing.
It's very frustrating as an observer without any way to influence events. OSBAPI was an important attempt to save a great deal of pain. It provided a uniform model, so that improvements could be shared amongst all implementations, so that tools could work against standard interfaces in predictable ways, so that end-users had one and only one set of concepts, terms and tools to learn. It also made a crisp division between marketplaces, provisioning and binding.
What we have instead is a mess. Everyone writing their own things, their own way. No standards, no uniformity, different terms, different assumptions, different levels of functionality. No meaningful marketplace concept. Provisioning conflated with binding and vice versa.
It is a medium-sized disaster, diffuse but very real. And thanks to the marketing genius of enterprise vendors who never saw a short-term buck in broad spectrum developer awareness, it is basically an invisible disaster. What we're heading towards now is seen as normal and ordinary. And it drives me bonkers.
1. OSBAPI is not widely known outside of the Cloud Foundry community it came from. In turn that's because Cloud Foundry is not widely known either. Its backers never bothered to market Cloud Foundry or OSBAPI to a wider audience.
2. It imposes a relatively high barrier to entry for implementers. You need to fill in a lot of capabilities before your service can appear in a conformant marketplace. With CRDs you can have a prototype by lunchtime. It might be crappy and you will reinvent a whole bunch of wheels, but the first attempt is easy.
3. Fashion trends. The first appearance of OSBAPI in Kubernetes-land used API aggregation, which was supplanted by CRDs. Later implementations switched to CRDs but by then the ship was already sailing.
4. RDD. You get more points for writing your own freeform controller than for implementing a standard that isn't the latest, coolest, hippest thing.
It's very frustrating as an observer without any way to influence events. OSBAPI was an important attempt to save a great deal of pain. It provided a uniform model, so that improvements could be shared amongst all implementations, so that tools could work against standard interfaces in predictable ways, so that end-users had one and only one set of concepts, terms and tools to learn. It also made a crisp division between marketplaces, provisioning and binding.
What we have instead is a mess. Everyone writing their own things, their own way. No standards, no uniformity, different terms, different assumptions, different levels of functionality. No meaningful marketplace concept. Provisioning conflated with binding and vice versa.
It is a medium-sized disaster, diffuse but very real. And thanks to the marketing genius of enterprise vendors who never saw a short-term buck in broad spectrum developer awareness, it is basically an invisible disaster. What we're heading towards now is seen as normal and ordinary. And it drives me bonkers.