57 ms·
Solomon, wait, just 2 days ago you said CF was throw away code and not on your radar? Care to explain your pivot to 'intriguing'? https://twitter.com/solomonst
by wattersjames 14y ago
Solomon, wait, just 2 days ago you said CF was throw away code and not on your radar? Care to explain your pivot to 'intriguing'?
https://twitter.com/solomonstre/status/209895170194423808 https://twitter.com/solomonstre/status/209895170194423808
- shykes 14y agoHi James, in this tweet I'm referring to phpfog, which has been publicly deprecated (the polite term for "throwing away the code") in favor of a cloudfoundry deployment. Not necessarily a bad move in their situation... but yes, as a result it is not a very fearsome contender in the paas market.
- shykes 14y agoI just looked you up and found out you're a cloud foundry evangelist. Would love to hear your thoughts on my original question. In your experience do cloudfoundry resellers contribute all of their customizations? Do they sometimes emphasize non-contributed extensions as key differentiators? And if so do you see this as a possible concern for the cohesion of the project? Do you (vmware) do anything to discourage (or perhaps encourage) this behavior?
- wattersjames 14y agoI'm not an evangelist, but I am a member of the Cloud Foundry team, and responsible for partner development and ecosystem. I think you are creating a straw man question as the overwhelming majority of partners have open sourced most/all of the applicable code. Take a look at http://www.ironfoundry.org http://www.ironfoundry.org for instance from Tier3 who has taken a very liberal approach to open source with their Cloud Foundry based service. Appfog has also contributed back their code for PHP to Cloud Foundry. They are doing a very nice job of expanding the potential deployment targets as one of their competitive advantages (HP, Joyent, most EC2 regions). Thus to answer your question I've seen robust contributions back with a very liberal amount of open source code, and a focus on value-add through service delivery options. I'm curious about your view of the hybrid deployment model many of our users prefer with an on-prem instance that can be deployed to multiple service providers.
- shykes 14y ago"I'm curious about your view of the hybrid deployment model many of our users prefer with an on-prem instance that can be deployed to multiple service providers." I see these as 2 separate things: - By "on-prem instance" I'm guessing you're referring to a local VM which mimics the remote deployment target? I think that is a cool and useful feature in the "nice-to-have" category. - By "can be deployed to multiple service providers", I guess you mean that the portability between cf-enabled providers frees developers from lock-in? In my opinion this solves a non-existing problem. Developers can already deploy to multiple service providers with almost zero effort, because all service providers rely on open standards for deploying web applications. As a result portability is incredibly good between dotCloud, Heroku, Cloudfoundry and almost everybody else. Of course it's up to the developer to not lock themselves into proprietary APIs which are only available on certain service providers (eg. App Engine).
- deleted 14y ago[deleted]