Open Stack

Just because the market hasn't immediately shifted from IaaS to containers doesn't mean it won't happen eventually, and that google's wrong in their push for containers over IaaS. It took a long time (still ongoing) to move from physical machines to vm's. The same parallel will happen with containers I believe. We're at least a few years out from it becoming more common place. That doesn't mean folks can assume it will always be the way it is, and the "market has spoken". "The only constants are death and taxes." :)

Your right in the assertion k8s needs a place to run, but that doesn't necessarily mean OpenStack, unless we help integrate it and make it a great place to run it.

I'm glad the IaaS stuff in OpenStack suits your needs. Thats great. It hasn't served a great number of users needs though, and has been at least misleading folks into believing it will for a number of years. If we want it to just be an IaaS, lets free up those users to move on elsewhere.

Does OpenStack intend just to be an IaaS in a few years or something else?

Thanks,
Kevin
________________________________________
From: Monty Taylor [mordred at inaugust.com]
Sent: Friday, March 10, 2017 9:27 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 03/10/2017 10:59 AM, Clint Byrum wrote:
> 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 <zbitter at redhat.com
>>>> <mailto:zbitter at 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.

I agree with this strongly.

I get frustrated really quickly when people tell me that, as a user, I
_should_ want something different than what I actually do want.

It turns out, I _do_ want computers - or at least things that behave
like computers - for some percentage of my workloads. I'm not the only
one out there who wants that.

There are other humans out there who do not want computers. They don't
like computers at all. They want generic execution contexts into which
they can put their apps.

It's just as silly to tell those people that they _should_ want
computers as it is to tell me that I _should_ want a generic execution
context.

One of the wonderful things about the situation we're in now is that if
you stack a k8s on top of an OpenStack then you empower the USER to
decide what their workload is and which types of features it is - rather
than forcing a "cloud native" vision dreamed up by "thought leaders"
down everyone's throats.

It also turns out that the market agrees. Google App Engine was not
successful, until Google added IaaS. Azure was not successful until
Microsoft added IaaS. Amazon, who have a container service and a
serverless service is all built around the ecosystem that is centered on
... that's right ... an IaaS.

So rather than us trying to chase a thing we're not (we're not a
container or thin-app orchestration tool) - being comfortable with our
actual identity (IaaS provider of computers) and working with other
people who do other things ends up providing _users_ with the a real win.

Considering computers as some-how inherently 'better' or 'worse' than
some of the 'cloud-native' concepts is hog wash. Different users have
different needs. As Clint points out - kubernetes needs to run
_somewhere_. CloudFoundry needs to run _somewhere_. So those are at
least two other potential users who are not me and my collection of
things I want to run that want to run in computers.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev