The Next Big Thing In Software Architecture

a few years ago i was involved in writing something called the reactive manifesto this was in part based on the experience of my team building a financial exchange and coming up with what was to us a fairly innovative approach to its architecture this was the nicest big system that i've ever worked on or seen i've spoken about aspects of this before but the architecture that we ended up with was really close to a specialized form of an actor-based system it's a weird name for an approach and i think that it's not as widely known as perhaps it should be but i think that perhaps the time for active-based systems might be coming again this is an interestingly different way to think about problems and for many classes of systems it solves a lot of otherwise very difficult problems so what are actors and how do they help us to build great systems [Music] hi i'm dave farley of continuous delivery welcome to my channel and if you haven't been here before please do hit subscribe and if you enjoy the content today hit like as well i'd like to thank swim the producers of the actorbase runtime framework of the same name for sponsoring this video many of today's real-world software-as-a-service applications are event driven actor-based applications analyzing huge amounts of data from real-time event sources swim is an open source java runtime which lets you easily create an actor for each event source each actor continuously analyzes events and streams its insights to other actors that link to it swim applications run at cpu and memory speed so millions of times faster than disk and are resilient and scalable go to swimoes.org to learn more and there's a link in the description below if you'd like to explore the idea of organizing systems around collections of actors is a surprisingly old one it was first mentioned in 1973 and like lots of ideas in computer science it was first thought of in the context of ai research at the time the ai link though i think is a bit confusing because this is really quite a low-level kind of thing in some ways actors are primarily an approach to dealing with concurrency they are simple but a powerfully effective way of organizing our work that allows us to almost effortlessly parallelize it but they do need us to think a little differently about how we organize our code to achieve that as i've said many times here concurrency is one of the really difficult problems in software it's the root of nearly everything that makes our job genuinely difficult when we have information in multiple places which cop is correct which one is the most up to date if i change my copy how do we change yours too how do we join up the work that your code is doing with mine these are the problems at the heart of computing actually it goes deeper than that these are the problems at the heart of dealing with information in any form all of these problems are just as relevant to information on bits of paper as to the contents of our database databases or services actors don't solve all of these problems automatically but they allow us to write code that can ignore them to a large extent or at least reduce their impact and that's quite a big win so what is an actor technically an actor is a universal primitive for concurrent computation in practice what this means is that an actor is a single threaded piece of code information comes into an actor is processed on a single thread and then information is sent out from the actor again if you want an actor to do two things you wait for it to complete the first before it's allowed to start work on the second these inputs and outputs are described as messages and these messages are the only communication that's allowed no shared data no backdoor access all information flows in to and out of an actor as a message if a message arrives while the actor is busy the message is queued up until the actor's ready to work on it for some implementations these cues are sometimes called an actor's mailbox this is a all lovely and simple an actor waits for a message does something useful and then transmit another message in response notice i haven't said anything about how the actor works internally except that from the outside the input processing and output happen in sequence in response to a message an actor can do three things create more actors send messages to other actors or designate what to do with the next message when it arrives mostly this last one means it changes the state of the actor so yes actors are can be and are usually stateful the really nice thing about this as a programming model is that a single actor processing a single message is a deterministic thing given a starting state and a message we'll always end up with the same result it's single threaded after all so these things are incredibly testable so what's the difference between a method or function call and a message well there's no return value for a message the response from of an actor to a message is one or more of the things that i've already mentioned a changing state another message or more actors technically the important point here is that in sending a message the sender does not transfer the thread of execution onto the receiver this seemingly simple technical step has a lot of really nice consequences it means that an actor can send a message and then continue doing useful work without waiting for any kind of response it also means that a different actor can handle the response to the one that initiated the action if needed actors are decoupled from one another in both time and location the location part is really interesting too the computer science of actors talks about their addressability but addressability doesn't necessarily mean fixed addressing this is rather like the difference between an old landline style phone and what we call a phone now in the old days if you called somebody you knew where they were because where they were in space because they were answering the phone the route to their phone was fixed by the landline now when you call someone they could be anywhere actors need a way to communicate and something needs to do the same job as the mobile phone network to locate them but that could be fixed like the landline or like the mobile phone system entirely dynamic it can also be point to point or broadcast if the addressing is based on topics that actors are interested in for example like publish and subscribe messaging then the actors can join and leave conversations when they need to so now we have this potentially massively parallel decoupled decentralized time and location independent model for computing all based on the simplest of simple programming models take some input process it send some output listen for a message process it and respond in any of those three ways oh and there's no shared data anywhere no concurrency primitives like locks or synchronization blocks at least non-visible to the actor there may be some cleverness in the infrastructure but from the actors perspective no shared state of any kind as i said originally this was designed as a model for low-level concurrency later developments like erlang introduced more ideas ideas like the supervision systems once our actors are decoupled in time errors don't automatically propagate this is a good thing it means that we can deal with them differently and depending on the nature of the error if there's a problem processing a message but the actor is still fine then it could send a new message indicating the error or perhaps create a new actor to deal with it if the actor is broken because of some unexpected problem of some kind this is a different kind of failure and in this case we could designate a supervisor whose job it is to monitor what's going on and decide what to do when things go wrong it could stop a stored process or start a new one for example there are some small differences but this is very similar to the reactive systems that are described in the reactive manifesto all this stuff adds up to a the most robust programming model for programming complex distributed systems that we have this is how things like telecoms exchanges work the ericsson class 5 voice switch works exactly in this way built with erlang and actor-based programming language this is also how my team built one of the world's highest performance financial exchanges a few years ago the actor model is widely used in big complex systems that value reliability high performance or the elegantly simple programming model highly i think that this approach has some really interesting properties of value far beyond esoteric use cases actors are already used in a lot of mainstream applications the xbox game titanfall for example uses actors based on the orleans framework and twitter is built on akka another actor-based framework but still i think it's less widely thought of than perhaps it should be let's just recap that list of properties that i mentioned earlier we have a massively parallel decoupled decentralized time and location independent model for computing here all based on the simplest of programming models does that sound familiar at all doesn't that rather sound like the sort of thing that we might want to use the cloud for but with the benefit of this simple programming model we are moving or have moved in the direction of a much more decentralized world of computing we create small pieces of code that respond to events and process them serverless functions tied to an event stream for example web services responding to requests in implementation most of these are still tied to a request response kind of model for computing and certainly models of computing like the function as a service of serverless are often seen as the best implemented as stateless systems but what if they weren't what if these things were all actors well the first game would be that that we wouldn't really care where the processing took place we could leave that as a problem for the messaging infrastructure if my actor needed to talk to yours i could write the code so that i sent send a message that you receive if your actor was running on the same machine as mine the message could be a local call that the infrastructure would detect the fact that it was local and communicate using local technologies to make that fast and efficient and simple on the other hand if your actor was running somewhere else the message remains the same from my point of view when i send it and from your point of view when you receive it but the infrastructure and then communicates across the wide area network and gets the information to you sometime later and everything still works as before so the actors remain are both unchanged this is a problem for the communications infrastructure rather like your mobile phone answering my call whether you're sitting next to me or on the opposite side of the planet i've spoken here before in the context of reactive systems about how systems like this achieve a fantastic separation between the essential complexity of our systems and their accidental complexity this seems to me like a great tool a great opportunity for the creators of the public cloud systems that we increasingly depend upon they could raise the level of abstraction to further generalize the technical features of our systems while allowing actor builders us to more clearly focus on the essential job at hand writing code that solves the problems for our users or writing code that our users enjoy while not needing to worry too much about threads and processes locks clustering or even persistence at the point when we write and test our actors you can take this idea a very long way when we built our exchange our services knew nothing about our infrastructure nothing there was no compromise in the design of the interface to one of our services no additional functions were demanded by the infrastructure all of the accidental complexity of message delivery message persistence clustering failover load balancing sharing of data and so on were external to the services themselves as ever there are costs to this model perhaps the most complex one is how do you migrate state if my actor is stateful and i want to change its internal representation how do i do that if my messages are assured in delivery that means that their pistol persisted somewhere so if i want to change the structure of a message how do i do that and the other problem is if i need to coordinate the actions of multiple actors in some way to ensure that their data is consistent then how do we do that all of these are solved problems and usually supported in some way by the infrastructure provided by your infrastructure supplier snapshotting and replay for the first example message migration or phased interface changes for the second perhaps and distributed consensus protocols like raft for the third my crystal ball is no clearer than yours so i don't know if the cloud builders will take this route there's been some talk recently of stateful serverless approaches and provision of those kinds of services that's they sound very intriguing but they are pretty early on in the stages of development so far certainly with my bias these may be interpreted as representing an actor-based approach but i think the actors are a fascinating approach to computing in general and provide us with a powerful but simple model allowing us to build genuinely complex but extremely robust systems while focusing primarily on the problem that's in front of us rather than the technical plumbing actors do this better than any other approach that i know of they allow us to focus on the essential parts of the problem that we're working on while deferring and often generalizing the more technical bits i think that this is a very strong candidate for an even more widely used programming model in the future it's certainly one to watch thank you very much for watching [Music]

Channel: Continuous Delivery

Views: 5,623

Keywords: software architecture, software architect, software architecture patterns, actor based model, actor model, actor model talks, concurrent computing, computer science, continuous delivery, devops, Dave Farley, software development, software engineering

Id: -IZlOPciSl0

Length: 16min 34sec (994 seconds)

Published: Wed Dec 15 2021