5 ms·

> ...however if that glue actually works I might as well do that with 20 sht tier providers and let the redundancy cover gloss over it. No competitive advantage

• jacques_chester 7y ago
  > The super perplexing thing is that cloud providers jumped on the kubernetes bandwagon so quickly and this is what made this commoditization possible. My view remains that this was the purpose of Kubernetes: to scorch the earth ahead of ECS. Google had nothing to lose by doing so. > I've brought it up before, but the "Service Catalog" is basically identical to the user Operator (Controller + Custom Resource Definition) pattern, but for some reason it's being treated as different... The Service Catalog is based on the Open Service Broker API, which in turn was extracted from the Cloud Foundry Service Broker API. I hear folks say "it's not declarative", but typically this turns out to mean "it's not a YAML file". The fact is that OSBAPI is literally about telling the platform: hey, I need a service for this app. The brokerage process then works out how that's achieved. One such mechanism is Operators, there are also brokers that can apply Helm charts. The major difference is really about the CRDs as the point of interface. There's a fork or project somewhere which presents OSBAPI as CRDs (ie, YAML submitted to a remote REST endpoint) instead of as CLI commands (ie, JSON submitted to a remote REST endpoint). I feel like that's the best of both worlds. You keep the internal consistency of service discovery, service binding and service injection, plus the thing that really adds value: checking the YAML into revision control. Disclosure: I work for Pivotal. We compete with Red Hat / IBM. We also cooperate with them on OSBAPI and a number of other projects.
  • hardwaresofton 7y ago
    > My view remains that this was the purpose of Kubernetes: to scorch the earth ahead of ECS. Google had nothing to lose by doing so. I agree, but avoided saying it to try to not seem like a crackpot. I'm fairly sure I have a comment to the same tune somewhere in the back of HN somewhere (or maybe somewhere else). Also in the sounds-like-what-a-crackpot-would-say category of thoughts -- I don't trust the CNCF. Similar to how I don't trust the OIN. > The Service Catalog is based on the Open Service Broker API, which in turn was extracted from the Cloud Foundry Service Broker API. I hear folks say "it's not declarative", but typically this turns out to mean "it's not a YAML file". The fact is that OSBAPI is literally about telling the platform: hey, I need a service for this app. The brokerage process then works out how that's achieved. One such mechanism is Operators, there are also brokers that can apply Helm charts. No comment about this, "declarative" is just tacked on onto things as marketing fluff these days. OSBAPI is plenty declarative to me; you're telling it what you want instead of how to provide what you want. > The major difference is really about the CRDs as the point of interface. There's a fork or project somewhere which presents OSBAPI as CRDs (ie, YAML submitted to a remote REST endpoint) instead of as CLI commands (ie, JSON submitted to a remote REST endpoint). I feel like that's the best of both worlds. You keep the internal consistency of service discovery, service binding and service injection, plus the thing that really adds value: checking the YAML into revision control. Though heavily simplified, do I have the difference (written below) correct? API version: 0) User wants cloud provided service X 1) User makes service catalog CLI request (a web request is made to the broker) CRD version: 0) User wants cloud provided service X 1) User creates a CRD 2) Controller sees created CRD and makes web request to the broker If this is right, it seems like a very small difference.
    • jacques_chester 7y ago
      My understanding is that yes, you have a controller listening for CRDs which essentially stands in for the CLI/API step. To be fair, OSBAPI is a bigger upfront effort for a service author than fiddling with kubebuilder and sorta-kinda doing some basic service-y stuff yourself. Plus CRDs are the cool thing right now and I expect they will continue to build in momentum. Where it will come back to bite everyone is that every service will have its own Operator and its own CRDs and these will often be different in shape, behaviour and conventions than other Operators and CRDs. It'll be like the bad old days of every piece of software shipping with its own pile of bash scripts for management and twenty different process managers. You know: the sort of thing Red Hat helped to bring an end to. After we reach the point where you're spinning up whole clusters because the PostgreSQL operator doesn't play nice with the Kafka operator on Tuesdays when the breeze is too strong, someone wise and brave and famous on twitter will yell "this is insanity! Surely we can rationalise this into a single API, a single mechanism!" And then OSBAPI will be reinvented (but ... declarative!) while I stand at a safe distance, teeth audibly grinding down to bone.
• kahnjw 7y ago
  > The super perplexing thing is that cloud providers jumped on the kubernetes bandwagon so quickly and this is what made this commoditization possible. Pessimistically speaking, this means either they're either about to butcher the cross-cloud usability of kubernetes (i.e. drift between EKS,AKS,etc) or kubernetes was a wolf in sheep's clothing from the start. Is it perplexing? Didn't Google do the same thing with Chrome and Android? Understandably those aren't enterprise systems, but they successfully entered a market by open sourcing something that became wildly popular. In the case of Android and k8s, user cost is also reduced. Once it was clear that k8s won over mesos and docker's solution, AWS and MSFT didn't have much of a choice but to adopt it.
  • hardwaresofton 7y ago
    Yes, but it's weird that all the providers did this. I think in that analogy, what's happening is like Apple (the competitor to beat) at the time also started offering Android phones as soon as Android started to get traction. It makes sense for Microsoft/IBM/Oracle to jump on the k8s bandwagon because they're basically doing the worst/newest entrants but why AWS? They already had CloudFormation, along with lots of energy already dumped into SDKs for various tools (ECS, beanstalk, etc). There are a few other technologies that could have done this before k8s really took off, like pre-k8s openstack -- why didn't that get adopted?
    • wmf 7y ago
      AWS acts like they can win without obvious lock-in and so far it's working.
      • dragonwriter 7y ago
        AWS uses proprietary sinplifying management layers on top of common technology as a lock-in mechanism, and have announced their product in this direction (Fargate for EKS) for k8s, though it hasn't been deployed yet. AWS doesn't act like they can win without obvious lock-in, they act like they can win by extending open technologies with proprietary management layers that customers will depends on and be locked in by, which they do in pretty much every area.
• hyperion2010 7y ago
  In a truly competitive market cloud vendors would be trying to underbid each other for people's workloads. show me the code, show me the data, and let the bidding wars begin.
  • kahnjw 7y ago
    I keep hearing people say some variation of this without understanding the irony of the statement. A perfectly competitive market means, among other things, that there is zero barrier to market entry. That means you can enter the market without large capital spending. Given the amount of capital plowed into these gigantic platforms, any statement starting with "if tech were truly competitive..." is purely hypothetical and probably always will be.
    • hardwaresofton 7y ago
      I think you might be taking it too literally -- I don't think they mean "perfectly competitive" in the economics sense.The commenter actually "truly competitive", which I take to mean "in a market that was truly competitive". That said, somewhat orthogonal to your point -- the amount of capital applied to create these gigantic platforms is not indicative of what people can and do create with internalized cost -- the F/OSS movement has proven that. People have created immensely valuable software, and internalized/shared the burden of creating that software. I also think that it is entities with large capital that strive (and almost always end up creating) gigantic platforms -- it justifies their heft/consulting teams, etc. motivated single contributors/small groups never set out to giant platforms, they usually build things that do one thing well (see unix) and compose (see unix) to do greater things. More towards your point directly, you're right, a lot of things would stop making sense in a perfectly competitive market in the theoretical economics sense. Outside the fact that the model is wrong/incomplete (as all non-perfect knowledge models have to be), I do think this would lead to a certain number of competitors, but likely more than 0. My instinct is that the number of firms selling the product would be equal to the aggregated demand / costs to run a business selling the product -- and that ratio is probably greater than 1. Purely a spherical cow scenario but at least that's where I think it would go.
    • 7y ago
• Havoc 7y ago
  >I don't know what "shit tier providers" you're referring to The VM providers where you purchase a years worth of VM time but aren't entirely convinced they'll still exist as a business in 12 months. There is a whole ecosystem of sketchy oversold VMs that you can't push to 100% 24/7 but are dirt cheap. Not useful for business in itself, but 20 glued together...maybe.
  • dcc 7y ago
    Mo Servers Mo Problems... seriously, we need to be careful of what we dream of.