The Next Big Thing In Software Architecture

Поделиться
HTML-код
  • Опубликовано: 14 янв 2025

Комментарии • 141

  • @_winston_smith_
    @_winston_smith_ 3 года назад +27

    This is the way! This is my default architecture. The main problem I've found in using it for many years is that a certain percentage of programmers really struggle with the concept and are better kept working on the internals of actors, rather than the messaging and coordination of multiple actors (which should be minimal if you are doing it right).

  • @pompiuses
    @pompiuses 3 года назад +52

    I think the complexity of an distributed architecture like this is understated in this video. Debugging, monitoring and handling of state can become very difficult. Most applications I've worked on have mostly synchronous needs, typically web gui's, batch jobs, interacting with rest services. Introducing an distributed architecture into these type of systems increases complexity by a lot. I'd think more than twice about my needs before going that route.

    • @monad_tcp
      @monad_tcp 3 года назад +1

      I got bitten by this a couple of times when I was leaning how to actually use it. But then you realize the situations where its useful to apply that architecture. (never as a silver bullet)

    • @EricKolotyluk
      @EricKolotyluk 3 года назад +1

      Actually, with Java 18, the tooling for concurrency will improve, and it will be easier to address your valid concerns. In particular, Structured Concurrency and other improvements in the JVM will make "Debugging, monitoring and handling of state" easier, safer, and more effective.

    • @brandonpearman9218
      @brandonpearman9218 3 года назад +2

      Nice to hear someone say something good about synchronous. So many companies I have worked at force asynchronous patterns on workloads that are synchronous by nature, and then they wonder why the user has a bad experience... The idea being you cant have a user wait for a response but you can have a user wait for eventual consistency. Would you rather have a user receive an error message or wait for an unknown amount of time for their data to save and become consistent.

  • @idcmardelplata
    @idcmardelplata 3 года назад +15

    It is precisely because of these properties of the actor model that I use Elixir as the main language for the backend.
    Thanks for the video, great content as always :)

  • @1foxmark
    @1foxmark 3 года назад +58

    I would like to watch one more episodes with more practical application and implementation. Especially the messaging system on such a massive scale. Very interesting speech - thank you very much.

    • @DavidAtTokyo
      @DavidAtTokyo 3 года назад +8

      Lightbend have lots of videos available showing off their actor based Akka offerings. Dave kind of hints at AkkaServerless in the video too.

    • @charleskhenry
      @charleskhenry 3 года назад +3

      I very much agree. More implementation and examples would be so helpful!

    • @FrostSpike
      @FrostSpike 3 года назад +3

      Take a look at the Erlang use-cases in the telco industry with processes running over clusters of switches and their supporting ecosystem.

  • @chaouanabil3087
    @chaouanabil3087 3 года назад +8

    i think that actor model is the best model we have today to what alan kay meant about OOP. a distributed (transparent physical location) objects with a local state collaborating and communicating by sending messages.

  • @NotaUser1234
    @NotaUser1234 3 года назад +8

    I have worked with Lightbend's Akka and I couldn't agree more. The actor model is a great way to build highly concurrent, yet very efficient, backend systems. It should be used more.

  • @BrunoGabrielAraujoLebtag
    @BrunoGabrielAraujoLebtag 3 года назад +13

    I've worked with Actor based programming in Elixir/Erlang. I can confirm it! It is indeed awesome!!! I think programming languages should move to support actor based programming as first class citizen.

    • @monad_tcp
      @monad_tcp 3 года назад +3

      It indeed is. I used it on F# to write device drivers once. (it was for USB, so the timing wasn't that critical, we were communicating with an AtMega that actually did the processing of signals and turned them into messages in real time)

  • @MrAbrazildo
    @MrAbrazildo 3 года назад +6

    4:06, it's an instant relief to hear that. If we can count on a single entity to does the job, it's way less stressful to think the whole picture. 5:00, but here was the beginning of the end... Creating new actors can be good for AI net, but for software it will be easy to loose the track of things.
    5:15, I think otherwise the system would not be ambitious.

    • @yeetdeets
      @yeetdeets 3 года назад +1

      Since an actor would be deterministic and predictable in regards to input->output, sending 3x tasks to 3x actor clones would be the same as sending 3x tasks to one clone. This video sounds basically like Kubernetes combined with Docker, although I'm an amateur in this arena. Kubernetes + Docker seems to already be the standard in the cloud infrastructure to me as an outsider.

    • @MrAbrazildo
      @MrAbrazildo 3 года назад

      @@yeetdeets But you can easily look the track of how many actor would appear, in some moment. And if their tasks demand more actor, I don't know...

  • @SaHaRaSquad
    @SaHaRaSquad 3 года назад +2

    When I first heard about this my mind was blown. It makes thinking about concurrent tasks so much more intuitive. And distributing tasks across machines is trivial because the architecture already is basically a network of nodes and so the actors don't need to care how messages are transmitted.
    After working on one application using actors this has become my standard way of thinking about software design, it's one of those cases where the simple approach is also very practical.

  • @namewastaken360
    @namewastaken360 3 года назад +4

    Best t-shirt yet!

  • @davidpaez_co
    @davidpaez_co 3 года назад +4

    This approach sounds very similar to agent based modelling and simulation, used primarily to study complex social phenomena.
    Excellent video. Thank you Dave

  • @fsociety2871
    @fsociety2871 3 года назад +1

    I attended DevTernity last week and dave was one of the speakers, luckily I've been watching this channel for a few months now so I know him already. Watching his videos feels like I always attend a conference.

  • @juliankandlhofer7553
    @juliankandlhofer7553 3 года назад +9

    nice video! are you planning to make a video on what went wrong with log4shell/log4j? i feel like a logging library with causing rce using jni and ldap could be an interesting story about feature creep and what happens when simple projects get too big.

  • @algernon69
    @algernon69 3 года назад +3

    Dave I would like to know how you think of actor model compared to BDI agent model (Jade and Jack come to my mind)

  • @NigelFurtado
    @NigelFurtado 3 года назад +5

    Pub/Sub, message queues, Kafka/Confluent. This is what the big cloud service providers have been addressing for years. Good luck refactoring monolith apps to get there. But definitely worth considering for building new apps from scratch like POCs or MVP.

  • @arlipscomb
    @arlipscomb 3 года назад +2

    Some new terminology but the same challenges and solutions that were used back when the mainframes roamed the earth. Message control systems, distributed transactions, moving the heavy lifting of multi-processing to the OS level. Data persistence can become a real challenge in these systems, as putting everything needed into the messages can be an interesting problem in some cases.

  • @flaguser4196
    @flaguser4196 3 года назад +3

    searched for actor model.
    got model actors instead.

  • @javierolazaran7227
    @javierolazaran7227 3 года назад +3

    Great content as usual. Can you recomend some article or bibliography on the topic?

  • @siyaram2855
    @siyaram2855 2 года назад

    Dave, Why we haven't been able to come up anything after actor model?

  • @marna_li
    @marna_li 2 года назад

    I have not explored any actor framework yet, but to me it is an opportunity to be more object-oriented, if we forget about classes. Actors are objects interacting with other objects through messaging - what OOP was supposed to conceptually be. And they are in certain cases their own processes.
    Actors do limit people who are used to traditional OOP, since you cannot, at least not by default, pass object references between actors. You have to view actors as their own process. So to the jump from OOP to actors is similar to that of jumping from OOP to Functional program: It is a new way to reason about your software and code.

  • @after_alec
    @after_alec 3 года назад +3

    Actor-based smacks so much of Agents and Genservers in Elixir and I am here for it

    • @SaHaRaSquad
      @SaHaRaSquad 3 года назад

      Because Elixir runs on Erlang's VM, which was basically 100% built & tuned for actor-based applications.

  • @redevil5k
    @redevil5k 2 года назад +1

    I've had a conversation recently where I "promoted" this kind of development (I'm not really a developer but I know my way around code - SW QA) and one issue I didn't know how to solve with this architecture is when copying an object is too expensive. This is on a latency critical embedded system (limited processing power and memory). They did a few very cool things to get around this but the design is very complicated and it is hard to onboard new and/or inexperienced people. If you have any recommendations on how to approach this problem, I would more than love to hear it.

  • @DAG_42
    @DAG_42 3 года назад

    So is it incompatible with this model to keep actor state or perhaps even message queue saved to disk? Or would periodic saving be the "snapshot" you mentioned?

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад

      Yes, fine to record the events, common even to do so. Snapshots are a different thing. Think of the steam of events defining the state of an actor. You can recreate that state by replaying all of the events. Periodically, you take a "snapshot" of the state of your system. Now you can load the 'snapshot' and only need to replay events from there, rather than from the beginning of time for the actor.

  • @MrXzxzxc
    @MrXzxzxc 3 года назад +1

    And what about working with database? Does actors share the same instance, or there must be separate db for each actor?

    • @einarnorfjor2937
      @einarnorfjor2937 3 года назад +2

      You create an actor around the database connection 😉

    • @monad_tcp
      @monad_tcp 3 года назад +1

      Actors don't need databases. Instead of using a volatile queue, you use a durable queue that stores the state, and part of the queue itself can be detached as message to another actor by the coordinator (which is really an actor).
      That durable queue can be implemented as a database, but it doesn't sit inside the actor, its just another actor in the system.

    • @monad_tcp
      @monad_tcp 3 года назад

      Converting part of the state of the durable queue as a message to an actor, know what this is ? a database query.

    • @DavidAtTokyo
      @DavidAtTokyo 3 года назад

      Depends which database you want to use but an actor can save its state in a relational database table if you want; have it save its data with an ID unique to the actor. The Akka stuff i am familiar with often is shown using Cassandra as the backing storage.

  • @Frost571
    @Frost571 3 года назад +2

    I had to learn Akka Actors in college. It was very interesting. I hope to work with it someday.

  • @RicardoSilvaTripcall
    @RicardoSilvaTripcall 3 года назад +3

    Mind reader !! I was just reading about the actor model, Elixir and Akka today, it is an interesting approach, could kubernetes or Istio act like a supervisor in this model? Congrats !!!

    • @arminrosic
      @arminrosic 3 года назад

      Elixir/Erlang FTW !!

    • @DavidAtTokyo
      @DavidAtTokyo 3 года назад +1

      Kubernetes is kinda similar at a bigger level of granularity, I think. If a pod dies, ok restart it. Supervisors in the actor model are similar but I think actors in general are going to be smaller things, and actors need to work as a bigger cast so best to clump them together rather than scatter them around before it is necessary to do so for scalability or resilience reasons (which the addressability supports). And actors themselves can do work as well as supervise other actors, whereas kubernetes is just keeping your pods running.

    • @SaHaRaSquad
      @SaHaRaSquad 3 года назад

      Kubernetes is on the infrastructure level while actors apply to the architecture within a software. So for example you'd build a web service backend with an actor-based system (e.g. Erlang) and then use Kubernetes to manage it together with databases etc.

  • @thought-provoker
    @thought-provoker 3 года назад

    Good job.
    Would have needed that video 4 years ago when I suggested exactly that approach to some Java organization which outright dismissed the idea with the statement, "But you won't be able to manage the complexity that happens when actors start to interfere with our monolith which might process some transactions between when an actor receives a request and generates a response."
    Nevermind I just wanted to use actors to model human behaviour of CSR's who were doing the very same thing, just a gazillion times slower.

  • @MarcosVMSoares
    @MarcosVMSoares 3 года назад

    So it's like OTP for elixir and erlang ?

  • @CosasCotidianas
    @CosasCotidianas 3 года назад +1

    New intro, love it ❤️

  • @XfStef
    @XfStef 3 года назад +1

    Would love to know more about how the data fits into this actor driven design.

  • @edwarddejong8025
    @edwarddejong8025 3 года назад +1

    In a panel with Hoare, Hewitt and Armstrong (inventor of Erlang), Armstrong teased Hewitt and Hoare as he was the only one who made a working system. Armstrong did not consider Erlang an actor model programming system. To this day, the Beam runtime which underlies Erlang/Elixir is the only runtime i am aware of that can handle 500k threads without a problem, as each thread has its own heap and stack, so it doesn't get into garbage collection locking problems.

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад +2

      Joe also says "Erlang is probably the only true OO language there is", because of message passing. I met Joe once, very smart and not very interested in fitting into other people's boxes was my impression. In the same response that I am quoting here, he also says they didn't look at actor, they designed a language that worked for the problem, but he didn't reject actor as a model, and the implication was that Erlang was close. Which makes sense to me.

  • @brownhorsesoftware3605
    @brownhorsesoftware3605 2 года назад +1

    The future is now. I've implemented an entirely message-based logistics phone app using Firebase messaging. No database just distributed JSON graphs. My data tool is a text editor. It is totally flexible and ridiculously easy to debug. The time it took to implement was due to the complexity and bugs in the Android life cycle, not the data architecture. The only bit in the cloud is an endpoint to pipe the messages to Firebase.

  • @nirmalyasengupta7714
    @nirmalyasengupta7714 Год назад

    Thanks for bringing up the topic of Actors, Sir.
    I have had the opportunity of building and deploying 3 largish, non-trivial applications (Contest Hosting, Leaderboard Manager, Device status collection/transformation) using Akka & Scala (also Java). The results have been very satisfying to all the stakeholders.
    It is a easily understood model to buils FSM-modeled applications: easily testable and very predictable.
    Lightbend's decision to change the licensing terms have reduced the interest amongst the stakeholders, drastically. Unfortunately.
    I don't know Erlang, but I am exploring similar framework in Rust. I find Actors intuitive.

  • @EricKolotyluk
    @EricKolotyluk 3 года назад +3

    Generally another valuable explanation of Reactive Systems... but...
    You avoided the point of actor mailboxes that are overwhelmed by producers... Given you must have experience with Akka, what do you have to say about Akka Streams, backpressure, flows, pipelines, etc.? Actors are a powerful abstraction, but combined with pipelines backpressure, etc. there is much more to say, and clearly, you are the person to say it...
    Also, Java Project Loom is about to change the world with Virtual Threads, how does that fit into your universe Horatio?
    I am not trying to be critical, I am inviting your technical expertise on things you are able to explain better than most of us...

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад +3

      Back-pressure is more of a "reactive systems" idea than an actor idea I think, but certainly important for managing load. I don't think that actors as a concept changes anything. It doesn't make overloading any more likely than any other system design, and with supervision your options when you are overloaded are easier to see and deal with. Actors are, in my experience THE most efficient way of processing load, so you are less likely to hit bottlenecks, but of course they are always there to hit.
      Actually I haven't used Akka, I am friends with the producers, but my experience with actors is with home-grown approaches.

    • @EricKolotyluk
      @EricKolotyluk 3 года назад

      Wow, I was just under the impression you had used Akka the way you explain things... Anyway, I still hope you will follow up on this topic with ideas such as Akka Streams/Flow, Java Flow, and similar pipeline frameworks. If pipelines are good for CI/CD, shouldn't they also be useful internally as a Reactive Systems Idea, inside of applications, services, etc.?
      Yes, back-pressure is not an Actor Idea, it is a Reactive Systems idea that solved a core problem with Akka Actors. For example, Java Flow does not use Actors, but does implement back-pressure. In my own Akka experience, I always deal with concurrency in an escalating fashion: can I solve a problem using concurrent (non-blocking) data structures; if not, will Futures solve the problem; if not, will Actors solve the problem; if not, will Streams solve the problem; if not; will an Akka cluster solve the problem; etc., where I don't settle for increasing scale of complexity until there is a demonstrable need. However, I do agree these things are the next big thing in software architecture.
      I also think that Java 18 Structured Concurrency is also the next big thing in software architecture the way Structured Programming was the late 1950s.

  • @manutdfanneverwalkalone7774
    @manutdfanneverwalkalone7774 3 года назад

    What is the difference in comparison with microservice architecture ?

  • @someopinion2846
    @someopinion2846 3 года назад +1

    An actor-based system is an object-based that also has subjects.

  • @peterbennett2301
    @peterbennett2301 3 года назад

    To what extent is the actor based model similar to the Pipe and Filter Design Pattern?

  • @dosomething3
    @dosomething3 3 года назад +1

    please discuss actors vis-à-vis tdd.

    • @DavidAtTokyo
      @DavidAtTokyo 3 года назад +2

      It’s a good point, TDD for traditional method calls is different to TDD for working with actors to which you send a message… and it may or may not be designed to send back a response. Still, you can do black box testing for actors. Send an actor a message, and sooner or later you would expect that it would send a message to another actor (which you insert in your TDD) and so one can assert that the intended recipient does receive the message.

  • @queenstownswords
    @queenstownswords 3 года назад

    Can you please compare and contrast the differenced between the actor approach and 'edge' computing?

  • @Cowglow
    @Cowglow 3 года назад +1

    state machines?

  • @antonchernikov8671
    @antonchernikov8671 3 года назад +1

    That's exactly the system we're building right now!

  • @Tekay37
    @Tekay37 3 года назад

    What book would you recommend for taking a deep dive into learning about the actor model? I'd like to develop my own actor model system once so I can understand thoroughly how it works.

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад +1

      You could do worse than look at books about Erlang or Elixir, also There is "Reactive Design Patterns" www.amazon.co.uk/Reactive-Design-Patterns-Roland-Kuhn/dp/1617291803

  • @SolidAir54321
    @SolidAir54321 2 года назад

    I have always been intrigued by the actor model and wanted to use it more. However I write a lot of editor applications---programs that edit some data such as a document. I'm not sure how the actor model can be used for these types of programs. Editing programs seem to be organized around some central collection of data which can be called the document. But in the actor model you would like for actors to have their own data, or state, contained within themselves. I don't think I would want my actor to keep accessing the central document for data that it needs to do its task (do I?). And I don't want each actor to have its own copy of the data, or even a partial copy. There are reasons why you would not want the document data spread around amongst various actors.
    Is there some actor-based way of organizing this? Or is the answer that its just better not to use the actor model at all? But lots of program are editors. It seems the actor model is best suited for server programs and maybe not so much for applications.
    I'd like to find out more advanced ways of designing with the actor model but most information I find is all just introductions to the actor model. Tons of those introductions but nothing more.

    • @ContinuousDelivery
      @ContinuousDelivery  2 года назад

      I have never thought of doing an editor this way, but I think I would start by experimenting with the idea of a hierarchy of contained actors, document composed of paragraphs, with docs and paras being actors, paras, composed of words. Actors for pictured, headers, footers and so on. Not sure if this would work out well, but it is probably my first guess at a place to start experimenting.
      It is quote possible, maybe probable, that actor isn't a good fit for this problem, but I confess that I also don't like the idea of a single store represents the whole document either.

    • @SolidAir54321
      @SolidAir54321 2 года назад

      ​@@ContinuousDelivery Thanks for responding! I don't necessarily think of the "document" or data being a text document though it could be. I just use that name since it most quickly gives you the idea of the type of program. Could be an image. Could be a preset for a musical instrument like a keyboard.
      Some of the types of things you may need to do that makes the distributed data design a bit ugly:
      ---- Save the document to disk. Do you want to have to send a message to all actors to collect their portion of the data? Or have actors save their portion themselves? Then how to control the order things are saved?
      ---- You may want to compare the current edited version of the document to the unedited version to highlight the changes made so far. It's much easier to swap between the old and new versions with the data all in one place rather than distributed amongst actors. This might also be related to an undo feature. Would each actor maintain its own separate undo list?
      ---- I would need a user interface to show the user the current state of the document. If the data is distributed around in various actors, then do I have to ask around different actors to get the data? Or do I have each actor display it's own data? If so, then maybe I need to maintain a structure for the actors just like I would structure the data itself.
      It seems to get unwieldy to have each actor manage a portion of the document. But if you have the document all in one place, then the actors need to grab from the data when they need it. Neither way works very ideally. But then a lot of programs are editing-type programs. I guess the actor model is just not good for this. The bright side is that these programs probably don't need concurrency anyway because they spend most of the time waiting for the user to do something. Not like server processing (which I know nothing about).

  • @BryonLape
    @BryonLape Год назад

    I worked on a Actor based system a few years ago (Akka was used underneath). The Actors were simple and testable, but configuring which Actors were needed to fulfill a certain user request was an absolute crapfest. I've seen several systems since and none of them had a clean way to handle the message patterns.

    • @ContinuousDelivery
      @ContinuousDelivery  Год назад

      Yes, you can do badly designed Actor based systems too. You can always screw up any approach with a poor design.

  • @petersuvara
    @petersuvara 3 года назад

    What’s the difference between MQTT, ECS and Actors.
    Sounds like much of it is purely semantics…
    They run on the same principle right?
    In particular ECS (entity component system) runs the same way, where objects are processed by systems in sequence, in order to optimise for parallelism.

    • @monad_tcp
      @monad_tcp 3 года назад

      It seems its mostly layering and granularity of the implementation. Certainly nothing to do with the concept, but the implementation. (and busswords)

    • @bobbycrosby9765
      @bobbycrosby9765 3 года назад +5

      I've only got experience in Erlang for actor-like systems, so others might vary. But in general, you can think of Actors as objects, with only private state, where method calls are put in a queue, and that queue is processed on the Actor's thread.
      MQTT seems to be pubsub. Actors aren't fundamentally pubsub. You need some kind of reference to an Actor to send it a message. You could use pubsub along with Actors. And you can implement pubsub using Actors. But you don't have to do either.
      ECS isn't Actors either. Because while Actors hold their own state, it usually does things to it in reaction to messages sent to it by Actors outside of it. You could probably implement ECS using Actors, but I'm not sure why you would unless it were your only choice because they don't seem to have much in common.
      Since I only really have Erlang experience here, I can expand upon the role of their Actors. In Erlang, "Actors" are "Processes" - and they are lightweight threads. They are (kinda, but not exactly) the only way to maintain state, do asynchronous programming, synchronize your code (yes, processes do both - a processes processes its mailbox in a single thread, so it acts as a method of synchronization), and isolate GC - each process has its own garbage collector. By convention, you use processes to isolate errors - you build a supervision tree, where each node's job is to deal with child nodes crashing - of course, each node in the supervision tree is a process too.
      Erlang systems are architected as a giant graph of processes, even if your system only runs on a single computer. There is basically no other way to do it given the limitations above, unless you have an extremely simple program. You can have thousands of processes in an Erlang system. I've built some with tens of thousands of processes, all running on a single computer.

  • @upgradeplans777
    @upgradeplans777 3 года назад

    I have prototyped two systems using the actor model, but moved away from it both times. It didn't seem to fit particularly well, but perhaps I just went about it incorrectly?
    One time, we moved the architectural focus towards CRDTs as the building block for distributed coordination. The other time we moved the architectural focus towards a shared transaction log (event sourcing) for distributed coordination.
    I know these concepts are largely independent, and that both can also work in an actor based architecture. But they do have some points of contact, since all of them aim to help with distributed coordination. I think that CRDTs in particular have the potential to fulfill a huge role in cloud/serverless technology. (But to many programmers, the CRDT concept is even more alien than actors.) For the transaction-log/event-sourcing architecture, I don't think it can have as big a role as is often claimed, but I really like it when its constraints fit the problem domain.

    • @xiaokourou
      @xiaokourou 3 года назад

      Were you able to get CRDTs working in a real system? I am very intrigued by them but last time I looked at them they didn't seem production ready. What library are you using

    • @upgradeplans777
      @upgradeplans777 3 года назад +1

      @@xiaokourou Our application was to allow user input on devices that are intermittently offline, where the possible inputs are domain specific. I was surprised at how well we were able to make it work. (maybe I should not have been surprised, since they have a rather solid and proven math foundation.)
      Most CRDT-libraries that I know focus on providing implementations of merge functions, for example aimed at collaborative text-editing, but the merge function is also highly dependent on the application domain. For example, a "collaborative text-editing CRDT for prose" will not work well as a "collaborative text-editing CRDT for sourcecode", and vice versa. (I think one for English will probably not even work well for Chinese.) Our domain model was simple enough to be implemented in relatively straight forward merge functions.
      Apart from the merge functions that I implemented, we were able to use any and all communication libraries to facilitate replication. In my experience, the "conflict free" part of the name really does a whole lot of heavy lifting. I think that cloud solutions of the future should be able to provide plumbing for replication aimed at CRDTs, and also building blocks to easily compose merge functions. I don't think "standard"/"advanced" merge functions (like automerge aims to be, for example) are a good fit for many projects.

    • @xiaokourou
      @xiaokourou 3 года назад

      @@upgradeplans777 thanks for the detailed response. No wonder. I thought it was supposed to be one stop shop with automeege type libraries. Seems like you'd need to write custom merges for it to be perfect. I did a comparitive analysis and some spikes around this about a year or so ago for my passion project. But because my emphasis was a little different (user owned database) in the end I ended up using Textile threaddb instead. Although you can use CRDTs within it

  • @walterlol
    @walterlol 3 года назад

    I don't understand. Isn't this a microservices architecture? Can someone correct me?

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад

      Microservices are not necessarily asynchronous, often not stateful, are independently deployable and aligned with a bounded context. Actors are very different.

  • @FlaviusAspra
    @FlaviusAspra 3 года назад

    We're using Apache nifi. It does not have the sticker "actor" on it, but it has many common principles and ideas.
    I agree that using actor libraries is great for performance, but with nifi we optimize for knowledge sharing, while still having quite a bunch of performance.
    Why do I say knowledge? Because the nifi canvas, the drawing, is the backbone of everything that goes on in the system.
    We still have our own programs, the domain model, etc, not in nifi, but nifi makes the inputs and the outputs of all systems and subsystems visible.

  • @julianwieg
    @julianwieg 2 года назад

    I would like more information on where you buy these T-shirts and if u also wear them at work :)

    • @ContinuousDelivery
      @ContinuousDelivery  2 года назад

      I get most of my T shirts at qwertee.com
      Since COVID I work from home, so yes, I often wear one of these T-shirts.

  • @chrisdams
    @chrisdams 3 года назад

    I inherited a system like what you describe based on jade. As such it seems like it could perhaps be a reasonable approach. I am not sure if I would have chosen that approach if I had build it freshly. The thing that worries me most about it is testability. Okay, one should probably write about 90% of tests as unit tests that involve only one single actor and that is certainly possible, so that is nice (altough in some cases jade also makes that difficult). But when one wants to also have some automated tests that involve multiple actors to see that everything wires together correctly and interacts correctly one is out of luck. It does not seem possible to use normal unit-like tests to do this because the jade framework demands to be in charge. I now started writing a separate testing executable that interacts with the jade application over TCP. (Some of the actors are the ones who communicate with the external world over TCP.) This is really a bit less nice than also being able to have some integration tests together with the unit tests in the junit test suite. It is also quite slow compared to being able to test in one single executable. The whole bunch of actors take quite a bit of time to start up.

    • @allanpetrie7747
      @allanpetrie7747 3 года назад

      Can you not just mock the other actors? Or does Jade make this difficult?

    • @chrisdams
      @chrisdams 3 года назад

      @@allanpetrie7747 Mocking the other actors is possible but does not really address the problem. The thing is that jade and junit just don't seem to like to play nice. For one thing, they both want to provide the main function of the application.

    • @evgenyamorozov
      @evgenyamorozov 3 года назад

      It seems this is not required. Like you have to make sure that any single actor works fine meaning given right or wrong data it produces expected results. If you can prove that, then no matter how many actors you've got, whole system would work as it should.
      Otherwise, such an integration tests would test only infrastructure - network, switches, etc, which I believe is not required.

  • @Tubingonline1
    @Tubingonline1 3 года назад +1

    This actor based architecture sounds very similar to OOP (Object oriented programming) can any one tell me how is it different from OOP?

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад +4

      No inheritance, no specific defined approach to polymorphism, no sync or request/response semantics, so it is quite different really.

    • @Tubingonline1
      @Tubingonline1 3 года назад +1

      @@ContinuousDelivery , Thanks for the reply 👍. Really appreciate this.

  • @benjaminwootton
    @benjaminwootton 3 года назад

    Not sure if its an accident of history or the circles I move in, but nearly every backend system I've worked on since the early 2000s has involved parrallel services reading messages from queues, processing them on a single thread, then sending onto other queues. It's one reason I drifted away from development, because almost every project felt the same. This stuff bubbles up in interest occasionally under the banners of reactive, actors or serverless, but it doesn't feel that new or innovative to me. Am I missing something?

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад +1

      Well, maybe. At that level of reductionism you can say all coding is the same.
      Actors != serverless
      Serverless is "function as a service" and currently, almost entirely, a stateless model. Actors are usually stateful. This has a big difference on how you design systems with them.

    • @LeviRamsey
      @LeviRamsey 3 года назад

      @@ContinuousDelivery on the other hand, it's fairly easy to use the actor model (and it's fundamental dynamic: state + message => next state) to build a system that's essentially serverless (as in you don't care where the system executes or if hardware fails). Akka Serverless (the first word should give a good hint of how much actor model is hiding there) is a good example of this.

  • @RomaineRC
    @RomaineRC 3 года назад

    woah your graphics are looking way better

  • @slr150
    @slr150 3 года назад

    Very useful thanks!

  • @arminrosic
    @arminrosic 3 года назад +1

    Erlang/Elixir/OTP FTW !!!

  • @DictatorOfCandyland
    @DictatorOfCandyland 3 года назад

    I don't see the difference between this and SOA?

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад

      SOA says nothing about messaging, asynchrony or statefulness. This is really quite different.

  • @mohammed-alzard
    @mohammed-alzard 3 года назад

    Very interesting speech, thank you very much.

  • @iham1313
    @iham1313 3 года назад +1

    seams like domain driven, microservice based, functional and modular

  • @coder8515
    @coder8515 3 года назад

    Fascinating

  • @lllevokelll
    @lllevokelll 3 года назад

    This being the next being thing seems in distinct competition with things like Lambdas being 'good enough' for the majority of enterprise developers the majority of the time. (For every 1 dev working on a twitter-like arch/project, there are 5+ working on enterprise software, monoliths, etc.) It's brilliant if you are building something in a highly concurrent / stateless space, though, sure. Thought provoking content. Seem challenging to apply in the catching fire in the enterprise ecosystem sense. The average hypothetical enterprise seems to have their hands full at the moment trying to standardize their CI/CD pipeline jungle down to a crisp and mature standard set of frameworks and managed pipelines.

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад

      Actors aren't stateless, that is why they are good for different problems to Lambdas, and more generally applicable.

    • @lllevokelll
      @lllevokelll 3 года назад

      @@ContinuousDelivery Between attaching efs file systems to lambdas, using lambdas as step function state machines, saving lambda data into redis, people have been drifting into wanting/making lambdas be more like actors, and I let them become a bit semantically blurred in my head. Thanks for the clarity.

  • @ssssssstssssssss
    @ssssssstssssssss 3 года назад

    We'll start seeing learnable architectures become applicable at some point. That's not an architecture per se, but I'd say it'll be a "big thing in architecture".

  • @Sergio_Loureiro
    @Sergio_Loureiro 3 года назад

    Now I began to wonder if modern sandboxed multi process internet browsers can be seen as these multi-actor systems or not.

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад

      I don't see the likeness. Not single-threaded, not asynch. I am sure that you could build a browser this way, but most are not as far as I am aware.

    • @naythaniel
      @naythaniel 3 года назад

      @@ContinuousDelivery I feel like maybe he means web workers (supported by all modern browsers) - which actually do appear to use the actor model, effectively by definition.

  • @renatocron
    @renatocron 3 года назад

    cloudflare durable objects are kinda like serverless stateful services

  • @jamstawildman
    @jamstawildman 3 года назад

    Interesting stuff.

  • @kamertonaudiophileplayer847
    @kamertonaudiophileplayer847 2 года назад

    A message can be highly complex and generally require a significant resource just to keep it. So, what is a solution? Look further, what happen with a message? Finally it is stored somehow. So it is the clue.

  • @mckengineer5727
    @mckengineer5727 3 года назад

    Pretty much all the agile s/w methods and architecture thinking comes from a business IBM system history. Anybody who has dealt with real-time process control and other event based systems get this…I think a simple read of the basic wiki page on DCS is a good starting point en.m.wikipedia.org/wiki/Distributed_control_system

  • @ReedoTV
    @ReedoTV 3 года назад

    Actix is a great actor framework if you happen to be using Rust

  • @temmihoo
    @temmihoo 3 года назад

    Not to dismiss actors in any way, the message passing nature of actor infrastructure is something that is completely missing from most OOP implementations, which is a biiiiig shame.
    Reading stuff written about OOP from the original sources, message passing was considered hugely important and inheritance is... Well. It isn't even mentioned. Then later on, in C++ and everything after that, OOP centralises around classes, methods and inheritance. Luckily, most use class based inheritance from cathegory theory. Many of these latter day OOP systems don't even have message passing except as a third party optional module and most definitely not part of the core infrastructure.

    • @evgenyamorozov
      @evgenyamorozov 3 года назад

      I believe calling a method of an object is similar to sending a message to that object. At least I've heard such an interpretation and it makes sense to me.

  • @emdadgar_official
    @emdadgar_official 3 года назад

    rust ... how is it ? :)

  • @freedom_aint_free
    @freedom_aint_free 3 года назад

    To me the future is functional, languages like Haskell will inherited the earth !

  • @Oswee
    @Oswee 3 года назад

    While it is quite simple idea, it is still too complex for the mainstream developers. It involves quite significant investments into infrastructure before seeing any benefits of this model.

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад +2

      Not really. You can run actor systems on a single system, no problem.

    • @DavidAtTokyo
      @DavidAtTokyo 3 года назад +3

      I spend lots of time in my job dealing with concurrency issues so I’d rather argue the opposite, that for mainstream developers the standard database centric approach to building applications is too complicated for them and we’d probably be in a better spot if programmers had all been indoctrinated with the actor model. Different challenges though no doubt, but what Dave said in the video really captured the essence.

  • @Siderite
    @Siderite 3 года назад

    I always thought actors was a good idea, I just never got work anywhere where they considered it as a solution.

  • @mytech6779
    @mytech6779 3 года назад

    Too much abstraction, can't loose sight of the physical electric signals and expect much efficiency. Yes abstraction can help organize complex code for correct outputs for given inputs, but the purpose of concurrency is efficient use of hardware so without efficiency I could not claim that the code is correctly executed despite having the expected final output. From this perspective I would say that the speed of execution is a [meta?] component of a "correct" final result.

  • @siyaram2855
    @siyaram2855 2 года назад

    Why is it the next big things? Isn't it available from 80s?

    • @ContinuousDelivery
      @ContinuousDelivery  2 года назад

      Yes, but all ideas were available from the 1980's 🤣🤣
      More seriously, I think that the difference is that the time may be coming for actor based systems. This approach has a lot going for it in a modern, cloud, context.
      It allows cloud providers to raise the bar of abstraction for cloud based systems, isolating the logic of the system from the accidental complexity that makes up so much of software.

  • @SaudBako
    @SaudBako Год назад

    All of this is just Alan Kay's definition of OOP.

  • @gregoliver975
    @gregoliver975 3 года назад +1

    I was really excited about this until you said the word Java, then my interest went away. Java is the reason why everything in the world runs at half speed and why we've just had to patch half the worlds financial apps and apache across the board. There are so many different modern languages to use - using Java is just silly.

    • @ContinuousDelivery
      @ContinuousDelivery  3 года назад +4

      Obviously it is your choice which languages you like or dislike, but your argument about performance is simply wrong. At the absolute limits C++ gives you more control over some primitives for certain aspects of writing non-blocking concurrent code, but beyond that to call Java slow is simply wrong.
      I am not a Java fanboy, I am fairly tech agnostic these days, but Java is a good choice for high performance systems, better than things like C or C++ for many scenarios.
      I was involved in writing world-class trading systems, using Java (amongst other languages). The JVM is one of the most highly developed (in terms of person-years of effort) pieces of software on the planet. Ideas like runtime compilation and optimisation mean that code running on a JVM is more optimised than the output of a statically compiled and optimised language. I have worked on trading systems written in C++ that were slower than similar systems written in Java for this reason.
      None of this stops bad programmers writing bad code in any language. That is a much bigger problem than language choice (within limits of course - you don't pick Python or Javascript for high-performance).

  • @brandonpearman9218
    @brandonpearman9218 3 года назад

    Like actor system, hate serverless

  • @AleksandarIvanov69
    @AleksandarIvanov69 3 года назад

    Tl;Dr: microservice everything :)

  • @llothar68
    @llothar68 3 года назад

    The more i hear about even more complex systems the less i'm interested in. Because only very few corporations will do this and i'm sure never be hired by them. In the meantime i'm still working alone and trying to find out how to spawn native linux processes on android systems with the new workmanager API.

  • @HANU8
    @HANU8 3 года назад +1

    What is the difference between this and Alan Kay's REAL object-oriented programming ?

    • @evgenyamorozov
      @evgenyamorozov 3 года назад +1

      None... recently (I believe there is a thread on reddit) Alan Kay said that he was mistaken and he should have called this thing MOP - Message Oriented Programming.

  • @sab611
    @sab611 3 года назад

    Sounds like functional programming.

  • @coderider3022
    @coderider3022 3 года назад

    Azure functions , durable functions and AWS equiv are where the everyday developer should be moving to.

  • @somersmatthews2749
    @somersmatthews2749 3 года назад

    Haskell

  • @cassianofranco3082
    @cassianofranco3082 2 года назад

    Looks like OOP