Episode 6: Yves Junqueira and John Ewart, co-founders of YourBase

Transcript

This transcript was generated using auto-transcription software and the source can be edited here.

Beyang Liu: All right, I'm here with Yves Junqueira and John Ewart, two engineers who worked on developer tools at Google and [00:02:00] Amazon now co founders of YourBase, a cloud base and build and test service for large hairy code bases that understands your dependency graph to help your team ship software much faster. Evans and John, welcome to the show.

Yves Junqueira: Hey, Beyang. Thank you.

John Ewart: Thanks Beyang.

Beyang: Yeah. So to kind of kick things off here, I would love to get kind of your developer backstories, you know, how you originally got into programming and what has been kind of the long journey to eventually creating YourBase?

John: Uh, yeah, so I guess for me, I started using computers when I was really little, um, in fact, my dad brought home one of the first PCs that, that Wells Fargo ever had on the day I was born. Um-

Beyang: Wow.

John: ... and he has a background in economics and spent a lot of time tinkering with computers and writing computer models for finance and for, for banks. And so he got me into programming. I don't know I was probably 11 or 12. I was doing some FoxPro programming with him to help [00:03:00] out, uh, learning how to do some analysis of data. And about that time, Linux was becoming a thing, uh, you know, computer shows you could pick up CD sets from, you know, Walnut Creek CDROM. So I spent a lot of time experimenting with a variety of distributions and free BSD and other things. And that kind of started my, I dunno, self exploratory phase of computing, also known as breaking lots of things, including monitors by setting the refresh rate and the, uh, the mode set incorrectly.

Beyang: [laughs]

Yves: [laughs]

John: [laughs] You know, and then I, I ended up going to college, uh, majored in computer science, went to graduate school, did some work in environmental engineering, um, worked at a series of small companies and startups, and then ended up being, uh, picked up by Amazon about seven years ago, uh, moving up here to, to the Seattle area. And then I guess the rest is history from there.

Beyang: What about you, Yves?

Yves: [00:04:00] Um, do you know that movie Hackers from like a 95 movie, 1995 movie? Do you know that?

Beyang: Yeah. Yeah yeah.

Yves: Yeah. I wanted to be there.

Beyang: [laughs]

Yves: That movie was so good. I fell in love with that movie. I wanted to be a hacker. Like really, I really wanted to be a hacker. So I got it, I heard about this thing called Linux, you know, the internet and whatnot. I got like, how do I become a hacker? Oh, you should learn everything about Linux. And I got into that and it got a really deep into it. Um, and just, you know, kind of like a wedge into the security, uh, bits I grew up in Brazil. Right?

Beyang: Mm-hmm [affirmative].

Yves: And, uh, it didn't learn coding until much later. I studied international relations uh, eventually couldn't find a job once I was out of the university and ended up going to IT 'cause I had that knowledge from my script, kiddie past.

Beyang: [laughs]

Yves: [laughs] And I became a CIS admin [00:05:00] and, um, got really good at it somewhat quickly. And I got a job at Google and moved eventually moved to Zurich in Switzerland-

Beyang: Mm-hmm [affirmative].

Yves: ... worked there for many years. Uh, so I spent over all 10 years at Google and then, uh, moved to Seattle. And sometime later I, I left Google to start YourBase with John and yeah, that's where we are at now.

Beyang: Tell me a little bit more, uh, about YourBase, um, in particular, you know, for, for people listening, who've never heard of it before. How, how would you describe what it does?

Yves: Yeah, sure. Uh, we provide a built in test service that, uh, at the core is, it may look like a CI, but at the core it has, um, uh, the capability of creating a, build dependency graph. And this dependency graph is, um, gives, gives us the ability to do many cool things, including [00:06:00] speeding up the building and test cycle. Um, and also just providing a lot more information about your testing process and your build process and your, um, software development life cycle.

There's a hosted component, uh, that you can just use the, the hosted version of YourBase, or you can deploy YourBase, YourBase servers, uh, in your own cloud. And at the end of the day, what you get is the, this ability to get very fast, high quality feedback when your code and a lot more intelligence about your, your build and test process and your dependencies and so forth.

Beyang: That's really interesting. So, you know, when you mentioned the dependency graph, uh, can you talk to us, uh, more about that? So there's many different ways to describe dependencies or are we talking about like, you know, it knows node modules and can recompile those, uh, interactively or is it some kind of other notion of dependency?

Yves: Um, it's a very broad notion of the, of the [00:07:00] dependency. But let me give an example so that, that makes it a little more clear, right?

Beyang: Hmm.

Yves: So let's say that you have a very large application and let's say you have a monolith, right. Which is a very common pattern for, for building and shaping software. You have a very large monolith and a lot of people working on that same code base. And it's taking a very long time to test your, your code base. 'Cause once you want to make a change to your software, you want to make sure that there's no regressions and when you're checking in changes to the repository. And so you run all these tests and potentially, uh, hundreds or thousands of tests. So how do you make sure that you were running the correct tests? Do you run all of the tests that you need? Do you also compile all the dependencies, all the, um, all the, um, packages that are required underneath, even if it's not a compiled language, what language do you have to install all the node modules? Do you have to download all of them? Do you have to redownload all of them every [00:08:00] time?

So if you look at the build process, it either in an abstract sense, it's a, it's a graph of many nodes where nodes are different steps and those steps can be, um, a process that runs on, on, on Linux, right? It's just, a, uh, similar to a make or a CC pro uh, like, uh, the C compilers running a process that takes some input and it has an output.

Beyang: Mm-hmm [affirmative].

Yves: But the build and test process is a very large and complex graph of many different activities that could be processes. But sometimes, um, the reason we have a very broad definition of, you know, dependency graph is that sometimes your build and test process is actually one Linux process, right? Or one process on the operating system, whatever operating system it is. So in some cases you just stand up a JVM and you run it, all the tasks on that thing. Right? And, um, so we want to know what are the dependencies of that thing. So for example, if you really know that, um, module A doesn't [00:09:00] depend on module D and you will update module D you probably don't need to run the tests related to module A because they have, they have nothing to do with each other. Right?

So understanding these, uh, de- dependencies just gives you a lot of power. So for example, you can skip the unnecessary parts of the build and task process, but you can also know what depends on what you may have, uh, accidental dependencies that you don't want, or you may have, uh, the, it may be difficult for you to change some, some code because you don't know what exactly depends on water and so forth. So the dependency graph has this ability to know very deep. Um, what piece of coal depends on what.

Beyang: So how do you construct that dependency graph, you know, am I, as a user of YourBase going to have to go through and write a bunch of config files that describes exactly what depends on what, or is there some magic going on here?

John: [laughs] Uh, no. I mean, so it's not magic science, I guess.

Beyang: [laughs]

John: Uh, [00:10:00] we, uh, so, so in effect we analyze builds from the system called level and all the way into a pro language level. So if you have, for example, a, um, a JVM build, right, you're building a Java program, the JVM, as Eva said, is a single process. You, you run maven or whatever, whatever you're running, and it's a, a single execution of a single binary of the Java binary, but it does a lot of things, right?

So, uh, we have the ability to monitor from the outside. All of the system calls that your build is making and we use that to figure out what files that you depend on what, you know, networks you may be calling, uh, all of the things that your processes are doing, but we also have the ability with some simple add-ons. So we have, for example, a Maven plugin, uh, that when you're building in our CI system, will leverage an external thing that will infer that build the graph by, by analyzing your Java [00:11:00] code, uh, as it's building. And so then we use both the information from the JVM and also from the process graph to build this, um, dependency graph.

Yves: Just to add on what John said, uh, what do we don't say, what do we keep as a secret is how do we exactly do that? How do we exactly piece those pieces of the puzzle together? And how do we make it correct? Because the hard bit is how do you actually make sure that this infer to dependency graph is actually correct and corresponds to reality, 'cause if you get it wrong and let's say that you're trying to test their code and you accidentally, and you're incorrect is kept some important part of your build a test process. You're going to get a broken test. Right?

Beyang: That makes sense. I mean, you definitely don't want to trade off speed for, or correctness for speed with your, with your bills.

John: That's right. Yep.

Beyang: Got it. But it's, so it is kind of your secret sauce right now, but it's, [00:12:00] uh, if I understand correctly, it's a combination of static analysis and also runtime analysis, like running the build in a sandbox environment where you're kind of observing, uh, what syscalls are, are happening. Is that, is that right?

John: Yes. Syscalls and other things.

Yves: And the, the other addition is the fact that we are able to merge these two, right? We have a blend of both the, at the system called level where it makes sense, and at the programming language level where it makes sense, right? And in the case of Java or Ruby uh, Python, oftentimes you have these, you know, long running processes that run hundreds, thousands of tests. So in those cases, doing the analysis of simply, you know, process-based analysis is not necessarily going to get you much benefit because the probability that you run your entire RSpec Suite based on any code change is probably nearly one. Right? And so being able to combine the [00:13:00] very fine grained language specific details with the externally observed details means that we have a very rich picture of like, not only what you're running and how you're running it, but what it depends on what, uh, and because we have all this data, we can then show you things about your builds.

Um, some of our customers have discovered, they're surprised that certain parts of their build have dependencies on some other part of their source code, because of the way they invoked get or something, for example. Um, and so they've been able to not only automatically, but then to further refine their build process, to cut those build times down.

Beyang: That makes sense. I mean, what you're describing is it sounds like a really intelligent, um, system. It also sounds like, uh, perhaps like the, the model of using it is, is quite different from, uh, some of the more kind of well known, popular, um, CI and build [00:14:00] services, and thinking of things like, you know, Jenkins circle CI, gitlab CI and gitlab actions. All these things are, you know, if I want to use them, I'm basically describing exactly what I want to happen in response to, you know, push or whatever. Like I'm telling the computer exactly what I want it to run and build. How, how do you position your base against tools like that? Are you trying to go in like, kind of replace, uh, those types of tools or are you going after a different kind of market altogether?

Yves: I think the market is gigantic. So I don't think about replacing, uh, tools. And in fact that we are very focused on the build and test, um, um, bits of it.

Beyang: Mm-hmm [affirmative].

Yves: We, we have a very modular system that can be used with existing Cis. Uh, what we have observed, those that, when, once we get the, once a customer deploys YourBase for their, for their system, for their systems, if they're using an existing [00:15:00] CI, they sometimes think that it's better to not pay twice for, for, uh, something that is provided feedback on their, on their, uh, on their code. Right? So they end up, uh, like, because as you know, hosted, CIS at least tend to charge based on parallel execution on like, how often do you, are you, are you building and how much, how long it's taking.

And if you're delegating to a third party to build it, you're kind of like paying twice. So we made it possible for, for customers to YourBase as a CI, that they just integrate directly with a GitHub, for example, and then take it from there.

Beyang: Got it. So you can use your base in conjunction with, uh, other build tools and services.

Yves: Absolutely. Yes. Yeah. In fact, we don't focus at all on a deployment. Um, I understand that most people talk about CI/CD as being a single entity, right?

Beyang: Yeah.

Yves: [00:16:00] And, uh, a lot of CI products, CI solutions I have also developed pipelines and deployment capabilities, and that's not something that we are focused on. That's not something we're particularly good at. So in fact that our customers use YourBase as the entry point CI and then they, they do deployment using existing solutions, right? They integrate, we integrate very easily with other solutions. So that's, that's what tends to happen. Uh, we focus on, on the build and test process. We want to do a really good job at, at, at that, and, yeah, we want to be fast, consistent, intelligent, and, um, provide actionable information for, for folks doesn't matter how big the code bases, the code base is. And other parts of the problem are better solved by other folks.

Beyang: That makes a lot of sense. If you were to describe kind of the ideal user of YourBase right now, do you have kind of a single picture in mind? Is it a big organization, a small organization, certain [00:17:00] languages, certain technologies that are ideal for use with YourBase?

Yves: Yeah. Um, we, we, we've evolved over time. So when we started, we, uh, sold, do very small companies 'cause that's what we could, um, easily, uh, support. And over time we've grown to, to actually, uh, target much significantly larger organizations. And, uh, it turns out that the larger organizations are the ones that care the most about, uh, efficiency of building tests, because they, they're the ones that will, are more and more likely to have very large code bases that have lots of tasks that are very complex, that are hard to manage. And they are there organizations that set up, uh, teams dedicated to improving the engineering productivity. And therefore, um, they ha they see the highest return on investment when they integrate with YourBase.

Beyang: I guess like, kind of [00:18:00] um, taking a step back a bit, you know, you both worked on developer tools at Amazon and Google, um, which probably have two of the largest proprietary code bases in the world. Can you talk to us about your journey as developers there with a particular focus on experiences that you had that kind of informed your understanding of the world leading up to creating YourBase?

John: Yeah sure. Um, so I can say that when I initially joined Amazon, my job was working on an internal tool for deployment and called Apollo. Um, Apollo is a tool that manages infrastructure, you know, deploys millions of times in a given week to millions of machines. And so that entry point showed me a lot about how automating a lot of the drudgery, I guess, the sort of, um, you know, building software, deploying it to hosts [00:19:00] by creating a, a reproducible process-

Beyang: Mm-hmm [affirmative].

John: ... that you could control as a developer that would get out of your way was incredibly powerful. Um, before joining Amazon, I had worked for a number of small companies and startups and I, the one thing that I noticed immediately that was different was, uh, coming to Amazon your first day, you know, there's this Wiki and you go through it and then someone says, here's a bug fix it. And at some point during the day, or during that first week, you go to click the deploy button and you're kind of shaking because you're thinking, am I going to break the universe? Right?

Beyang: [laughs]

John: But because there are all of these tools in place that helped to ensure correctness to help, to deploy things in a repeatable manner to help roll back all of these things, uh, you can focus on adding value, right? You can focus on building the product that you're building, but at the same time, I will say that at least at Amazon, there are a lot of the same problems, [00:20:00] right? There's the same problems that developers face in the outside world developers inside of Amazon face. How do I deploy this thing? How do I build this thing? Um, what, what kind of, how do I manage the complexity that I'm given the business model complexity, the program complexity, the dependencies, all of those things are very similar. I think that certainly the size is different between say Amazon and Google and, you know, a different small company.

Beyang: Mm-hmm [affirmative].

John: But I think that at the end of the day, it's really not a giant leap between the two. Right. Um, but I think that the one thing that I sort of appreciated the most and that every time I've, I've come and gone from Amazon a few times. Um, in fact, I think I've, I've been there three different times in the last, you know, seven years. Um, but every time that I leave, I think man, if only I had X and usually it's a thing that simplifies my life, such that [00:21:00] whenever I look at joining a new project or building a new thing, I don't need to learn an entirely new universe. Right? Um, that I simply have a set of tooling that I can run that is repeatable, uh, between one team and another or one project and another, I don't have to remember what version of Ruby is this thing using or what, you know, dependency management tool am I using? Right?

Beyang: Yes.

John: All of those kinds of thing.

Yves: I think that Google is a little uh, weird and different. The life of a Google engineer is, there's a lot of the same struggle. How do I get things done? How do I ship? How do I, how do I make this correct? I'm nervous. I don't want to ship this, this is going to break. But Google is different. There's, Google evolved a, a separate branch off of evolution. It's like the, I don't know.

I was talking to John earlier today about the comb jellyfish, the comb jellyfish, I think it's called. It's a, it's an organism that it's a little bit like a jellyfish. They are completely different branch of evolution and they have a [00:22:00] nervous system, but it was evolved completely independent and different from the nervous system that all the organs or other organisms on earth have. And the Google engineering feels a little like that. It's, it solves the exact same problems that everything, uh, outside solves, but it's like, you, you know, you put a bunch of, uh, engineers, like in, on a vacuum, like isolated Omar. So now go build this thing that it should be exactly like this, all the things that Amazon has. Right? But, make it different.

And for a while, and I think that that has goods and bads. Right? And so I think that from that they evolved very unique approaches to many things, right? From not produced a big table to board. And so-

John: It's like the, it's like the Australia uh, developers.

Beyang: [laughs]

Yves: Australia, that's a very good analogy. Yes. It's like Australia of, of, of developing infrastructure and, um, you know, that's good and bad. Right? I think that, [00:23:00] um, in general, uh, uh, a team of engineers at Google looks more like another team of engineers at Google than, um, any other team in the world, but let's say, right? So it is it's, it's uh, yeah, so the, the tooling is very different. Like even programming languages used internally, um, are different.

Beyang: Mm-hmm [affirmative].

Yves: Database systems are different. And, but that doesn't mean that it's necessarily better, uh, at all. And there are some things that are, that were really good over there and that we, um, that I miss, I still miss to date, but that, uh, I think over time, the more, um, I think that it's not so clear to me anymore, that the things that, um, Google has are, you know, um, not in every area, uh, I think that they're better or, or equivalent, um, uh, alternatives outside. Right? And I think that Kubernetes is a [00:24:00] fantastic ecosystem that is much, that is doing much more than Borg does.

Beyang: Mm-hmm [affirmative].

Yves: Um, like Sourcegraph has become-

John: Borg would be kind of the, the internal version of Kubernetes.

Yves: Yes, correct. Yeah Borg, Borg is the internal, the, the, the, the thing that came before Kubernetes, right? The, the, the, the inspiration for, uh, I would say for Kubernetes the, you can't even say that it's container ba- it is container based, but that's a, the implementation detailed. It was not, that was not the ... anyway so, um, and similarly, there are many other tools that I think outside have become, um, as good or, or, or better. And there, there are many examples as you know.

John: Yeah. I mean, I think, uh, culture wise, Amazon has always been more of a, there's a bunch of stuff let's smash it together and make it work, you know, uh, almost every Java project, the core of the Java build system for a long time, and possibly even today was built on Ant. Right.

Beyang: Hmm.

John: Um, so Google solution, [00:25:00] right internally, it's called blaze externally Bazel, Amazon solution is let's make Ant, you know, work with this standardized build system, um, or, you know, our spec working with Rake, right? They, their culture is very much take a thing in the wild and bring it in and make it work inside of this wild universe that is Amazon.

Beyang: [laughs]

John: Um, and, and not necessarily rebuild a brand new thing all the time. So I think it's, again, it's, I think they're both very similar in scale and engineering talent, and it's just that they have somewhat different approaches to the way that they solve particular problems. Right?

Yves: But with regards to your original question about how that, how our stories influenced. So at the, we were doing now, um, I think that the most important thing that I took from Google that, uh, definitely influenced the way, uh, I've thought about YourBase and we, we work with YourBase is that I think at the, [00:26:00] um, at Google, there's this insane, ambitious about, ambition about, um, what you can do right with technology. And there is seemingly no limit about what needs to be done. So the challenge is to find a problem once the problem is defined, the rest is just hard work and make it happen. Um, this, this is true from very, the very origins of Google, you know, how Google defined this from, we want to make information available, uh, all, all the information from the internet available at under 300 milliseconds. It doesn't matter what it takes. And it turns out that what it took was to put all of that on in RAM in 1996. Right?

Beyang: [laughs]

John: [laughs]

Yves: So the certain, you know, the, the, the, the, the it's completely unthinkable, like no, no same person would think about, Oh, let's just put the internet in, in memory, right. In a bunch of computers and go from that. But, so that sort of approach where, you know, you don't, you don't see [00:27:00] the technology is not the, the end goal, but it's the, you know, it's just a way to get things done and, uh, have, you know, uh, it's kind of like seeing see no limits to how you do things. Um, definitely like informed our approach. So when we, when we, uh, when I left Google and I was starting a company, and initially YourBase was going to be something else. And, um, I w- I was playing around with many different ideas, uh, including, um, database as a service, you know, microservices platform. I, I prototype many different ideas and I tested many different ideas, but the thing that was in common with all of, with everything was doing is that the, the process of just getting things done and built, um, were, were just very painful.

And I, and I, and I, and I started to talk to many people about, Hey, like, what's, what's in your data they like as a developer and the more people I [00:28:00] talked, the more I could see that there was, there was something missing. And, um, I, so I, I went on and, and pitched to a bunch of people, Hey, what if we, there was a way for you to get feedback when you're coding five seconds, rather than in 15 minutes.

Beyang: Yeah.

Yves: And, you know, and, and what if it actually built on your laptop rather than actually building the cloud for your code, as you're writing on your laptop, would you try something like that? And people said, sure, I will definitely try something like that. I mean, that, that sounds like a dream. And I would ask, okay, would you, would you, um, uh, would you like to pay to help develop enough of such solution? And, you know, a bunch of people said yes. And I was like, okay. So I got to build this.

And then I found John, we, we got together and we spent a ridiculous amount of time actually making this crazy, you know, plan happened. 'Cause we, I had no idea how to, how, how we're going to do this. Right. This is a big promise. How do we make [00:29:00] sure that we're giving feedback on people like run all their tests, build their software in the cloud, but make everything seamless and, but also make it correct. Um, it was a little bit higher than I thought when we started.

And yeah, it took a little bit of time to, to get to, uh, to any launchable, uh, state. Uh, but yeah, it, it did happen. I'm glad we persisted and yeah. So, uh, I think that, that persistence, um, like the goal and the process is probably, you know, I, I probably got some, some, a little bit of that from, from spending time with other, uh, folks everywhere.

Beyang: Yeah. That makes sense. I mean, but, what you're saying, it's, it really sounds familiar to me. 'Cause, you know, when we were first starting Sourcegraph, it was like, well, there were, uh, comparisons to tools inside the Google, you know, code search being the main one for Sourcegraph.

Yves: Mm-hmm [affirmative].

Beyang: But this is so like, it's so different, you know, [00:30:00] inside of Google, the way things work from the outside world where you're kind of like broadly inspired by the culture there and the, um, prioritization of developer experience and that sort of thing. But then when you go and try to build a solution for everyone else, there's, it's a completely different kind of environment.

Yves: Yes. Just the Wild West.

Beyang: Yeah. The wild, it's like, you've you, you're a kangaroo. You've like made it out of Australia and now you're trying to like hop, I don't know that [laughs]

Yves: [laughs]

Beyang: [crosstalk 00:30:33] Australia thing.

John: When you encounter a Platypus.

Yves: [laughs]

Beyang: Yeah. Exactly.

John: Yeah. It's a simple idea on paper, right?

Beyang: Yeah.

John: Yeah.

Beyang: You know, out of curiosity, do you find that, uh, when you're talking to potential customers or users, do you see a correlation between like having worked at Google or Amazon or an organization like that, uh, earlier in their career and being able to just like grok what YourBase does or is it kind of, [00:31:00] uh, you know, uncorrelated with that?

John: It, it is easier, um, absolutely. So, you know, there's a large contingent of former, uh, Google, Facebook, Amazon engineers. And they come to expect some things from their developer tools. And when we, um, when we go and talk to them, we don't have to explain much. Right? Um, so that would be, definitely makes the conversation easier. Uh, but what we found is that, that's not necessarily a requirement to have a good, successful customer conversations.

Beyang: Mm-hmm [affirmative].

John: Um, as you know, these days, large organizations have dedicated, dedicated areas, departments, teams for doing engineering productivity and those people leading those teams know everything that's going on. Right? They know what is, um, what is the state of the art that they know the latest trends, the best tools, um, their challenges [00:32:00] to make things happen that work for their organization. Right? So when, um, when they have the problem that we, that we help solve, when they have the problems that we help solve, it's a somewhat, uh, easier conversation. And in fact, um, I'm not sure that your audience is, uh, our audience here cares too much about these bits, but in fact, the, um, we actually found out that we have a much better time talking to, uh, um, those leads on engineering, productivity teams then when individual developer.

And I'm not, that's an interesting thing. I don't, I don't know if you absorbs, observed the same, but even though the developer may have that pain of like waiting for 30 minutes for their build, maybe they just don't imagine that that's something that can be improved-

Beyang: Yeah.

John: ... or, you know, um, it's just, or maybe the build is such a hairy part of [00:33:00] the development process. Nobody wants to be associated with it. Nobody wants to change it. Nobody wants to deal with it, unless for that crazy person that, you know, that is, that maintains the bill every team has that person. Right? Um, so people don't think that it's, that it's possible to, to integrate it, improve their, their process. Right.

Beyang: Yeah.

John: Um, so that's why we have much easier, um, conversations with, um, more experienced people, like very senior architects and so forth. I think they embrace change to my surprise. They embrace change a little easier than, than, than I would expect.

Beyang: Yeah. That's interesting. It's like the most developers, it's not their job to think about build speeds and that sort of thing. So even though they feel the pain, it might not be at the forefront of their minds. Like, Hey, I could actually, you know, step up and bring in a solution that changes from my, my team. Whereas if you're talking to someone who works on [00:34:00] the developer productivity team, it's like, that's their job description, make the team more productive. And so they can see more of the instant value of your product. And they actually have the, the will to kind of push forward adoption of it.

Yves: But I can, I can tell you that, uh, you know, we have some customers where their, their builds used to take 20 minutes plus easily every time, uh, you know, and this is a group of folks that builds a lot, you know, um, hundreds of times per week, easily and normal build times with us, or, you know, four or five minutes on average.

Beyang: Yeah.

Yves: But when they start creeping up to eight or nine minutes, you know, the, the alarm bells start ringing, right? So once you get used to that, now you kind of, you know, you don't want to give it up [laughs].

John: Yeah. It's hard to go back to the, the bad way.

Yves: Yeah. Yep.

John: That's kind of how I felt, you know, coming from, from Amazon is internally, you want to start a new project, you'd go to this neat tool and you'd say, I want to build a Java project. I want to use these frameworks. You click a button, [00:35:00] they would make you a source repository. It would be prepopulated with basically a skeleton project that would build right out of the gate. It would be, you know, you'd say I want to deploy it to X, Y, Z, and it would provision some capacity and infrastructure and you just clone the source code onto your machine, make some changes, build, push, and off it goes.

Beyang: Mm-hmm [affirmative].

John: Um, whereas now every time I think about building a new thing, I feel like, Oh man, now I have to go do X, Y, Z, and then don't forget this thing. Right? Um, and so I would love to help push the ball forward towards where, for all developers that's as easy as that. And the feedback loop is such that you can get feedback immediately, right? There's no long wait cycle between, um, you know, doing a build, seeing the results, pushing a poll request, finding out that it's past, uh, all those parts of the build process.

Beyang: Yeah. It's all, it's almost like you're trying to [00:36:00] eliminate that build exam, anxiety.

Yves: Mm-hmm [affirmative].

John: You know the, my codes, compiling name, right? The xkcd comic.

Beyang: Yeah.

Yves: Mm-hmm [affirmative].

John: You know, those, those guys will be grumpy 'cause they won't have sword fighting anymore.

Yves: [laughs]

Beyang: So, um, you mentioned Blaze as a, uh, you know, the Blaze as Google's internal build system now opensource does, um, Blaze or Bazil. Um, Bazil is it Bazil?

Yves: Bazil. Yep.

Beyang: Bazil. Got it. Um, yeah, so Blaze and Bazel, uh, that's how Google builds things internally. And since it's open sourcing, um, do you see that affecting kind of the landscape of, of CI and builds? What do you think the impact of that is going to be on the world?

Yves: Well, I hope it affects, and I think that it is seeing very good adoption in many places. I think that it's, uh, I mean I used it for many years. It's a fantastic system. It's definitely a major evolution to many things that are [00:37:00] available out there. And I think that people should definitely take a look at Bazel and, um, learn about it and understand it.

It's, uh, it's very robust, very mature. It's very fast. Um, it's just a different way of thinking about build and it's a different way of writing your tests and, and programming your, your entire application to be, uh, compile build and so forth. So when I, when I left Google, I immediately, uh, fortunately Bazel was already open source. So I jumped right in, right on the bandwagon, bandwagon. And I started using Bazel too. Um, and, um, what was interesting for me was that, um, the experience at the time of using Bazel, uh, was very, was very different.

Uh, at Google everything's already, uh, much similar to what John [00:38:00] described it at Amazon, um, at Google everything's already set up or you just come in new, you, you talk to your, the name and password and you have access to build, um, Google search, right?

Beyang: Yeah.

Yves: And you kind, kind of of oversimplify a little bit. But, um, but everything is already set up for you, everything's there. With Bazil that was not the case and I had trouble, uh, adding dependencies to my projects. The, the, as you probably know, um, with Bazell the challenge is that it really needs to understand very deeply, uh, it needs to everything about your project, all the way to old dependencies, all the way down, you really have to declare, do use Bazil to build all your dependencies. Um, and this, this is a challenge because anytime you ha- you have a, you want to use it a third party software, and that software has its own rules for building itself, which is the case [00:39:00] for the larger and more complex projects, then, um, it, you have to write the, the, the compilation roles and the testing roles and so forth by yourself. And you have to adapt, adapt, um, their built system. And sometimes even the code because of different import paths and whatnot. And you have, have to adapt all of that to, uh, your, you know, to your scenario, right? You know, to work with your code.

I think that there's a possibility that over time, if a very large conti contingent of people uses Bazel right, and there's widespread usage of Bazel just like there is for, uh, Kubernetes let's say, and suddenly it becomes a standard not soundly, but like if it becomes a standard, if it passes a certain critical threshold where there's enough momentum in the community where, um, uh, almost every open source project has a way to be built automatically by Bazel or if the Bazel team invests a lot on automatic ways of building things.

Beyang: Hmm.

Yves: I can see it [00:40:00] becoming even more popular, you know, which is very exciting. I think that it's a tool that, um, is really great, but at least for now, uh, what we see is that, uh, there are many companies that are, that have the problems that Bazel solves, including incremental builds, um, which, uh, you know, it gives you this ability to, uh, have, uh, the, the way that builds or works very quickly is that it allows you to build and test software incrementally because it compiles and, and, and it executes steps on itself on its graph. And it caches the dam in a distributed way.

So if, if you have different people working on the same code base and to build a certain part of the code, and someone else builds the exact same code that has the same, um, the same exact file contents, it reuses, it's able to reuse parts of that step and, you know, just patches that from a distributed cache and it can speed up something which is [00:41:00] great.

John: But you kind of have to specify that in advance.

Yves: But you have to specify all of that in, in, in advance. So, uh, for, for large companies that are, have been, um, moving to Bazel or using Bazel, many of them are very successful. They're, they're talking about it outside, but it's a, it's a, uh, [inaudible 00:41:21] process. Right? And, uh, and I, you know, I'm really looking forward to what Google is, is, is continuing to do with Bazel. What we are doing is, you know, we have a different approach. I think if you're using Bazels or using any other system, what we do is we do two things first.

We, uh, you, we, we just assume that your build system is not going to change significantly, internally, so whatever tool you're using, Maven, a Gradle, uh, Bazel or just make files or whatever you're using, you don't have to change that. You don't have to throw it away. It's just too much work to do that for a very logical base. It's almost impossible. [00:42:00] So we take that and we try to augment it instrumented so that it, it's able to use the, the dependency graph that we provide, you know, as an API and, uh, automatically able, and then you were able to speak, you know, have incremental builds and have incremental testing. That's something that Bazel, doesn't do that we found out that we also had to do in order to deliver on that crazy, you know, goal that we had to like, Oh, like we're going to build your soft- it's easy.

We're just going to build your software much faster than, than you normally do. And it turns out that we also had to do something called test selection, which is, um, you need to test that this particular test, um, depends on this other code. So therefore when you're changing this other code, you need to run this test. Right? And this happens.

Um, that's not something that Bazel able to do because Bazel works only at the package level granularily. And it doesn't go very deep on, on, let's say it has a coarser [00:43:00] grained dependency graph, and we have, uh, a finer grain dependency graph. So we're, we're pretty much, um, uh, an addition we don't replace Bazel, like, I think that, um, what we see is that a company that is considering using Bazel, they are going for the incremental build aspect. Um, and they, they, um, they can do that with Bazel. And the advantage of Bazel is that it's a very robust, a very mature system. Awesome. Uh, and it's provably, correct, because it's very conservative.

Beyang: Yup.

Yves: And our approach is, um, we, we, uh, focus on, uh, reliability also and, and, um, speed, but the, the, our differentiator is convenience, right? You don't have to write a dependency graph, you don't have to specify things. And our, our, uh, system does that for you. Um, so you, you can get some of the same benefits that you would get from Bazel, but, um, [00:44:00] um, a lot of the benefits that we get from Bazel, but with a lot of more, it's a lot more convenient.

Beyang: That makes sense. It's not like either or either, right?

Yves: Absolutely.

Beyang: Your, your approach is like, whatever you use as your built system, whether it's Bazel or, you know, Ant or Maven, like YourBase takes that, and kind of understands the dependency graph with the configuration that's available and, and actually executes that build in an efficient manner.

Yves: Yep. Yep.

Beyang: Got it. Um, just out of curiosity, do, do you use Bazel at internally? For your own source code?

Yves: Uh, we initially did. Uh, it was not a very popular thing within the team. I really wanted to continue using it. And, uh, we, we, uh, at the time, uh, this was, it was at the very beginning of the project. John, I think was not even getting started yet when we, when we, um, I switched off Bazel and, um, and then we started using, [00:45:00] um, um, our own, like we created a, you know, YourBase supports a very simple, the, the clarity of syntax for specifying, uh, much like any traditional CI and you, so we created that instead. And that's something that John, um, was, uh, very keen on creating. 'Cause it's a very, you know, it's, it's a modern way of developing of, of, of defining your builder tasks. Right?

You just, just like, uh, you know, circle CI, you would specify any elements, so forth. So we, we created something similar. So we internally we use, um, that, that same system, we use our own, our own, um, build uh, the, uh, the clarity of syntax.

Beyang: Okay. Got it. So you're just using kind of your own-

Yves: Yeah. And yeah, so the, the, and then what, what we're able to do is we're able to, like, YourBase is able to understand the different components within your repository. Right? And it's able to glue together different repositories. So that's [00:46:00] how, uh, we were able to not, um, not need Bazel at the end of the day.

Beyang: Can I get your comment on, uh, the kind of Bazel lookalikes out there now? I mean, there's uh, I think there's, uh, several build systems that are kind of, uh, have the same high level vision, you know, things that come to mind back, out of Facebook, uh, Pants, uh, Gratil, uh, please.build.

Yves: Mm-hmm [affirmative].

Beyang: Um, are you, what's your familiarity with those tools and how do you view them in the kind of broader CI landscape?

Yves: I haven't used them in any active project. I did the research dam and I'm optimistic about all these graph based filters. And I think that it's a, it's a really robust, really good way to, to, uh, develop code. Um, but I think it's a different style. And I think that people are going to land on a graph based build system or not, and it's going to depend on their requirements. [00:47:00] I think that in my experience, uh, what succeeds is, what the developers want to adopt. Right?

And, um, I think that my, my guess is that people prefer a simpler approach where it's a little bit closer to a what a Dockerfile is, where things are very, very simple to define. You would just run commands on a container and, you know, that's the, that's the end of the story. And that's, you know, yeah, we, I think that that's a little bit more intuitive and simpler for developers because it matches with their, with their own experience, uh, when they're, uh, developing on their laptop, right? While these other systems have a learning curve. But I think that developer infrastructure, developer tools, there's, you know, users for everyone, I think this is a gigantic to speak in, you know, CI, you know, fashion, it is the gigantic market.

Beyang: [laughs]

Yves: So [00:48:00] I think like many, one should feel defensive about this or that. I think there's, as long as you're solving a problem for, for, um, for, for people that want the thing in a particular way, or that have the particular type of requirements. I think that there's, um, uh, there's space for it, for everything. But my, my current, um, uh, what do we see from our customers at least is that people tend to gravitate towards the simpler way of like a little bit more container based, like commands on the Linux container sort of thing. Right?

Beyang: Mm-hmm [affirmative]. That makes sense. You know, as you look towards the future, um, do you have any predictions about how the CI landscape is going to evolve? You know, like five years from now are, you know, are, are most people are going to be using Bazel, um, are, is your base going to be kind of the, the kind of standard defaults, uh, build system for, um, both large companies open? [00:49:00] Like wha- if you were to, you know-

Yves: Mm-hmm [affirmative].

Beyang: ... get on kind of the Nostradamus soapbox, you know, predict the future for us please [laughs].

Yves: Of course, easy, easy. Um, I think that, um, do predict a future. You have to think about what, uh, what, what is the arrows of, of evolution pointing towards, right? What are the evolutionary pressures on, on these systems? And I think what is guaranteed to continue to, to happen is that we're going to have more languages and we're going to have more versions. We're going to have more open source. We're going to have more types of technologies. We're going to have, um, AI driven development, right? We're going to have all sorts of things happening everywhere. And, uh, so there's more fragmentation. So that's, that's in, in the developer developer tools like landscape.

Beyang: Mm-hmm [affirmative].

Yves: Um, but there's, [00:50:00] um, so I think that there's, it's very hard to say that this model is going to win or that model is going to win. Um, I think that if I could get bet, uh, bet, I think it's going to be like in any most, all other, uh, develop, um, technology like this. I think the closest analogous is like databases, right? There's just not a single database. There is a handful of extremely popular databases. There are databases like Oracle that have been around for, for a long time.

So I don't think, for example, that Jenkins is going to go away. I don't think Makefiles are going to go away ever. Right? And I think that established CIs are gonna be here for a long time, but I think the new use cases and new needs are going to push for the growth of certain models and what I hope to, and I hope that I'm right, is that, um, what we, what we are setting up, you know, our company to, to be is, we're there for [00:51:00] handling complexity really well.

And I think that complexity is this thing that is going to grow a lot over time. It, um, all the time, you know, um, nonstop. Right? And, um, I think that if you want a specialized build system that is able to handle complex needs or, or, or is able to scale from, from a small, um, from a small application all the way to, you know, I'm now I'm Facebook complexity, I think that YourBase is going to be your system of choice. Um, and the liking everything there's going to be a second system of choice, you know, there's going to be Bazel. And I think that there's a lot of people were using Bazel with YourBase, and you're going to have an amazing integration with Bazel for a base of customers.

And so, yeah, I think that's the, that's, that's what I love to, to be at, you know, we are, um, in this future where YourBase is, is the choice for, uh, very serious, [00:52:00] um, software feedback on when you're trying to ship code fast.

Beyang: I guess, you know, just taking a step back for a second from kind of a, you know, maybe first principles perspective, why do you think build systems are so hard and complex? Yeah. You're, you're telling, [crosstalk 00:52:17] 1980 you know, they'd probably be like, well, you have your source code, you have your deployment target, you've got the compiler, you know, how many ways are there to skin that cat? You know?

Yves: But I think John is better to answer the, I just wanted to make a comment that I think that if we knew how hard it is, maybe would have chosen something else to, to do right. 'Cause it took a lot of the long time to, to get to a good state, but I'll let John answer that. 'Cause I think we know, you know, very, very painful ways or what it took us to get to this point.

John: Yeah, you're right. There, I think the primary challenge with all build systems is that it is a very open ended [00:53:00] problem, right? You, you are, you're trying to solve, a, effectively a problem that has an unlimited problem space because the number of permutations of language, uh, build tool like, you know, rake, for example, consider Java, right? You've got ant, you got Maven, you've got a Gradle. Uh, you've got, if you're running a closure, you've got line, line, line, I forget the name of it. Uh, but like within a small single language JVM space, you have five, 10 different tools that you could use to build, uh, your, your particular package.

Um, and so attempting to encompass, all of that is very challenging, right? Trying to predict all of the things that people are going to do and going to want to do with your system and your tooling. Uh, and we all do this right? The ways in which we break those systems is pretty impressive. Um, and so I think [00:54:00] the biggest thing is building a team tool that is flexible enough, uh, that people can, they can evolve with people's needs and that it can grow with the ecosystem, but providing enough structure and scaffolding such that it is not to your point about, you know, Australia that is not the wild West.

Um, you know, and so I think that there's, there's a middle ground. And I think for a very long time, we've ended up rebuilding systems that are very tailored to like a specific niche. Um, then on top of it, all you've got now you've got multiple services, right? You're, you're building tests for, uh, what seems to be a fairly simple API involves, uh, you know, your flask application, if it's maybe written in Python and maybe you've got a redis cache and you've got PostgreSQL, and then you've got, uh, you know, some mail service. And Lord only knows you've got a full tech search.You've [00:55:00] got all of these things that are, that are running. And so being able to model all of those things is, is very hard.

Um, but I think that from a, from a user's perspective, the thing that is really hard about build systems is just that, how do I keep going all of this in my brain when I hopped from project A to project B, uh, when I moved from, even for me for a very long time, I have like most developers, tons of unfinished projects sitting on my computer.

Yves: [laughs]

John: I think we all do, right? Uh, and, and I say to myself, you know, I really want to add feature X to this thing. So I'll open up a terminal, hop in and I'll just be like, okay, wait, control our search through my history. How did I build this thing? Um, what, what tools did I need to download? Oh, that was a different computer, you know? And so, uh, and on top of it all, then when you go from local development to, you know, your CI system, to your [00:56:00] deployments, you for at least currently you oftentimes have totally different tooling.

So you have this configuration drift between, uh, how I build my stuff as a new developer, how I build my, my source code and run my tests inside of an automated system, how I, you know, package it and release it. And, uh, you know, our, and my hope is that we can, I'd love to tooling that basically takes all of that complexity and sort of narrows down the number of things that you need to, uh, to remember in order to be up and running.

So now at least when I work on a new project, I just hop in and I say, why build? I don't have to remember, Oh, this requires Python in a virtual environment. Right? That's automatically taken care of for me. Um, and so the other thing is that you get that feedback, right. Um, being able to build it in the CI system or in your, in your automated system, as part, your full process is the exact same as being local. Right. You don't have this works on my machine type [00:57:00] response. Right. I'm sure you've all seen the-

Yves: Yeah.

John: ... image like stamp works on my machine. Good to go. Um, you know, so it's a very complicated and very, it's always changing. It's an always evolving landscape and it is basically completely open-ended, there's almost no way to, to enumerate every single combination that people will come up with.

Yves: Yeah. And it's almost like that complexity, it's almost like a creeping vine. It sneaks up on you, you know-

Beyang: [laughs]

Yves: ... probably grows over time, and, when you're writing code, like the build system is never the thing. Right.

Beyang: Mm-hmm [affirmative].

Yves: The thing [inaudible 00:57:34] application and so it's kind of an afterthought and you keep tacking on these. Yeah.

Beyang: [laughs]

John: Yeah.

Yves: It's like you just like take something and like, Whoa, like when did this come into existence?

Beyang: Yeah.

John: It's to, uh, to quote, you know, Frankenstein's creator, right. I've created a monster.

Yves: And, and I, I actually love, like earlier, you mentioned that, uh, you know, some of your customers are using your tool to [00:58:00] actually discover dependency links that they didn't even know about. It's almost like you've gone beyond just like making the build faster. You're actually helping people understand what the actual links are in their chain. 'Cause it's, it's kinda easy to forget what those are over time. Like, wait, what, like that thing, uh, affects this thing.

John: Yeah. In fact, I, uh, this is one of the surprises of when we started, you know, saddling our product. Um, we, you know, Hey, here's this thing that we built, what do you think of it? Right. That's basically, you know, we went very humbly to is, is a gigantic, amazing company that we were trying to sell this thing. And we think that it's really useful for increasing build time for, for, uh, reducing, uh, build time. Right. And then, you know, people started looking at this and um, you know, can you give me this, uh, can, can you give me an API for this? 'Cause I have some ideas. Right.

Beyang: Yeah.

John: And then we started to figure out that, you know, Oh wait, actually you can do, you can [00:59:00] check test flakiness if you actually know your test results and you know, how they're evolving over time and which test depends on which, which co- yeah, which test depends on which code. And if you know, what libraries you depend upon, if you know where your library came from, that's probably good for security. So it, like we finding like interesting applications about the dependency graph that, um, you know, we, we didn't think about, uh, like finding the [inaudible 00:59:32] was, uh, an early find that was very interesting.

Beyang: Yeah.

John: But the more, um, like the more we get deployed on a more complex, uh, um, infrastructure is like, it, it, I think that approach now is to not try to guess what people, uh, what, what our system is useful for. Right? Like, Hey, we understand that this is an important [01:00:00] problem and software is complex and you need to understand the, um, relationship between different pieces of code in how your code, uh, is built. And how will you see that your code, uh, is working? That's like, what do we do really well, but he's like, we understand this, right. And here's, you know, information and, you know, we, we get, we will make it possible for people to figure that out.

And then, uh, we give them APIs and we give them ways to like, um, take that right. And to take it and run with it. So, um, yeah. So that's, I think that's, um, um, uh, uh, one of those surprise evolutions that I think that I think a lot, lots of companies, and I know that this also happened for, for Sourcegraph that one of those things that people use your, your, your system in unexpected, amazing ways that's, you know, for an entrepreneur is, is, is really nice to see. Right. Because he actually provided more value than what you thought you were going to be able to.

Beyang: Yeah.

Yves: Yeah. Users, user will always surprise you. Right. I, [01:01:00] I read an article recently from a person who was a sales, business sales rep at a startup, and they were selling us some sort of database product. I forget the name of it offhand.

Beyang: Mm-hmm [affirmative].

Yves: Uh, but they were having a hard time selling it. They, she would, I think it was a woman, they would fa- they would follow up with, um, they would follow up with customers to find out, Oh, Hey, you downloaded our product. How's it going? And a lot of customers would say, I haven't used that pro I like, I don't remember that. And they said, yeah, you downloaded it. You paid us $20.

John: [laughs]

Yves: Oh, Oh yeah. It was pretty neat, but it didn't solve my problems. But the story was such that they encountered one customer who was super excited and, you know, they, they loved the product. They said, this is the best thing, you know, we have this use case where, you know, it was a database product and we would send, I guess, sales reps into the field and they would be gathering information. And they had been using all sorts of, you know, CSVs and Excel files and whatever else, and [01:02:00] then trying to merge it back together. But apparently because this database was so small and embeddable, they put it into a little program. And so all of their sales reps out in the field could record all the information and bring it back and merge it. And the sales person was like, I never even thought, like we never thought about using it that way.

And there were a couple of times where that became a repeat pattern and then that became their product. They just went off in this direction of, this is what we're building. Right. Because that's what resonated so well with the users. Uh, so it's always fun to see how people use your tools and your product, um, in ways that delight them and are very surprising to you. Right. I'm sure Sourcegraph has similar stories as well.

Beyang: Oh yeah, definitely. Well, actually seeing, as we're almost out, of ti- uh, a time now, second to last question for both of you, uh, you know, if there's someone listening out there right now who is working inside a [01:03:00] Google or an Amazon, or, you know, just any development organization and there's some tool, or there's some part of the developer experience that they see in that organization that they want to bring to the rest of the world, what advice would you give to that person?

John: That's a good question. I think that it depends on what first thing is, talk to people before you assume that the thing that is used internally is going to be needed outside. That's one of John's mantras, right? That like most people don't actually have Amazon's problems. Right. So I think that, that's an interesting thing to keep in mind. Um, like if, if I think that if you have energy, that information, that, that insight about something that you think other people will find useful, um, and you want to either, uh, um, start your own company or [01:04:00] have, um, let's say an open source project within, um, from within the existing company where you want to open source that project that I'm getting to the hands of more, more people. I think that I think the most important advice that I would have liked to hear, um, earlier on in, on my career is that the most important thing that engineers should be doing to, to really make their, their work successful is to actually go and, under- understand users, go talk to users.

Beyang: Mm-hmm [affirmative].

John: And, um, really, really figure out that, uh, if the problem that you want to solve is a problem that they have a maybe invert the equation a little bit and ask what are their problems and, and go from there so that you don't, you don't waste time, uh, packaging your internal project into an open source that is not super useful because maybe you learn that if you make small changes in your launch it with a different messaging, you know, if you're launching to, with a different deployment model, um, or so, or so [01:05:00] you, you get more success or maybe it's okay for your company to ship that as a service instead of a, instead of an open source software.

And, um, and for people that are thinking about starting companies, it's very useful to reach out to other founders. I definitely talk to, uh, Beyang, uh, [Ann Quinn 01:05:17] very early on through like, Hey, what is this state? What is this the extent of your company? How do I do that? Right. And I think that it's incredibly useful to, if you're thinking about certain company, reach out to all the founders, uh, they're like they have so much, they have scars that they know they want other founders to not have the same scars. And, uh, so, you know, um, and there are many problems that you can anticipate if you, if you're thinking about that.

Uh, and, uh, my last is that in general, I think it's a really good idea in general, when you see that there's a thing that is used internally, that you think could be used outside. That is a very good pattern. I think that don't, I don't think that's [01:06:00] a bad pattern, pattern at all. Um, and I think because you've seen that gaze, and maybe your company's a little bit further in the future than other companies, and you think that other companies are like the outside world is going to catch up. Um, so that's a good pattern. So you should definitely look into that.

Yves: I think, um, I think similar to that, my, my perspective is also don't, don't wait to get feedback, uh, make sure that I think one of the things that we've learned is nothing is perfect. It's okay to start getting feedback from people and you need to get it earlier on before you've gone too far off of the rails. Right. Um, so I think getting that feedback from users is critical. I also think that very much echoing Evan's point that going out and finding people who have the same problem and getting to understand where they're coming from. Uh, and then also [01:07:00] once you do launch it, don't necessarily be tied to it ending up a certain way, right? It will evolve on its own in a lot of ways. And I think that it's important to embrace that.

Um, you know, not to like chase every little thing all the time, but-

Beyang: Mm-hmm [affirmative].

Yves: ... to follow the trend, right. If people start using or using a particular part of the product the most, right? I think that you should listen to your customers and your users. Um, because at the end of the day in us, that's who we service is the people that are using our tooling and our goal is to make them to be happy developers, right? Um, making their lives better. And so I think definitely getting out there and, and getting people's reactions, getting people to use it is very critical.

Beyang: So my final question is if someone's listening to this and is interested in trying out YourBase, how can they get started?

Yves: I think the best ways for them to go to YourBase.io to learn more and follow the steps from [01:08:00] there, we will be very excited to hear what they think. We are on Twitter too. So reach out and let us know what they think.

Beyang: Well, my guest today had been Yves Junqueira and John Ewart. Ewart and John. Thank you for being on the show.

Yves: Thank you, Beyang. It was great.

John: Yeah. Thanks. It was a real pleasure.