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 <asekrete...@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 >
