Excerpts from Adam Lawson's message of 2017-04-18 10:33:32 -0700: > My personal feeling: > > We need to be very very careful. While I really respect Jay Pipes and his > commentary, I fundamentally disagree with his toolbox mindset. OpenStack is > one tool in the Enterprise toolbox. It isn't a toolbox. K8s is another tool > in the toolbox since it's turning out to be much more than just a container > management platform. Believe it or not AWS is another. > > I've been an OpenStack architect for at least 5+ years now and work with > many large Fortune 100 IT shops. OpenStack in the enterprise is being used > to orchestrate virtual machines. Despite the additional capabilities > OpenStack is trying to accommodate, that's basically it. At scale, that's > what they're doing. Not many are orchestrating bare metal that I've seen or > heard. And they are exploring K8s and Docker Swarm to orchestrate > containers. They aren't looking at OpenStack to do that. I recently > attended the K8s conference in Berlin this year and I'll tell you, the > container community is not looking at OpenStack as the means to manage > containers. If they are, they were likely sitting at the OpenStack booth. > Additionally these enterprises are not going to use two platforms side by > side with two means of orchestrating resources. That's both unrealistic and > understandable. Shoe-horning K8s into an OpenStack model really underserves > the container user space. > > OpenStack's approach is to treat K8s as a tool. > K8s is working to classify OpenStack as a tool. > > So to me we're one of two - maybe one of three solid FOSS cloud platforms - > not including Azure and AWS which are both trending up in consumer adoption > again. All of these are aiming to orchestrate the same resources and in > different ways, they each do it very well. A One Platform vision coming > from the minds within one of those projects creates unnecessary friction > and sounds a little small-minded. Big world out there - we're not the only > player.
I won't speak for anyone else, but when I say that OpenStack should be "one thing" I definitely don't mean "the only thing." What I mean is that someone selecting several OpenStack components to use to build their stack should have those components behave in similar ways, and use similar deployment and end-user patterns so that once someone figures out one component the next is easier to figure out. It would be great if those components were able to integrate directly with other tools not produced by the community (serving volumes to containers with Cinder or authenticating non-OpenStack apps with Keystone, for example), but that's secondary to the components produced by our community actually working together, in my mind. Doug > > In the end I guess I'm trying to say that we need to be careful when we > make assertions because this vision sounds like we're drinking too much of > our own Kool-Aid. When we assume our platform orchestrates the heap, we > need to understand there are several other heaps getting bigger and do > things OpenStack can't. If we buy into a marketing vision, we start a > downward path towards where Eucalyptus and CloudStack are today. > > Just my oh, 3 cents worth. ; ) > > //adam > > > *Adam Lawson* > > Principal Architect > Office: +1-916-794-5706 <(916)%20794-5706> > > On Tue, Apr 18, 2017 at 7:39 AM, Flavio Percoco <fla...@redhat.com> wrote: > > > On 16/04/17 09:03 +0100, Neil Jerram wrote: > > > >> FWIW, I think the Lego analogy is not actually helpful for another > >> reason: it has vastly too many ways of combining, and (hence) no sense at > >> all of consistency / interoperability between the different things that you > >> can construct with it. Whereas for OpenStack I believe you are also aiming > >> for some forms of consistency and interoperability. > >> > > > > Could you expand on why you think the lego analogy does not cover > > consistency > > and interoperability? > > > > > > Flavio > > > > -- > > @flaper87 > > Flavio Percoco > > > > __________________________________________________________________________ > > 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