Future technical direction of Mesos?

[Andrei Sekretenko <as...@apache.org>]

Hi all,
while the vote on moving to Attic is ongoing (I hope that the current
standstill will end quite soon - by Attic+non-ASF fork, by lowering
the committer bar or in some other way), I think we need to (once
again) ask recent and potential future contributors and users:

In which exact direction would you like to see the project moving?
What are the things you need in Mesos and would be willing to contribute?
For the people and organizations who are maintaining private Mesos
forks - what is there in those forks that might be of value to the
community and you would like to merge into upstream?

I'm asking, because I'm under impression that an (unconscious) view of
some/many of the PMC is that Mesos is not  - and will never be -
solving any task that Kubernetes is not solving now and will not be
solving in the foreseeable future. _If_ one views Mesos+something as a
"contender in a container orchestration war" then that "battle" is
clearly lost.

Using the "bad analogy" Curl/Firefox by Charles-François Natali: what
are the tasks for which you use this "Curl" where it cannot be
reasonably substituted by "Firefox"? And do you envision other tasks
of these kinds?
--
In the other words: what do you want Mesos to be in the future?
A thing capable of running legacy Mesos frameworks for container orchestration?
A core of a system which struggles to keep feature parity with
solutions on top of K8s, has performance characteristics similar to
those solutions, but is not built on top of K8s?
Or... something entirely different?

In the two first cases, I would agree that Mesos has no future and
should be retired (and retired not only as an ASF project, but in
principle).
In the latter case - can you be more specific?

Note that, although the answers might impact the ongoing Attic vote,
the project needs them regardless of the outcome of that vote.

Best regards,
Andrei Sekretenko

RE: Future technical direction of Mesos?

[Marc <Ma...@f1-outsourcing.eu>]

> I'm asking, because I'm under impression that an (unconscious) view of
> some/many of the PMC is that Mesos is not  - and will never be -
> solving any task that Kubernetes is not solving now and will not be
> solving in the foreseeable future. _If_ one views Mesos+something as a
> "contender in a container orchestration war" then that "battle" is
> clearly lost.

I have been wondering about this. Not having any knowledge of kubernetes. At the time I decided to 'use' mesos it was my understanding that multiple networks (multihome tasks) were not possible with kubernetes. 

I saw some video where the mesos development team explained why there was a need to create a mesos containerizer because the docker one was not stable enough. Has kubernetes their own containerizer?

What should I think when I read about such things: "Kubernetes and Mesos employ different tactics to handle the same problem. Mesos is more ambitious, as Kubernetes equates to just a single node of Mesos’ entire solution."[1]

And last but not least, from a commercial aspect is it not better to be able to have choice? Ending up with only kubernetes will result in another tool for google to force their standards.

If I may continue your bad analogy. Apple is still making iphones although they clearly lost against the android platform. ;)


[1]
https://www.stratoscale.com/blog/kubernetes/kubernetes-vs-mesos-architects-perspective/

Re: Future technical direction of Mesos?

[Samuel Marks <sa...@offscale.io>]

What I would like to see is an *easy* way to maintain multiple clusters
[Postgres, Kubernetes, Kafka, Spark] across: one developer laptop; three
servers, five servers, all the way up to 10,000.

Currently at each 'tier' you need to use different tooling, particularly
when you get down to the developer laptop level. It should be trivial to
integrate Mesos into your workflow.

I funded a team [off my ideas] to decouple ZooKeeper from Mesos and enable
a choice betwixt Consul, etcd, and ZooKeeper. That is one [big] step in the
direction of having it usable at the low-end of targets [1 developer
laptop].

Looking at Kubernetes I don't see a competitor to Mesos. Well, at least not
as each project was originally envisioned… at last look Kubernetes still
sucks at stateful applications. If you're using Kubernetes to maintain your
distributed [out-of-memory] filesystem you're doing something wrong.

With a friendly getting-started pathway for Mesos—particularly for
low-resource targets—I see a decent future ;)

Samuel Marks
Charity <https://sydneyscientific.org> | consultancy <https://offscale.io>
| open-source <https://github.com/offscale> | LinkedIn
<https://linkedin.com/in/samuelmarks>


On Wed, Apr 7, 2021 at 7:47 AM Andrei Sekretenko <as...@apache.org>
wrote:

> Hi all,
> while the vote on moving to Attic is ongoing (I hope that the current
> standstill will end quite soon - by Attic+non-ASF fork, by lowering
> the committer bar or in some other way), I think we need to (once
> again) ask recent and potential future contributors and users:
>
> In which exact direction would you like to see the project moving?
> What are the things you need in Mesos and would be willing to contribute?
> For the people and organizations who are maintaining private Mesos
> forks - what is there in those forks that might be of value to the
> community and you would like to merge into upstream?
>
> I'm asking, because I'm under impression that an (unconscious) view of
> some/many of the PMC is that Mesos is not  - and will never be -
> solving any task that Kubernetes is not solving now and will not be
> solving in the foreseeable future. _If_ one views Mesos+something as a
> "contender in a container orchestration war" then that "battle" is
> clearly lost.
>
> Using the "bad analogy" Curl/Firefox by Charles-François Natali: what
> are the tasks for which you use this "Curl" where it cannot be
> reasonably substituted by "Firefox"? And do you envision other tasks
> of these kinds?
> --
> In the other words: what do you want Mesos to be in the future?
> A thing capable of running legacy Mesos frameworks for container
> orchestration?
> A core of a system which struggles to keep feature parity with
> solutions on top of K8s, has performance characteristics similar to
> those solutions, but is not built on top of K8s?
> Or... something entirely different?
>
> In the two first cases, I would agree that Mesos has no future and
> should be retired (and retired not only as an ASF project, but in
> principle).
> In the latter case - can you be more specific?
>
> Note that, although the answers might impact the ongoing Attic vote,
> the project needs them regardless of the outcome of that vote.
>
> Best regards,
> Andrei Sekretenko
>