D2iQ (formerly Mesosphere) sunsetting DC/OS and focusing on Kubernetes | Hacker News Reader

D2iQ (formerly Mesosphere) sunsetting DC/OS and focusing on Kubernetes

d2iq.com

101 pointshartem_34 comments

This is one where the market wants what the market wants and it wasn't mesos. In 2013/2014 I was super excited about mesos and then kubernetes came out. Having worked at Google, seeing this thing come out it was clear from the get go it would win. But if you're a startup with millions in funding running at 100mph you can't stop. It's impossible to course correct immediately and you shouldn't. You have to see it play out in the market. Even in hopes that you can continue to establish a strong business. In this case kubernetes ate everyone's lunch including mesosphere. It's sad. It's really sad to be a technologist who works on something for years only for that to become irrelevant when something comes out that takes the market in a different direction. And this gets even harder when every cloud provider starts using open source as a marketing and distribution channel. I experienced this with grpc. My original project is now no longer a company maintained effort but instead a side project once more and it's even been renamed. The perils of going up against Google. The only saving grace is to solve the same problem but in a different way. E.g move on to being a "platform".

I'm sad for Ben, Tobi and Flo but that's the game and sometimes it doesn't go your way.

This is why I think many a software engineer gets burned out around midlife. The "winner take all/most" dynamics don't just exist for internet companies, they also exist for technologies. Putting my blood, sweat and tears into some long term technology project, only to have it end up being on the losing end of "mind share" at some point, can be incredibly disheartening over time. Some years ago I worked at a company that decided to standardize on Flow (TypeScript wasn't yet the clear winner, and Flow seemed to be easier to integrate piecemeal into an existing project). It was a good bit of work - that is all now getting ripped out and converted to TS as the Flow ecosystem dies.

I think that may be one reason why many software engineers take up things like woodworking or sculpting: working in a 3D, physical, non-ephemeral medium can be incredibly rewarding after working in the space of easily disposable software.

We (Red Hat) sat down with the Mesosphere team pre-Kubernetes and were seriously considering Mesos and Mesosphere to replatform OpenShift (our PaaS) onto. When Google decided to make a run at Kubernetes, we decided to switch, despite having quite a few larger customers (financial, animation studios) urging us to go down the Mesos path. For us it was less history and accumulated baggage, the opportunity to learn from previous systems, to make the container spec a bit more core to the platform (since Mesos already had fairly opinionated choices in place), and to be less “high scale scheduling” and more “application infrastructure for the masses”.

I respected the choices and commitment the Mesosphere team had made, and their execution always reminds me that sometimes you have to commit, sometimes you have to pivot, and sometimes you don’t know which way is going to pay off. We might have gone down this path as well, and sometimes you’re not in the right place despite everything.

You and I have both spoken about what happens when a big vendor reinvents something you’ve created that has a lot of traction. This hurt Rancher with cattle, it hurt Docker in many ways, it’s now changed the direction of DC/OS irrevocably.

I do feel for all of the above and have personal experience with this bizarre situation. I wish all the best to Toby et al and hope they can continue to innovate for their customers and to flourish.

Mesos was always simpler to deploy and wrap my head around, but Kubernetes obviously won the most mindshare. DC/OS was Mesosphere's "enterprise" offering - however I wonder what this means for the Mesos product. I know there are still a couple large organizations still using it, but D2iQ employs most of the engineers working on Mesos, which isn't a good sign if they are no longer making money from it.

Pretty soon either D2IQ won't employ those engineers or they won't be working on Mesos.

I’ve got the exact opposite experience. Mesos is far more complex to run due to difficulty of developing a framework correctly. Kubernetes made the trade off to schedule centrally and that is probably the correct thing to do and definitely the more easy model to wrap your head around.

I would venture that most people using Mesos in Kubernetes-like use cases were deploying either DC/OS or Aurora, not writing their own frameworks.

All the large Mesos users I know of are moving to Kubernetes, I don’t know which ones you are thinking of.

Did Apple switch from Mesos? I know with the number of systems they were running Siri on Kubernetes might not have been possible. Then again they have the resources to build an in house replacement.

They certainly hired a bunch of K8s talent (and still are, I think).

Apple is huge. You will find more than one of every scheduler inside. No clue what their plans are around Mesos, but I think it’s safe to assume there are places it works well and will be slow to change.

Mesos didn't have a cronjob runner out of the box. There were other features like service discovery that were more intuitive in K8s as well.

Sad. DC/OS certainly had the best looking and easy to use UI.

That is true. Haha. :) Former dcos-ui and marthon-ui developer here.. ;)

Thanks for your work. It was a treat working in those UIs for some contract DCOS gov work.

It also had a significantly worse API. Just compare DCOS maintainence mode with cordon and eviction in Kubernetes.

"In fact, our recent survey report found that 89% of organizations are running Kubernetes in production or pre-production environments and that 77% of organizations feel that Kubernetes is a central part of their digital transformation strategy."

Self-selection bias? Of course by "organisations" they mean their enterprise clients.

I wonder how prevalent Kubernetes truly is, these press releases make it look like it is everywhere.

It's everywhere, and it's not going anywhere soon. Hopefully soon enough it will fade into a layer most don't see or care about, like the hypervisor.

This company's flagship product was a Mesos distribution. It actually is saying something if most of those customers wound up (also) running Kubernetes.

This seems like huge news and seems to be somewhat underappreciated/under discussed on HN... What's the over-under on number of months/years that Nomad will be able to compete?

I can't tell if consolidation in this space is a good thing (we finally get a single, extensible platform with widespread support, consistent APIs/models from vendors), or a bad thing (see: any other market lacking competition), but outside of Nomad and Swarm are there any other large container orchestrators that people put stock in these days?

Are we seeing the evolution of the VC model (subsidize-then-dominate) and/or it's application to F/OSS software? If I make a container orchestration platform (I've been sketching one out lately), do I have any hope in ever competing with Kubernetes for attention from developers, no matter how good what I make is (assuming ideological agility could offer benefits greater than millions of dollars is already a stretch).

Nomad is an interesting case. While everyone else was fighting container wars, Nomad was quietly executing and building a following. It’s not a threat to Kubernetes and it will probably never be, but it definitely has a dominant position in a niche of container orchestrators that just work. It doesn’t attempt to solve every infrastructure-related problem under the sun. Its main value proposition is that it’s simple to operate and reason about. That’s a no small feat, given how complex and fragmented Kubernetes and the ecosystem around is.

Kudos to Hashicorp for staying true to themselves and always keeping the interest of their users at heart.

This is the way it always goes with innovation - when there is some new technology you can have the small agile firms with outside capital make huge gains. Then one of the big guys notices, consolidates the space, and now that space is basically a no mans land for new capital and innovation by small firms. The small firms made something interesting and novel, the big guys scale it and optimize it.

I don’t think that means the VC model is dead, just means they have to look around the fringes for things the big guys aren’t doing for the next five plus years

Mesos was exciting when it came out - the ideas weren't new, but it offered a level of polish and cohesion for those ideas that wasn't readily available beforehand. I'm glad it existed, and glad I got to implement a few projects using it.

But, I'm not surprised. K8s is easier to work with if you're a startup and really working from a greenfield perspective, and most enterprises still have a lot "Pet" style servers around. It seems like they never found the great fit they would need to survive in the face of stiff competition and a quickly evolving marketplace.

I wish them the best of luck with this shift and anything else they might pursue in the future. Focusing where they did at that point in time was a gamble, and the type of gamble that pushes innovation in tech forward.

Mesos was a joy to work with in the early days of containerization. Easy setup, good documentation, few dependencies. It sucks that it just got outclassed over time by ECS, Docker Swarm, nomad, etc.

Ending up as another 'kubernetes is a pos to setup and maintain' clone is a gasp of an ending.

Having worked with a few container systems, and ported apps between them, I’d say Docker based images with 12 factor app patterns make porting very strait forward. It was a great intro to container systems, my first I think. K8s was last for pro, Docker Swarm for amateur.

Used to use Mesos at my last job. It was ok, but the tool ecosystem around it just didn't stay up to date with the needs of the industry. Secrets, Ingress, Cron type problems were difficult to manage and we had to write some in-house stuff to handle it. The zookeeper backend was a pain in the ass of course. Upgrades and recovery from master failures sucked.

I'm not saying Kube is the easiest thing in the world, but in OSS DevOps what you need is an industry standard with a good tool ecosystem. And Kube has that.

Quick question, based on this, would it be a bad idea if I decide to use Mesos for Spark based scheduler?

Well there's nothing stopping your from using it. Beta Spark 3 and History Server was pushed out recently.

https://universe.dcos.io/#/package/beta-spark/version/latest

I did not cared about Git, Mercurial was my friend, until I got dragged into Git.

I got disappointed with what Go might have been, and tried to ignore it as much as I could, although still thinking it is kind of ok for C like programs, now with Kubernetes infecting my world, I slowly feel the need to just suck it up with Go.

This is why one cannot have nice things.

You and I have disagreed on Go in the past, and I appreciate people’s criticism for Go. The type system isn’t the elegant algebraic ideal that many of us have, and it’s not even the messy generic implementation that many of us are familiar with (a la Java et al). The thing one must confront is that Go is designed to be a pragmatic software engineering language, and type systems (or really any individual in-language feature) simply aren’t going to make a big difference in most projects. The things that matter are tooling, ecosystem, learning curve, deployment story, standardization, etc and Go really shines in these regards. Go mostly gets out of your way and it will steer you toward the happy path, which can be really grating if you have strong preferences (Go values standardization above individuality, personal flourishes, and ego). That said, Rust does a very good job of being pragmatic while also allowing for more personalization, elegance, and so on, so I expect it will gain market share.

I remember a language designed 25 years ago with those goals, it just failed because Bell Labs were no longer cool.

You shit on Go with almost every post you make. Give it a fucking rest.

It is hard to do that when not using it isn't an option.

Not everyone that has to deal with Docker and Kubernetes jumps of joy dealing with the Go ecosystem.

Reply on news.ycombinator.com