On a unrelated note, does anyone know the origins of the one way vs two way door analogy?
In this post it is attributed to Jeff Bezos quotes, but it was popular in the Pacific North West before his rise.
Predicting the Future of Distributed Systems
31–40 of 51 posts
Re: Predicting the Future of Distributed Systems
#32Earlier quoted context omitted.
I remember seeing your presentation many years ago, at Fosdem. Very cool project and if I would have to manage classic OS deployments I would definitely give mgmt a try. That being said, I think the world is moving to more immutable systems similar to how Talos works ( https://talos.dev ).
I would be hesitant to claim "the world is moving to" anything, really. Deployments that would now be called "traditional", so anything that does not run in a container but in a VM, will continue to exist for quite some time. And not only because of legacy systems that are hard to migrate to a modern platform. At my place of work there are workloads that can easily run on Kubernetes and it would be wise to do so. On…
>Deployments that would now be called "traditional", so anything that does not run in a container but in a VM, will continue to exist for quite some time.
I think there is even a widening talent gap where you can't get people excited about doing something that maybe should have been done years ago (assuming VM -> containers makes sense for a thing). The salary needs to go higher for things that are less beneficial to the resume.
The industry at large asks most developers to stay up-to-date, so it starts looking suspicious when a company doesn't stay up-to-date too. For C# in particular, companies who have only recently migrated to .NET 5+ are now a red flag to me considering how long .NET Core has been out.
Re: Predicting the Future of Distributed Systems
#33Earlier quoted context omitted.
I'd argue that a lot of people are moving from Kafka to NATS. NATS and Kafka serve different purposes and for many use cases related to APIs, NATS has a lot more to offer, like like wildcard topic topologies.
it's the Kafka API, not Kafka itself, that I see as having become the standard.
Which is honestly a shame. It's an awful API.
Re: Predicting the Future of Distributed Systems
#34Earlier quoted context omitted.
I would be hesitant to claim "the world is moving to" anything, really. Deployments that would now be called "traditional", so anything that does not run in a container but in a VM, will continue to exist for quite some time. And not only because of legacy systems that are hard to migrate to a modern platform. At my place of work there are workloads that can easily run on Kubernetes and it would be wise to do so. On…
>Deployments that would now be called "traditional", so anything that does not run in a container but in a VM, will continue to exist for quite some time. I think there is even a widening talent gap where you can't get people excited about doing something that maybe should have been done years ago (assuming VM -> containers makes sense for a thing). The salary needs to go higher for things that are less beneficial to…
I think we have to make a distinction between "concepts" being out of date and tools being out of date. I would not consider the concept (or architectural decision) to run a system on a fleet of VMs as outdated. However tools (e.g. compilers) absolutely go out of date once they are being deprecated and need timely migrations.
In the latter case I would consider it a red flag if some long-deprecated tool turned up in the tech stack of a company, but there might be perfectly good reasons to stick to the former, a bunch of VMs, instead of operating a Kubernetes cluster.
I ran a small Kubernetes cluster once and it turned out to be the wrong decision _at that time_. I think I would be delighted to see a job ad from a company that mentioned both (common hypervisors/VMs, containers/Kubernetes) in their tech stack. Without more information I would think that company took their time to evaluate their needs irrespective of current tech trends.
Re: Predicting the Future of Distributed Systems
#35Earlier quoted context omitted.
I'd argue that a lot of people are moving from Kafka to NATS. NATS and Kafka serve different purposes and for many use cases related to APIs, NATS has a lot more to offer, like like wildcard topic topologies.
it's the Kafka API, not Kafka itself, that I see as having become the standard.
Ce n'est pas un Kafka: Kafka is a Protocol
Apache Kafka is an aging open source project. It's time to accept that Kafka's protocol is what matters. (https://materializedview.io/p/ce-nest-pas-un-kafka)
Re: Predicting the Future of Distributed Systems
#36> Programming Models If you read this section, the author gets a lot of things right, but clearly doesn't know the space that well since there have been people building things along these lines for years. And making vague commentary instead of describing the nitty-gritty doesn't evoke much confidence. I work on one such language/tool called mgmt config, but I have had virtually no interest and/or skill in marketing i…
I remember seeing your presentation many years ago, at Fosdem. Very cool project and if I would have to manage classic OS deployments I would definitely give mgmt a try. That being said, I think the world is moving to more immutable systems similar to how Talos works ( https://talos.dev ).
> I think the world is moving to more immutable systems
Mgmt doesn't care whether or not you want to build your system to be immutable, that's up to you! Mgmt let's you glue together the different pieces with a safe, reactive, distributed DSL.
Regarding your Talos comment, Kubernetes makes building things so complicated, so no, I don't think it will win out long term.
Re: Predicting the Future of Distributed Systems
#37Earlier quoted context omitted.
I remember seeing your presentation many years ago, at Fosdem. Very cool project and if I would have to manage classic OS deployments I would definitely give mgmt a try. That being said, I think the world is moving to more immutable systems similar to how Talos works ( https://talos.dev ).
I would be hesitant to claim "the world is moving to" anything, really. Deployments that would now be called "traditional", so anything that does not run in a container but in a VM, will continue to exist for quite some time. And not only because of legacy systems that are hard to migrate to a modern platform. At my place of work there are workloads that can easily run on Kubernetes and it would be wise to do so. On…
> I think configuration management systems like mgmt (or Ansible and Puppet) are here to stay.
I think so too, however "mgmt config" builds a lot of radical new primitives that Ansible and Puppet don't have. It's been negative for my "PR" to classify it as "config management" because people assume I'm building a "Puppet clone", but I really see it as that space, it's just that those legacy tools never delivered on the idea that I thought they should have correctly.
Re: Predicting the Future of Distributed Systems
#38Earlier quoted context omitted.
>Deployments that would now be called "traditional", so anything that does not run in a container but in a VM, will continue to exist for quite some time. I think there is even a widening talent gap where you can't get people excited about doing something that maybe should have been done years ago (assuming VM -> containers makes sense for a thing). The salary needs to go higher for things that are less beneficial to…
I think we have to make a distinction between "concepts" being out of date and tools being out of date. I would not consider the concept (or architectural decision) to run a system on a fleet of VMs as outdated. However tools (e.g. compilers) absolutely go out of date once they are being deprecated and need timely migrations. In the latter case I would consider it a red flag if some long-deprecated tool turned up in…
I'm hiring for a company that is building a tech stack of VM's. My username at mastodon or twitter has the details, and it's about working with https://github.com/purpleidea/mgmt/
Re: Predicting the Future of Distributed Systems
#39Something missing here in the discussion of object storage and databases is any mention of the declining importance of the file system.
From the 70s through the 90s or 00s everything was file system-based, and it was just assumed that the best way to store data in a distributed system - even a globally-distributed one - was some sort of distributed file system. (e.g. Andrew File System, or research projects like OceanStore.
Nowadays the file system holds applications and configuration, but applications mostly store data in databases and object stores. In distributed systems this is done almost exclusively through system-specific network connections (e.g. port 3306 to MySQL, or HTTP for S3) rather than OS-level mounting of a file system.
(not counting HPC, where distributed file systems are used to preserve the developer look and feel of early non-distributed HPC systems)