FikaAI Interview with Ben Hindman
Recording: FikaAI Interview with Ben Hindman
Hello everybody. I'm Alexi Kraov, the founder and organizer of AI by the Bay, the longest running deepest technical conference coming back in November by the Bay. And here we are at the Linux Foundation member summit in beautiful Napa with Ben Hund. Hey Lexi, the founder of Reboot. Yeah, reboot.dev. And we have a long history going back. So, I'll let Ben tell us a little bit about his career in software and what he was speaking about at the Linux Foundation Member Summit. Sure
Awesome. Thanks, Alexi. Thanks for having me. Yeah. So, yeah, I started my career um uh building uh Apache MSOS first at Berkeley um which was one of the first container orchestrators. Um in fact, we didn't even call it that when we first came out with it. It was just a cluster manager. before container orchestrator was a term that that was was was created
Um and uh he was one of the first container orchestrators really helped ignite uh uh a movement around containers and and running software that way and and and building out applications by microservices. Mhm. And what I talked about here um uh uh I I I gave a keynote yesterday about why microservices have uh have failed us. Yes. Um and uh and and you know the top three things that in my experience since we first built MSOS which was back in 2009 so long time ago um uh you know what we that we we stopped thinking a little too early when we first built microservices. Uh sorry when we first were doing container orchestration we should have thought maybe a little bit longer uh about what was going to be the best way for application developers to build their apps on top of container orchestrators. And really the top three things that I uh noticed working with enterprises that they struggled with, right? And uh I remember vividly uh I started running the subscal and then eventually it became the scale by the bake conference and I talked to Mario Ericson from then Twitter and he told me about all these amazing methods, right? how you just like schedule jobs and they had this manifest. They define what resources they need and it sounded then as magic
Yeah. And it sounded as the right way to do things, right? And then Twitter went on to basically run everything on meos and I remember like there were a lot of messes usages in Apple, right? And like I think some point like there were masses classes running on cruise ships, right? And all kind of stuff, right? So so you Yeah. like you you basically uh coined the term orchestration before the AI agent orchestration frameworks of two months ago. It's been right it's been going on so and and your your talk was about basically microservices are dead long live microservices right so what why people and then I tweeted about it some people replied kill microservices kill them the fire eradicate them right so why is there such a negative uh attitude uh for some people uh against microservices yeah I mean I mean so listen I'm a microservices apologist uh because I think that there's a lot of things to really like about microser services. Breaking up your apps into modular pieces uh makes it easier for you to uh uh uh uh code those pieces, to modify those pieces, to test those pieces. Um makes it easier to reason about all the pieces together when you write software by composing different pieces of code together. It just leads to more scalable code, not just from how the code can actually be be run in a in a in a cluster, but also scalable in terms of how you can reason about it, think about it. Um, you know, microservices lend to, you know, that the modular uh design lends to teams being able to independently and autonomously work on their things
They can they can they can ship them themselves. They can um, you know, behind APIs, you can have technology diversity if your companies are into that, which you know means that you can use what you think might be the right tool for the job. Some people can use Rust, some people can use Python, some people can use Go, whatever, whatever you need to do. So, there's a lot to really like about microservices. Uh but I think the challenge was that um we basically again as I said earlier kind of stopped thinking a little bit too early and we didn't think about all the the challenges that people were going to have when they went to actually implement them. Um, and the three big ones that I talked about yesterday that I think have kind of uh uh made them um uh you know a persona nonrada for a lot of organizations is um uh is is is number one um you know most people tell you not to use them but I think the real symptom for that is because we didn't create an abstraction with microservices that really separated how you write the code for how from how the code gets deployed. Yes, we sort of forced you to write the code in a separated way that made it easier for us to deploy it and we probably should have instead tried to figure out a way where people could have written the code and then we could have figured from the code as long as we gave them particular ways in which it was it was written we could then extract that you know extract the the boundaries if you will and then gone and run the code uh and scaled the code and other things and and I think that we can do that and I think there's some projects that are starting to do things like that um but it's not so so unlike you know map produce right where you can write a function um you know Hadoop uh or spark and then the systems can figure out where to move that code for that function to the data or you know where it needs to be run in the cluster so I think that's kind of kind of one of the first ones and and really that was manifested for a lot of people is manifested as just reading things like don't use microservices to start use something like a monolith and then eventually graduate to it and that just you know that's I mean, that's like telling somebody uh I I don't know what it's like, but it's like it's a bad way to start the conversation, right? Don't use this thing until you need it. Exactly
And the challenge is for a lot of people when they need it, it's kind of too late because then it's like they need it when they start to scale. And so if at that point in time they are trying to figure out how to actually get it to work, um you know, they're scaling their company, they're scaling application, it's the wrong time to figure out how to rewrite your application. That's right. That's right. And you basically tell people, uh, wait a second, you need to grow up to use this, right? This is for adults. It's serious business. That's right. You mentioned that and it's not it's not a good way to introduce people
And you and you quoted some famous people. I did like saying things. Yeah. And I think now that there's actually some a lot more work, people are thinking about these problems. Um, there's some work out at Google. um uh Sanjay Gamwatts and his team there wrote a paper in hot OS last year um where they quoted some of these things and try to say yeah there's got to be a better way of actually building cloud applications where we can have our cake and eat it too. We can we can we can write the code in a way that we can do it when we're a small company but that code because we've written it in a very particular way when we need to scale a system can figure out how to actually scale that code right um and you know I just think we're not there yet but I think we're that's the direction we're going so I can't help you know asking when you mentioned my produce what was this little toy project that was the test case for me spark right right the spark right spark spark was a toy for meos uh and of course you um turned into an absolutely crazy successful project. But you know what's interesting and so I just want to kind of draw this parallel and I wonder if you notice anything similar right so recently I've been to a bunch you know developer meetups right I'm a commit architect at new forj we have the graph database which plays with all the open source coolkit stuff right used to talk to models and deploy genai and do graph rack so um one of the hottest things like you wouldn't believe the hottest things in open source from my standpoint are geni and duck db right duck db is super awesome it's loved by developers And so uh so they know like are fond of doing this talk called big data is dead where they show right like the world at circa 2012 2015 puny little computers you need to create a mesh of them and need to hurt them and right and need to split you know workloads across them and it becomes very hard and unwieldy and you basically spend all your time scheduling puny jobs to puny computers reassembling them together and come now just plop a giant box in there run duct DB in Python process process terabytes of data which most people don't even have so so this is kind of the claim and so and then on the software engineering uh kind of architecture front people are saying like you know get rid of your microservices put them all the model and to me it sounds first of all it's going in cycles it sounds right like this a heiggillian spiral so like we we tried something it was hard we sort of switched back to something else we forgot that it was hard before and we're going back right so do you see the parallel with the cycle of big data being replaced by like one box and now people probably will find that one box is not enough in many cases like how does that correlate with microservices no exactly I mean I mean a ton of people especially those folks that were scared away from microservices they have been reaching for other uh solutions which I think the reality is is they work great in the early days but eventually when you need to graduate you have a hard time doing it
um you know of course if you can run everything in a single machine do it you know um I mean there's a lot of software out there that can be run with a single database uh uh that maybe is highly available couple you know a couple extra standbys but really one primary database I mean you can do that that's great um ultimately at the end of the day I think what I like to think about when it comes to these things is again how can we give people their cake you know so they they can have their cake and eat it You know, they can have an abstraction that works great on the single machine, works great when they don't necessarily have a ton of data, but that exact same abstraction will run especially efficiently for small data and will run super efficiently once you have have large data as well, right? Um, and you know, that's where I think in the microservices world, we need to figure out how to bridge the gap. I shouldn't even say microservices world. It's just in the cloud native computing world. If you're going to be running your software first and foremost in the cloud, you know, it's very interesting to me to figure out what are the right abstractions to bridge the gap from on day one. I can write the code and I don't have that many users and I don't have that much data and whatever. But as my users and data scale, the system just scales with me. Yes. By the way, I just can't help thinking of a good title for our microservices talk
Microservices, let them eat cake, right? Let them have cake, right? Let them have cake. Uh so uh but so this is you know what what really struck me so first of all you you basically just outlined the issues in microservices and you didn't describe how reboot actually addresses them right so can you tell us like how what's your take how do you solve these problems yeah I mean I mean our take is um you know I think one of the reasons why the microservices architecture landed where it did was um the services themselves were completely stateless and um and there was There's a lot of, you know, wins for that. Uh, uh, but the reality is is these services have some kind of state that they're actually working with. Um, and so what we've done in reboot is we've realized that it's it's really about it's it's the the amount of requests that are coming in for individual pieces of state and then the state themselves um is what's hard to scale. So if what we can do is we can actually have a programming model that unifies the computation and the state itself. M if we can unify those two things then we can really really easily scale that. So um you know the example uh there's been lots of programming models in the past that have done that that have unified computation and and state or encapsulated computation state and and behavior. Uh perhaps the um you know those of you that are listening you're thinking things like actors right the actor programming model
Um that's what it's all about. It's about this this this this unification. Um, so we did something like that with reboot. We said, you know, this is a good programming model. Um, or the unification is a really nice thing, but it's not enough. Oftentimes with actors themselves, um, it's a pretty low-level model. It's like message passing, sending one thing to another thing, waiting for a response to get back. And the reason why I think microservices were so successful is because it's a much more functional composition model
RPC, calling things, getting responses. You can do that all still asynchronously. Maybe in the past actors were valuable because you could do some stuff asynchronously that you couldn't do in in today's modern program languages. But today all programing languages are async and so that that that kind of gets uh swept under the rug. So you know microservices at that RPC layer is nice. Actors at that uh uh you know encapsulation of of of of state and and behavior is nice. And so if you kind of combine those things together, then you start to get an interesting an interesting programming model that's at a higher level than say actors. And then the last thing that we did with with uh uh um to kind of round out the the program models, we said, "All right, so it's kind of actor-like, but it's kind of RPC like um uh but what we want to do is we want to make sure that all of these different pieces of state, you know, all these different like actor likes things are calling between each other, they can do it safely in the face of failures
So what we did is we said, well, unlike just making it so that when you compose a whole bunch of functions together and you call things, if one of them fails somewhere along the way, you're in a bad spot. We said, no, let's make it atomic by default. Let's make it, you know, transactional by default. So when you call all these different functions, if one of them fails, the other updates that you did to any of the other actors that you called will not be committed. And that then gives you this really really nice programming model where the actors is something that you can effectively just scale up and scale down on a whole bunch of resources. So we check that box of like hey we can scale like microservices but because the programming model looks just like you're making function calls and calling things it feels much more like a monolith. you're kind of building this up in a monolith and then when you scale it up in the cluster it's totally safe because all the calls that you're making are either going to all happen or not or or not or not happen because they're atomic and transactional. Um so you know we're you know we're really just saying that unification of of code and data that you know actor like thing but at a higher level you can do some really powerful stuff with it
When you first described it to me last year, I thought like this is first of all it's obvious like why is not it done this way and then you presented the cases where it's actually not done on Google cloud right and then actual production systems fail. It was a big surprise to me right and that makes a lot of sense. So you know one thing which I thought about which you mentioned right basically uh unifying code and data. So uh in February at J focus I interviewed Yonas Bonire right the founder of Aka and one of the things he mentioned what led to the success of Aka which is one of the systems used at huge scale u is that they basically didn't try to create unified state right the data moves with actor so if data is encapsulated by the actor it's state then you can actually move the actor right and sometimes you route to actors and you can actually move them from one machine to the other you like do fail over. So how do you like uh kind of stack against that paradigm? What kind of compare reboot to aa for folks who don't know about? Yeah, totally. Totally. Um yeah. So so um again we're very similar to the actor programming model but at a higher level
Higher level. Okay. So um not about message passing uh focused on effectively RPCs calling and then in particular the way that we call between u these actor-like entities we do it in an atomic way um and so so it's a new programming model you know you know um uh that's you know you know takes kind of the best of actors and then and then then adds to it um you know AA in particular a lot of respect for AA and all the work that they've done um especially the work that they did where they sort built Kaix out. I'm not sure how much you looked at Kaix. Um, and a lot of the work there, especially a bunch of the event sourcing pieces. Um, again, you know, at the end of the day, I think these these kinds of technologies are trying to solve similar problems. Uh, but I think our big hammer in our toolkit is effectively distributed transactions and strong consistency. Um, because we believe that at the end of the day, that's the programming model you really want
And if we can make it scale, which we can, then uh why not give people the programming model that they actually want, right? Um I'd say the other big difference is when we were building um a reboot, we were thinking a lot about the full stack experience. Um we weren't just thinking about what it would be to build stuff on the back end. Um because honestly, even on the back end, sometimes you don't want strong consistency. Sometimes you want eventual consistency. So we have other mechanisms of writing code on the back end that are much more eventually consistent in nature. things more things like workflows or or saga- like patterns where you're doing a bunch of things but you're not all doing it as one one one big transaction um uh uh but on the front end we also cared a lot about that and that was a big part of the design so a couple of the things that we built into uh reboot from day one is reactivity um and the other one is item potency and so so what does that look like so reactivity means that when a front end actually calls a method on the back end that's reading some state and say that method calls some other method on the back end that's reading some state and that method called some other method on the back end that's reading some state. Anytime in this DAG that you call from the front end, anytime some state possibly changes, we reexecute the function related to that state and we propagate the information all the way back up ultimately up to the front end. Um, and this was a huge challenge with microservices as is people would want to get from the front ends they'd want to get data out of their microservices and they like they didn't have an easy way to do it and it just become way became way harder with microservices because now they had all these different things to call
That's right. So that was a big one reactivity we added and you can also even use it on the back end when you're running these more workflow like like um um um uh uh uh functions. And then the other thing that we added was item potency as a first class uh primitive. And that's so that when you're making calls from say the front ends or clients, you can guarantee that like when you make that call, it's only going to happen once, right? And just by building that into the the framework directly, it makes it so frontend code become front end or client code becomes ridiculously simple. You just make a call. You don't have to do this dance that you usually have to do between the front end and the back end where you have to do things like you know figure out how to make sure that like if there happened to be a failure when I was making the call to check to see whether or not I've already done that. So many people have seen this, right? They It's endless. If error not equals zero or something, just some crazy stuff, right? And so now that all goes away, you just get to make the call
You get to reliably retry in the face of any failures and we're going to make sure that the thing only happens once. And that's because we just fundamentally made item potency a first class primitive. And and you know, you mentioned earlier sometimes you're like, why doesn't everything work this way? I mean, I think this is kind of the iteration of computer science, right? Like we're sort of like we're like, oh wait, you know what? if you just built reactivity into the programming model. What if you just built item potency into the programming model? What if you just built atomicity into the programming model? And if you did that, which is what we've done at Reboot, you got a really, really powerful, safe, easy to use programming model that you can, you know, teach like a firstear computer science student and they can write code that's, you know, going to work right out of the box. No, what I really like about it, right, like you basically stand on the shoulder of giants. there was a lot of work in software engineering in systems right and you referenced this and so what comes to mind so it's kind of totally you know uh out of the left field but uh I've been at Fosdam in February and to my big surprise they had dev room on ADA programming language ADA is used in embedded systems and in mission critical systems right and so one so ADA was one of the first languages I learned which really excited me because of the systems design and so they came up with the first I think mainstream program language model of parallel ISM which was task assoc and so the tasks are basically units of uh synchronization and have different mechanisms of synchronization and I think the idea is that the task is is doing its work atomically so I'll go back and see I wonder if this kind of formalism can be implemented in ADA right because you know some so the tasks basically give you a lot of control and right then tasks wait for other tasks so render is a blocking mechanism but I think you can introduce you know timeouts and things like this so so like That's that's great. And like reactivity obviously that was huge push for Raka reactive programming right and that's a lot of people like not really thinking that you keep banging on the cloud and waiting for results. You're actually wasting a lot of bandwidth and resources and a lot of patterns actually uh are not you know efficient
Uh and you know it kind of also leads me to this inevitable question. How does this all relate to AI? In my take on this this is actually extremely AI friendly. let me run it by you and you tell me if this is right or not right so and I know like as a you know uh software engineer you want to rigorously kind of make claims which make sense right and describe the system and not just like put on it so but however if you will look at what's going on with the right so there is like vibe coding proliferating effectively on front end so the apps people are talking about vip code it it's like gobs of javascript right which somehow are expected to call a database What happened in like the evolution of this like the the the vibe coded agents find that they can stand up uh cloud databases like posgress using neon. So right so rebel agents find neon databases and stand them up and then they create like put stuff in them using webcoded schemas right and then so so like this is kind of what happens like front end back end so so they're mostly front end things right uh and obviously this works in a very limited sense in a in an app right which will kind of you can demo however if you are an enterprise and all your stuff is in microservices I think vip coding does not solve the problem of social modularization right so like this modularity we're talking about right so long as like we have now teams of maybe of AI agents and humans I think this idea that microservices is a social mechanism you separate concerns written by humans or maybe AI agents we don't care right as long as they look you know reasonable right but like you you I think it's inevitable that stuff will be kept separate for many reasons financial you security and and so and if you have to run different services in different places. So this sounds like a reasonable architecture to compose. Yeah, totally. Exactly. I mean I I think at the end of the day we're uh as long as AI is going to continue to be writing software which I think it will be doing for some you know foreseeable future
Um I think yeah that software is going to be best written in a way which is modular which is going to make it easier for humans if they need to to come in and understand and do what they need to do and for the organizations to scale and for the separate pieces to be owned and yada yada yada right um and yeah I mean what while while I was describing what we're doing I did not you know use the term AI or AI agents fundamentally at the end of the day AI agents are effectively actors you they're effectively these modules of code that are trying to execute some things in some step-wise way in a deterministic fashion. Um, and it's just, you know, it's that's what programming is all about. That's what we're doing. And they know something about the part of the world, right? And so, and basically, you get this level of atomicity to the interactions, right? So, reactivity, I honestly this is all good words for agents to learn. Totally. Totally. Exactly. Very cool
So, what's so like we talked last year when it was the inception, right? And now you're here at Lash Member Summit talking about it. So what's is the state of reboot and what's your developer adoption strategy? Yeah. So uh we're just getting it out there. We we started to get some early users. Um got a lot of great feedback and have been implementing that feedback. We're still an alpha piece of tech, but you can go check it out. You can go to reboot.dev and learn more about it. You can start building some of your own apps
Um one of the things that I'm most excited about Reboot is thanks to the programming model. Um you can do things like build your own durable data structures. Um uh so you could build something like say a distributed key value store, a distributed hashmap. Let's let's keep it a data structure, a distributed hashmap and then you can put that up on GitHub and other people that are building reboot applications if they're like you know you know it'd be best to store or to keep some of the data that I want for this application will be a distributed hashmap. They can grab that distributed hashmap. they can run it in their backend using reboot and again it will scale up as you add more data to it and use more machines. Um, and I think this is one of the sort of things I've always wanted is I've always wanted to be able to build distributed systems. Yes
That effectively I could give to somebody else and they could just easily use it. And that's a huge challenge. And so, you know, today we don't have many, but I I foresee us building a lot more distributed data structures that we put out there for people to play with. then it's pretty cool cuz then like you just kind of show up on day one when you're going to build your back end and you don't have to think about like anything more than just the the application logic that you're writing and which data structures you need to store which data and then and then you just build it. So um we'll be building a bunch of those uh you can check out uh things at reboot.dev join us on on the discord uh check out our docs check out our examples and yeah over the next couple months we're going to keep building out more and more and more apps. Is it in tcript? Great question. Yeah. So you can you can build backends right now in two languages
TypeScript and Python. Okay. So um you you can build a full stack uh uh uh TypeScript app. React in the front end uh uh uh TypeScript in the back end. You know thanks to that reactivity that we have in the back end. We've got integrations with React which again as I mentioned earlier it's just like it's really nice like you you basically make a function call from React in your reactive component and anytime the backend state changes changes the front-end component rerenders. So you just get like multiplayer out of the box like this couple of the apps right? Yeah. Yeah
Yeah. It's really really powerful. It's really really fun actually. Um uh so yeah building full TypeScript TypeScript apps but of course you know Python is the language of AI and there's a lot of Python out there. So you can also write I just learned recently the key value stores are AI. So you know so now you can build AI systems right. So this is amazing. Very cool
Thanks Ben and uh we hope to see you also speak at AI by the Bay in November. Sounds great and by the time probably will be much more development. So thanks for sharing and looking forward to progress on reboot of dev. Awesome. Thanks Alexi. Thank you.