But there is plenty of software out there that opensource has not made a boring commodity platform. AWS has tons of services that are quite useful that have no real implementation today. I have users being pushed out of OpenStack onto AWS simply because it is so much cheaper to build applications on top of AWS as the common services on AWS mean they don't need to implement the bits themselves.
This is where OpenStack could still get a competitive advantage. But on the current trajectory, the plumbing those types of things need to use in OpenStack today are not agile enough. Take Trove as an example. The goal is to provide database as a service. The user doesn't care if it is launched on a vm, or if it happens through containers. But the latter is much faster to launch now, easier to code for, and easier to administrate for operators. But we're stuck trying to add more and more layers of abstraction to add compatibility with all the ways of deploying it on vm's and containers, rather then pick a winner and just go with it. Thanks, Kevin ________________________________________ From: Clint Byrum [cl...@fewbar.com] Sent: Friday, March 10, 2017 8:59 AM To: openstack-dev Subject: Re: [openstack-dev] [tc][appcat] The future of the App Catalog Excerpts from Joshua Harlow's message of 2017-03-09 21:53:58 -0800: > Renat Akhmerov wrote: > > > >> On 10 Mar 2017, at 06:02, Zane Bitter <zbit...@redhat.com > >> <mailto:zbit...@redhat.com>> wrote: > >> > >> On 08/03/17 11:23, David Moreau Simard wrote: > >>> The App Catalog, to me, sounds sort of like a weird message that > >>> OpenStack somehow requires applications to be > >>> packaged/installed/deployed differently. > >>> If anything, perhaps we should spend more effort on advertising that > >>> OpenStack provides bare metal or virtual compute resources and that > >>> apps will work just like any other places. > >> > >> Look, it's true that legacy apps from the 90s will run on any VM you > >> can give them. But the rest of the world has spent the last 15 years > >> moving on from that. Applications of the future, and increasingly the > >> present, span multiple VMs/containers, make use of services provided > >> by the cloud, and interact with their own infrastructure. And users > >> absolutely will need ways of packaging and deploying them that work > >> with the underlying infrastructure. Even those apps from the 90s > >> should be taking advantage of things like e.g. Neutron security > >> groups, configuration of which is and will always be out of scope for > >> Docker Hub images. > >> > >> So no, we should NOT spend more effort on advertising that we aim to > >> become to cloud what Subversion is to version control. We've done far > >> too much of that already IMHO. > > > > 100% agree with that. > > > > And this whole discussion is taking me to the question: is there really > > any officially accepted strategy for OpenStack for 1, 3, 5 years? > > I can propose what I would like for a strategy (it's not more VMs and > more neutron security groups...), though if it involves (more) design by > committee, count me out. > > I honestly believe we have to do the equivalent of a technology leapfrog > if we actually want to be relevant; but maybe I'm to eager... > Open source isn't really famous for technology leapfrogging. And before you say "but Docker.." remember that Solaris had zones 13 years ago. What a community like ours is good at doing is gathering all the exciting industry leading bleeding edge chaos into a boring commodity platform. What Zane is saying (and I agree with) is let's make sure we see the whole cloud forest and not just focus on the VM trees in front of us. I'm curious what you (Josh) or Zane would change too. Containers/apps/kubes/etc. have to run on computers with storage and networks. OpenStack provides a pretty rich set of features for giving users computers with storage on networks, and operators a way to manage those. So I fail to see how that is svn to "cloud native"'s git. It seems more foundational and complimentary. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
