The Next Big Thing In Software Architecture • Dave Farley • GOTO 2023

[@velvetsound]

This reminds me of a big enterprise DDD system I got to work with for a Fortune 200 company. Massively paralleled microservices/services, complete separation of actors, and Kafka messaging based. It was a brilliant and clever design and the enterprise architect was amazing. The only problem is that the infrastructure guys just couldn’t keep it running on-prem at more than 4 nines. This stuff is HARD to keep running reliably over time. I’ve also tried this design at smaller companies and had to abandon it as too many developers just couldn’t grok the pattern. So I also feel a level of talent and architectural maturity from your team leads is required.

[@WayneMunro]

Its ironic when the dependency on external systems is essentially minimized to a much more simple and efficient system design albeit on a cluster of sparce distributed nodes. I'm afraid to say everyone went down the garden path with container orchestration and its inherent complexity. It's really easy to get an instance of an entity by its reference scheme and mutate its state without any concern for a database. It's also super-fast as the processing is next to the state.

[@inamortz2372]

Always enjoy Dave Farley's content

[@kalmarnagyandras]

A really nice modern implementation of these things is the Elixir language.

[@filipetome6738]

Forty years after Smalltalk, everything old is new again.

[@rahulkulkarni1780]

Adding Erlang + BEAM which powers Elixir

[@dandogamer]

Also golang :)

[@StefaNoneD]

@@dandogamer Go channels are not actors!

[@johnridout6540]

@@StefaNoneD True, but once you have channels it's quite easy to build actors.

[@davidvernon3119]

I wonder what the definition of “big” Is in the context of Dave’s trading system. One of the mistakes that I’ve seen time and time again (but mostly from biz types) is to assume that whatever they are building is “big” when in reality a highly efficient and streamlined system running on a few computers (or 1) can easily replace the “massively parallel, decoupled, decentralized, time & location independent” approach.

[@iolapps]

Sounds great! Thank you

[@iolapps]

will compair it with kafka...

[@sergeypichkurov8757]

IMO, the essence about the actors is how systems are modelled, as it invites to focus on the abstractions that are closer to the real world, and model persistence around it, which is a better foundation. Actors complement quite naturally to DDD and Conway law. But all this assumes that orgs go and do hard stuff discussing with the business what they really want to achieve. Amazingly, people find this boring and rarely bother about these things. They are much more happy to jump coding right away after the project start one-pager is handed. No wonder most of those folks are in perpetual search for the "basics" too, that is inevitable...

[@Zebsy]

Its basically message queues then?

[@chewbaccarampage]

You're on point. Rich Hickey's talk "Simple made easy" says, "Actors are complex, and queues are simpler." He goes on to explain that "Actors complect what's going to be done and who is going to do it."

[@kellyfj]

Middleware doesn't sell itself you know!

[@piromanaBG]

This sounds like microservices with MQs and Kubernetes

[@filipetome6738]

This sounds like Smalltalk and Erlang. Why do we keep re-inventing the wheel?

[@BobFrTube]

How does this relate to Carl Hewitt's Actors from the early 1970s and Alan Kay's work?

[@rgs2007]

Are we talking about event driven development? I've though about that a lot lately. I believe that it would facilitate the use of ai in writing code and make development much faster

[@ashimov1970]

cool T-shirt 👍

[@kellyfj]

Monoliths are back and this time they're mad!

[@xasm83]

the next big thing since 1970s that you can find in any hello world actors tutorial - I was expecting really something new and "next"

[@kevanschwitzer8585]

Next bing thing: How about back to the basics?! Well, you can't sell conferences on that idea, but I'd watch a more GOTO content if that's what happened.

[@wklenk]

Should contain a warning: Possibly is suited for some very special use cases, but has high probability to ruin your bread-and-butter SW system if your developer find it "cool" to use actors now and a highly distributed system, when a simple and pragmatic monolith architecture also would be sufficient.

[@TheSunscratch]

That’s basically what happened with Akka.

[@WayneMunro]

Time to dust of the good old Service Fabric and its Virtual Actor programming model, or brush up on Dapr Virtual Actors that was lifted from Service Fabric and Orleans.

[@phenanrithe]

That's an old video (-IZlOPciSl0). Interesting video, but I've always wondered why the author only explained what an actor was so late. It's best to define it first so that the viewers understand what's said on them and stop wondering or, worse, make up their own mind about it. During all those minutes, I thought it was about the common event-driven paradigm that has been used for years in UI, so all that was said until the definition was lost on me. I would also avoid all the distracting fancy animations if they don't directly support the talk (which was often the case at the beginning). Viewers can either focus on the talk, or on those animations, but not on both.

[@paulfrischknecht3999]

people love creating complexity and solving the same problems 100 different ways, in big part because of laziness to try and fit the problem and solution into existing approaches (and laziness to even learn about them); most programmers are not scientists or mathematicians and don't think on an abstract enough level to appreciate this...

[@filipetome6738]

And recruitment scaling requires catering to the lower common denominator on the job market. There seems to be a trade-off between the complexity of the system and the complexity of the knowledge required to build and maintain it. The more narrow the focus of the developers - knowing a tool inside-out instead of knowing Computer Science and Systems Control in general - the more different components and thus higher coupling between components. I think this is a disease of expansion. Once the software industry stops growing exponentially and salaries are brought in line with the rest of the economy, we should shed most accidental complexity.

[@asdqwe4427]

Erlang

[@ernesto8738]

erlang wins again

[@moutasim_ayoubi]

Hey dave, can you make the videos 10 mins only, it's hard to watch for more than that

[@petropzqi]

The longer the better

[@moutasim_ayoubi]

@@petropzqi not always, sometimes I don't want to spend much time on watching.

[@RC-cy7pd]

Or do both - the shorter ones I can pass out to busy peers and leaders as I advocate.

[@jakub.anderwald]

I was happy this is only 16 mins long, not a full hour like a lot of goto talks :)

[@JamesSmith-cm7sg]

Step functions, lambda functions and queues...

[@kellyfj]

Make Programming More Complex Again