I haven't used Fluid, but I just devoured all the info on it, and I want to share why I think it should be a game changer for most of us.
First - doing large scale collaborative state transitions is really hard if you want it to feel fast. The number of different factors at play range from the low-level wire protocol to the high level application design. It all has to be right, or you get very hard bugs.
Until now, I suspect most everyone wound up taking either the Operational Transform route or the CRDT route. What Microsoft did here was cleverly different (unique? certainly to me, and I've done a lot of reading and implementing here)
Essentially they split it up into 3 different layers. A "container" where the data + application logic lives. When you're operating at this layer, you're doing "easy" data structure work. It will feel pretty much like writing to an object/array/string.
Under the hood, it translates those into the operations needed, and submits them to a central service. That service gives them a total unique order. This is the key to what they've done - basically, they moved the clock for changes to a central spot.
By doing that, they got to do two things. One, they made it possible to scale well - the central store does very little: assign an atomic counter, distribute operations to clients, and create (and store) summaries to make things fast later.
If you've ever used Vuex/Redux/MobX, imagine getting the same behavior, but it's automatically synchronized at the session level across devices. With a UX that hides all the specialty stuff under the hood.
The genius of the design is that you could easily replicate and change the layers, and they've clearly thought about that. You can plug in different transports. You'll almost always build a custom storage layer anyway. Probably custom summarization too.
It's honestly a glorious piece of software architecture. I bet it works a fucking treat, because that design really should sing like a choir at christmas.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Adam Jacob

Adam Jacob Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @adamhjk

7 May
For people wondering if switching to the red hat model has worked for chef - super yes. It’s for others to give details, but I wouldn’t do the open core model again, if I wasn’t building on an existing free software island.
Selling the whole product, and having the whole product be open source, and having third party produced builds, collaborating together, it’s better on, I suspect, every angle.
It’s less clear you could begin this way, but I think you could. If we had, it would’ve been less of a shock to parts of the chef community. Not hearing a single conversation about lack of differentiation is like being in a hot tub, if you lived 13 years of it.
Read 7 tweets
28 Mar
Let's talk about this whole "k8s yaml is assembly" thing. When this gets said, it's often in a protective way. "The reason its so verbose is that it is assembly", or "The reason isn't dynamic is that is assembly". This is.. a bullshit excuse. It's not assembly at all.
What it is, is raw API calls. Without any of the kind of user tooling that might make it okay to make raw API calls. I know the story is, we're supposed to make those tools. But that's an enormous cop-out. A quick survey of the landscape shows that we're already @ ~6.
That's viable paths. None of which you could use effectively if you wanted to remain within the ecosystem broadly - each one will conflict with the others, do things slightly differently, and ultimately all of that will wind up straight on the user.
Read 19 tweets
18 Dec 19
Rust friends. Lets talk about async-std and tokio. There is a (relatively) polite cold war happening, and I'm pretty sure it's bad for all of us. Tokio paved a ridiculous amount of ground in the rust/async ecosystem, and it's been on a steady climb of improvement.
Much of that has been driven by real-world usage, building high performance networking code. That means it exposes all the knobs and fiddly bits you need when you care about the details. It also means that, when you first start, the experience is sometimes overwhelming.
It is, however, pretty damn solid. It's also quite quick, and pays a lot of attention to the details of what happens when you're in production (things like tail latency, which matters a lot when your request gets the shitty tail, and not so much when it doesn't.)
Read 9 tweets
30 Jan 19
I am not deep in k8s land. But I do have a drive by observation: the API being coupled to kubectl, and the behavior of a workflow being tightly coupled, is a mistake we made early at Chef with Knife.
We started out being very explicit about workflow. What happened next is predictable: it was the wrong workflow for some folks. So we made it pluggable (good!), but then it was harder to maintain and less portable (need this plugin for our workflow, sorry!)
The core set of behaviors need to be reliable and declarative, and accessible reliably from the API. If you’re going to include workflow in that, the above still applies. It’s either in or out.
Read 4 tweets
29 Oct 18
Paul Cormier says it clearly. Red Hat isn’t an open source company. They are an enterprise software company with an open source development model. That’s the thing anybody who thinks there will “never be another Red Hat” doesn’t get. arstechnica.com/information-te…
Folks who try to replicate it make a number of mistakes. 1: they don’t go fully open. 2: they make the project and their product identical, and free (as in beer) 3: they treat forks with hostility rather than welcome as collaborators on their upstream.
4: they build products for the wrong persona - the builders rather than the consumers. 5: they make it zero friction to move between the enterprise product and the open source project. The product is the differentiation.
Read 7 tweets
22 Aug 18
I have complex feels around the commons clause and whats happening now with Redis Labs. To get things out up front - I’m not a user of Redis Labs. I support peoples choices to license their work how they want, and to build their companies how they want.
As a part of a business model, open source gives a couple of things. 1 - the opportunity for a large community to arise, with their identity and effort mixed with that of the originators/companies. 2 - if that works, you have a shot to commercialize those users and contributors
In business terms, you’re creating a bigger top of funnel, with the hopes that you can drive reasonable conversion rates into $$ at the bottom. The size of your tent is what makes that $ possible. It because people use your software, but really works because they *identify* w/ it
Read 32 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!