I am truly excited to talk to one of Typesafe's founders and CTO, Jonas Bonér. He's got thoughts on why actors are essentially microservices, and how communication protocols are important both for your Reactive systems and your love life.
Tonya Rae Moore: Hello, and welcome to our third Typesafe AMA podcast with our experts. My name is Tonya Rae Moore and I am a Product Marketing Specialist with Typesafe. I write some of our blogs, I record or our webinars, I now do this podcast and, in general, I like talking about our reactive platform. My first question for today's guest who I'm super excited about is, should I pronounce it [JO-nas] or [YO-nas]?
Jonas Bonér: I don't really know myself. I'm so used to the American pronunciation.
Tonya Rae Moore: With a hard J?
Jonas Bonér: With a [U-nus], but [JO-nas] is fine, I guess.
Tonya Rae Moore: How about [yo-NUS]? Is that better?
Jonas Bonér: No, that's actually worse.
Tonya Rae Moore: Damn it! Okay. Well, then, I'm talking to Jonas Bonér who is one of our founders and CTO over at Typesafe who I haven't had much of a chance to speak with before, so I'm really excited to hear what you have to say today. So Jonas, I was actually kind of researching you before we started this podcast. And I was looking at your LinkedIn profile next to Martin Odersky's LinkedIn profile. And I was amazed at how a Java, a JVM guy, a Java Champion who started and invented the Akka project met up with Martin, a Scala guy, and made a company together. Could you tell us a little bit about your background, and how you two guys got together to found Typesafe?
Jonas Bonér: Sure. Yeah, I started out as a JEE consultant. J2EE as it was called back them. And I worked a few years before I got really interested in aspect-oriented programming. And that's when I first ever met Dean Wampler and some other people in the industry. And that was mainly when I got really passionate about Open Source. So I started this Open Source project with AspectWerkz. It was a runtime and compilier for AOP that was later merged with AspectJ. During that time I worked for BEA Systems at the JRockit team here in Stockholm.
Tonya Rae Moore: Oh, I didn't know you were on JRockit. That's a cool place. That's a cool company.
Jonas Bonér: Yeah. Yeah, there was a lot of great people doing really great stuff. It was very rewarding working there.
Then, I joined a smaller startup called Terracotta. They did some JVM-level clustering, as they call it or as we called it back then. And that's when I really got in to distributed systems, and resilient software, and scaling, and stuff like that. So I worked there for a while and then, I left to start a startup in the financing industry that didn't go that well, but during that period I somehow sort of lost faith a little bit in this unit. That way the JEE industry dealt with writing scalable systems or resilient systems. These so-called best practices didn't really work that well in practice so I started researching other things. And I sort of rediscovered Erlang. Something that I'd been tinkering around with back in university and kept an eye on, but never really tried. And I was really blown away by their approach to resiliency and then, I really started to enjoy working with the actor model. And I decided to port that over to the JVM (which became Akka), and when I was starting this startup in the finance industry, I decided to write the system in Scala.
So these things were happening concurrently. I continued working on Akka, it got some traction, and Martin Odersky, the founder of Scala, reached out to me at a conference in London, and invited me out for coffee to talk about the work I had done. That kicked off a conversation that we kept going for a couple of years. And after a while it was sort of clear that it would be great to actually merge our two companies and join efforts. Martin had a company called Scala Solutions focusing on Scala solely. And I had kicked off a company around Akka called Scalable Solutions. So we joined forces, and then, started Typesafe. So that's essentially....
Tonya Rae Moore: That's really interesting because when I did my podcast with Konrad over at JavaOne, we were talking about how much we enjoyed this company because one of the principles is that we do some stuff really well, but we don't do everything really well. So let's partner, let's team up, let's make a company where we together can bring the best possible solution to our customers. So it's interesting to hear that you and Martin actually founded the whole company on that premise.
Jonas Bonér: Yeah.
Tonya Rae Moore: So one of the things that we've been having a lot of internal Typesafe chatter about is microservices, like the word "microservices" itself. Where do you stand on that?
Jonas Bonér: Yeah, I think it's very interesting. I learned about the word microservices probably about three years ago or something, perhaps a little bit more. I remember when I heard the word and sort of understood what people meant when they said microservice - some people sort of think it's like SOA done again, or SOA done right. Well, that's one way of looking at it. But for me, in coming from an actor-based background, it was really clear that these two have a lot of similarities. In a way, all Akka-based systems are essentially microservices.
Tonya Rae Moore: This is one of the things I wanted to talk about is that's what I keep hearing in this internal chatter is actors are microservices.
Jonas Bonér: Yeah, they share a lot of similar traits, I think. Strikingly many, I believe. In a way I think that the microservices are like actors that are living at the edge of the system. Interfacing with the user, interfacing with other systems. So I think that's really true, that's the way I look at it.
Tonya Rae Moore: Okay, well, let's back up a second for people who are just grasping. So let's give a short description of actors, and what they're about, and the similarities with microservices.
Jonas Bonér: Sure. So actors were invented, or discovered by, if you may say, by Carl Hewitt all the way back in the early '70s. In 1973 he wrote the first paper on it. The essence of the actor model is that it's a fundamental model of computation, similar to lambda calculus, whose whole idea is that you have these isolated often stateful autonomous processes that are communicating through asynchronous communication - what was unique was that all communication was assumed to be asynchronous. These actors, they communicate through stable addresses, and this level of indirection means these addresses are decoupled from their runtime instance.They are decoupled in time, meaning that they allow concurrency on the same thread through interleaving, or concurrency on multiple threads. They also allow being decoupled in space, and I think that's where a lot of interesting things come in to play because that allows distribution, and elasticity, and mobility, and all these things that we need today.
And in a way, the way I view it is that Carl Hewitt was really ahead of his time when he came up with this. It's taken a while for these ideas to take root, but today I think the world has caught up with his thinking. Now, we have multicore processors, cloud computing, mobile devices, Internet of Things as the norm. And all systems are essentially distributed systems. This has fundamentally changed our industry. And I think we really need a more solid foundation to model these hard problems, other models that embody the reactive principles. The principles of being responsive, resilient, and elastic, the ones that are defined in the Reactive Manifesto. I find actors as the best implementation of these principles, and the best foundation to build these types of systems on, that I have used, at least.
Tonya Rae Moore: And it sounds like you've tried quite a few.
Jonas Bonér: Yeah, some.
Tonya Rae Moore: Okay, well, let's stop for a second because you used a lot of words here so I'm trying to make sure that I understand all of this. So you were outlining essential traits of actors. So what were they again? Can you go through them? Can you name them and go through them a little bit?
Jonas Bonér: Yeah, sure. So when I have been thinking about these things and how I view microservices coming from an actor model perspective I think it's clear that they do share a lot of things. And they all have a lot of traits in common. So if I should take some time, and go through what I mean by that, covering them one by one then.
I believe that the most important thing is that they both allow you to do mutual isolation between the components. This really allows the component to fail in isolation which is extremely important. By failing in isolation we are containing the failure. That means that you can avoid things like cascading failures. And these type of failures that you get when you have strong coupling either through synchronous communication or by other means.
So isolation and containment of failure means that you actually can have a healthy context outside the failed component that can sit there and observe the failure and act upon it. Restart the component, report what happened or manage it in some other way. And that is what we, in the actor world call supervision. This allows you to write self-healing systems, where they'll repair themselves and can be truly resilient.
But isolation also gives you the possibility to do a lot of simplified operations by upgrading the system in isolation component by component, instead of the whole monolith at the same time. It also makes it easier to detect what is going wrong. Monitoring the system and debugging certain specific components. It makes it easier to test the system, I believe. You can test each component individually. And also, scale it independently. Certain services you might need to run 10 instances of while others are finely tuned. If they're all baked together in a monolith then that makes it really hard to actually scale out the pieces that need it. So I think that's really one of the key things.
Another thing is that they all act autonomously. Since they're completely isolated they have to take decisions independently, and they have to act independently. They need to cooperate and coordinate with others to solve problems. That's very much how actors work, and I also think in the very same way microservices work. Carl Hewitt said one time that one actor is no actor. Actors always come in systems. They collaborate. And I really believe that that is also true for microservices.
So another also very important trait is that microservices, they really adhere to the Single Responsibility Principle (SRP). This is also very much how I think about actors. Actors should do one thing and one thing well. The benefits of that is, of course, that business responsibilities are not tangled. I think this makes it also easier to scale and to manage the system, and also easier to understand and evolve the code. It's really clear who's responsible for what.
And another also important thing is in my opinion, some people might disagree in the context of microservices, but what I've sort of taken with me from the actor way of thinking is that each one of these components should own its state exclusively. Both actors and microservices, they have a true encapsulation of both state and behavior. And they both can be sort of viewed as a bounded contex, in the domain-driven design vocabulary. And I think one of the most important things that you have is that they really have to own the state exclusively.
Tonya Rae Moore: I'm sorry, I'm going to interrupt you for a second. Why would exclusive state be debated in the microservices community?
Jonas Bonér: I don't know if it will be debated, but I've seen microservices-based solutions that were actually working with one single, common database that all of them talk to, which means that unless you actually make sure that you do things right, partition things right and define the schema correctly, it can allow one microservice to call in to the server the persistence of another one, and I think that's extremely dangerous. In actors it's really impossible because they are completely isolated, and you often use something like event logging to store this data - which I believe that is actually a preferred method of managing state for microservices in many situations, but in others the SQL store might be appropriate.
Tonya Rae Moore: Okay, thanks for clearing that up for me.
Jonas Bonér: Yeah, no worries. So the way I view it is that since they are completely isolated you have to ask a component - a microservice or an actor - for its state, and then you get immutable facts back. It means that the component that you ask is publishing the facts at its own will. You can't really force it. You can't peek in to its internal state. But you just have to ask it, and hopefully, you get a reasonable response back. I found this extremely important, a solid foundation for really being able to scale and write resilient systems.
Another important thing that I probably should have started with is that all of this requires asynchronous communication. True isolation, true exclusive state, requires you to base your whole server, the way you design your system on message-driven communication. Truly asynchronous communication. It is the fundamental principle of Reactive systems, and the basis for resilience, elasticity, and responsiveness. It gives you this asynchronous boundry between two components, allowing it to live in different spaces, so to speak. And this means that one component can actually live in-process, but it can also live outside in another data center or node, which gives a lot of freedom for the operations guy to manage the topology of the system. I also believe that asynchronous communication actually encourages you to really get real about defining right communication protocol: a well-defined, explicit protocol.
I think we talk way too little about protocol. It's usually something that we try to address by just winging it. But I think the protocols are essential to how the system is functioning. Protocols are really all about communication; it's the essence of communication. The key to all good communication and a long-lasting, mutually beneficial relationship, as my wife would probably agree with, is actually having explicit communication, and understand what the other person is saying. And I think you should be explicit with both what you publish and you do accept as a component. And also, how this communication protocol is evolved, versioning and things like that. This means that you can actually manage communication across time as you evolve the system, as you upgrade components and so on. And this is really something that needs to be thought through from day one.
Tonya Rae Moore: I wanted to just say that I've noticed that in our communications we talk a lot more about protocols than I have in any other company that I've worked for. Communication protocols. And I love that you tied that in to relationship advice. Maybe I'll do a podcast with your wife next.
Jonas Bonér: Yeah, I sort of learned the hard way to appreciate well-defined protocols that you put some love in to. To not just wing it. And the nice thing with asynchronous communication and distributed systems in general is that you can't just go by just faking it, because you really need to fully embrace good protocol design to have a distributed system work, at least over time. Even though asynchronous communication is harder, and it forces you to think in a different way, and that can be challenging, often it actually has some good side effects. And forcing you to think about communication protocols is one of them, I think.
Tonya Rae Moore: I was just going to say that's one of the things that I've been learning since I've come to Typesafe is asynchronous communication and its protocols. They do take more time sometimes. You have to ramp up to it, but it's so worth it at the end. It makes it so much easier and so much better in the end result.
Jonas Bonér: Absolutely.
Tonya Rae Moore: Have you ever thought about becoming a developer lonely hearts columnist?
Jonas Bonér: [Laughter] No, I've never thought of that.
Tonya Rae Moore: Maybe that will be next for you.
Jonas Bonér: Perhaps, yeah. I should think about my future, so thanks for that advice.
Tonya Rae Moore: Yeah, I know that you're struggling right now. Okay, so we went over the traits, and you touched on--
Jonas Bonér: Sorry, but there was one thing that I think is worth mentioning as well. And this is one of the things that I find most important in the actor way of thinking, the actor model, and that is distribution and location transparency. This is perhaps something that the microservices community hasn't fully embraced as much, but I'd like to say that it's really part of the way I view microservices. Location transparency is really what allows you to distribute a problem in space, and what enables elasticity, one of the core traits in the Reactive Manifesto. It's enabled through this idea that I've already talked about, that you have addresses that are fully decoupled from its runtime instance. If the client then is using that address it can be an hostname and port if it's a microservice, or it can be actor ActorRef if it's an actor. If you have this decoupling it allows you to have your address represent one actor or one microservice running somewhere, or it can represent five of them, proxied, load-balanced or replicated for resilience, in which one is active, but you have four passive ones that are all ready to take over in case of failure. This gives the Operations team so much power to scale the system in all dimensions. I think that it can't be underestimated. It gives you this unified model for both scaling up and out, multi-core or multiple servers. It doesn't matter, it's all the same.
Instead - as we often see - it forces you to use different tools for scaling up and out. For example: scaling out the system on multiple cores using threads and locks, but when they want to scale out the system on multiple nodes then they are bringing in an ESB or Message Bus to turn on clustering in the app server or do all kinds of crazy stuff. While if you have this decoupling that I think both the microservices and actors give you, it really allows you to have a single unified programming model. A single way of thinking regardless of how you want to scale, or in which dimension you want to scale in. I think that gives you a lot of power, and it also makes it so much easier to understand the system you just wrote.
Tonya Rae Moore: I may cut this out of the podcast, but I heard something the other day that I did not understand as someone who is not a developer. And I was going to ping Konrad about it, but since I've got you...heeeheee...I'm just going to ask you. Someone said to me the other day that it's harder to scale down than it is to scale up. Is that true?
Jonas Bonér: It can be if you use the wrong abstractions, I guess. But if you use the right abstraction, if you use the type of abstractions I just outlined, and you have true location transparency then, it shouldn't be really any harder, I believe. You, of course, need a good Operations management tool to do that, even if your programming model and your runtime is up for the job, you still need good tools on the operations side to take advantage of that. So historically, yes, I would say so. But, my experience with the actor model and basing it on such a foundation where there's really no distinction between scaling up and scaling out, or as I said earlier, distribution in time or distribution in space, then it shouldn't be any harder. So, if it is, then you're using the wrong tools.
Tonya Rae Moore: Which leads me in to the tie-in, but before I hit that I just wanted to outline to make sure that everybody understands the essential traits. So they are isolation, autonomy, single responsibility, exclusive state, asynchronous communication, explicit communication protocols, which was my favorite part, and distribution and location transparency. And these are all of the things that actors have in common with microservices, correct?
Jonas Bonér: Yeah, at least the way I view them. Microservices can be probably implemented in a gazillion ways. But the way I view it and the way I think microservices should be implemented, this is the way. Yes.
Tonya Rae Moore: And this is how we're implementing everything in Reactive Platform?
Jonas Bonér: Yeah, of course. Typesafe Reactive Platform has a foundation in Akka, and since that's what we all live and breathe it's natural for us to think about the world like this. As you know, customers have used this platform Akka and Play, to build microservices-based apps for years. Actually, even before I knew that they were called microservices-based apps. So I really believe that they do have a lot in common.
Tonya Rae Moore: Yeah, Konrad and I were talking at JavaOne about how we were microservices before microservices was cool. And I think that should be our next t-shirt.
Jonas Bonér: Yeah, perhaps. I think we were at least microservices before I knew about it. But, I don't know how much that says, though.
Tonya Rae Moore: It might say a fair amount. This has been great, and I have learned a lot. I really appreciate you taking the time on a Friday afternoon to talk to me.
Jonas Bonér: Yeah, thanks a lot. It was my pleasure. Sorry if I was rambling too much.
Tonya Rae Moore: No, I learned a ton, and I hope everyone else did, too. So to wrap it up you can check out www.typesafe.com with more information about Akka and our Reactive Platform. You can tweet at @jobner for Jonas. @tonyaraemoore for me @typesafe for Typesafe. I will also be checking #typesafepodcast for feedback and suggestions on improvements. And thanks to my very special guest, Jonas Bonér who I will not try and mangle his name again. And I hope to see you on the road soon, if not in the San Francisco office before then. Thank to everyone who listened. Thanks, Jonas.
Jonas Bonér: Yeah, thank you. Bye-bye.
