Yes We Can

Awesome. Hi, everyone. Welcome to this week's episode of Yes We Can. I'm super excited to have Jean here. Hi, Jean Yang. Welcome. Welcome to the show. Thank you. Thank you. I'm super excited to be here. Me too. We have so many things to cover. We have PhDs, computer science, founder, building an amazing company. I can't wait to talk about all academia. There's so much to cover. So just a couple housekeeping things. If the audience have other great guests they want to see on the show, please email me at yeswecanatCloudflare.tv. I love getting your suggestions. I read all the emails I get. So thank you so much. And if you have a question for Jean, you can put it in the little question Q&A spot, and I'll do my best to get to it. But let's jump in. Not jive in. Jump in. So Jean, you are the CEO and co-founder of Akita Software, which is what you're currently doing. And so I thought you could start by sharing with the audience. Tell us about your company. What does Akita do? Yeah. We're building what we call one-click observability. So the trend is this. There's the rise of SaaS. There's the rise of microservices. There's the rise of APIs, which means that any team can, with a click of a button, just call an API, deploy new functionality into their system immediately. And it's great because very small teams, very under -resourced teams, all kinds of teams can access all kinds of functionality very quickly. Everyone can build anything. But the flip side of that is programming, developing tools haven't caught up. So the world I come from is programming tools. I was working on application-level stuff. And that's very much like, let's help you understand your code. Let's help you and the editor do stuff. And today, most software is this ecosystem of your own services, other services that you're calling, everything playing together, more of your own services than ever before. And this part of understanding what's really going on hasn't really caught up in tooling at all to the pace of everything else. And so there's an emerging space observability that helps developers understand, this is what's going on with your programs in production. This is what's calling what. This is how it's calling it. This is what the throughput is like. This is what the errors are like. Here's how to think about it. And so far, what we learned was that a lot of these tools are still for the advanced user. So therefore, if you are a DevOps expert and you know exactly what you want to profile, these are amazing tools for creating exactly the dashboards you want and exactly the kind of profiling you want. If you're trying to optimize P99, your 99th percentile latency, tail latency of your software, you can trace that to every inch of its life and fix it. But what we learned was there are all these other developers, maybe they don't even have a DevOps expert on their team yet. Maybe they're just getting started and their website doesn't need to be that fast. Maybe they've been around for 20 some years and their website still doesn't need to be that fast, but they have millions of users that they're actively serving. They're actively improving their software every day. And for a lot of these developers, they've been left behind by today's monitoring and observability tools because they're like, look, we don't even know where to start sometimes. We have a bunch of stuff. We don't know how to monitor it. We don't know how to get started. And so one analogy I like to make is just like the low code movement made it easy for people who aren't programming experts to quickly build systems, we want to make it easy for people who aren't ops experts to understand what's going on with their systems, quickly find what's wrong, quickly figure out what changes they actually need to pay attention to. And how we've been doing it is in a way that I think is really cool. So we had a few user principles there. So we want a drop-in, completely drop-in solution so people don't have to change their code, they don't have to update their code, they don't have to include any library to use us. And then what we've been working on for the last few years is how do we help developers understand their systems better with insights? So we've been watching their API traffic and building algorithms to automatically understand that API traffic. And so we've been trying to deliver insights on what is my traffic? What is it doing? How's it changing? What should I pay attention to? So yeah, it's been super fun because it's a completely new kind of product serving a developer base that I feel very connected to. I'm what we call the 99% developers, like everyone else who doesn't have a lot of resources necessarily. And yeah, I've been having a lot of fun. That's amazing. I love so much of your passion and what you're saying. Obviously, you can tell you're excited about what you're doing, which is the best part about talking to founders. Everyone loves what they're doing, which is amazing, is this idea of taking something that was expensive and not accessible to everyone and making it easy and more accessible to everyone. And I think that that's something that really resonates with me because we did the same thing at Cloudflare, where it was just something that wasn't accessible and we made it more accessible. Something expensive made it more accessible, both technically and a budget perspective. And there is something so rewarding and satisfying about that. And it feels like it really comes through in your comments as well. Thank you. Yeah. Cloudflare is a really big role model for us, like how you guys manage to reach so many developers, how you guys have grown. Yeah, that's amazing. Okay. So you're clearly helping bring observability to every single development team out there, small or large, which is great. And how's it going so far? Maybe give us an example of some of your customers or types of teams that could check out Akita. Yeah, absolutely. So we can't talk about all of our customers publicly yet, but I can talk about a couple that are already on our website. So that's allowed. So one example is Flickr. We were recently on their blog. And so they're in this under-resourced engineering team category for the reason that their software has just been around for a really long time. So I remember when Flickr first came out, it was 20 some years ago, and some of, or yeah, I think a little less than 20, but early 90s, Web 2. And some of that code is still around. And many, most, if not all of the people who originally wrote that code, they're no longer around. And so they first showed up to us and they're like, look, we want to understand some pretty old code and we still want to move fast. Our engineering team is, we're a modern engineering team. We're still shipping features. We serve quite a large population of users every day. We have an API, we do stuff with them, but we also have stuff that, you know, they were written by ghosts. And so we love that because we were like, cool, we're fans of Flickr. If we can help them move, move fast, that was good for us. And so what we've been helping them initially with is just understanding, okay, what's going on? Because a big part of what we're able to do is just drop into systems black box and watch API traffic using a technology called eBPF. BPF stands for Berkeley Packet Filters. We watch network traffic on the network. There are other solutions that watch network traffic. None of the other ones will actually take that traffic and model it. So we watch their traffic and then we say, okay, these are the API endpoints we saw. Here are the types we saw. Here are the structures of the endpoints we saw. And then what we're building now is letting them set up monitors for this is what I care about. Tell me when it changes. And so for us, it's really rewarding because I think there's something really just for all people, very pleasing and helping someone clean up something that seems like a daunting and possible task otherwise. But then once that baseline is established, we can help them move faster by setting up high level monitors on their systems without having to excavate into their code or do anything like that. And so that's one profile of user. We also work with newer, more modern companies. Well, Flickr is very modern, but companies that don't have that legacy code, because for any company, the minute you ship your code, you have its legacy. And so especially for a newer, faster growing company, you're trying to move fast. You don't necessarily have the DevOps experts in place. There's less of a baseline to establish, but you want to know when things change. You probably don't have the monitor set up for when things change in a way that you don't understand. Because right now the state of the art for most of the companies we're seeing is they're reading logs or trying to look at the monitors they've set up on other tools they have, which are often incomplete. I see tweet threads all the time. I had this bug. I spent a week figuring out what it was. Then I set up a monitor. So if I ever get that bug again, I'll catch it. What about the next bug? And so for a lot of these earlier stage, younger companies, what we're trying to help build up is a vocabulary of like, here's what you can get started with. We'll catch a bunch of things that you might care about for you in the beginning. I love it. It's like you're bringing order to a lot of chaos. You're doing such a good job describing. We all have been in that situation where you wrote something a long time ago. And in this case, it's code. Those people aren't there anymore. You're like, wait, remind me why we did it this way or how we did it. And the fact that you can help just kind of put structure around it is almost like it makes me exhale. I feel like my stress level comes down just thinking about it. Like my bring order to a messy room or something. Yeah. Same. I mean, that's been my career basically. There must be a way to bring more order to all of this code. And yeah, the Flickr case is extreme. There are other companies that have come to us with decades old code bases. And you can't ask the person who wrote it anymore because they are long gone. But in many cases, the person who wrote it, even if it was last week, they may not remember. You don't have that conversation. What then? But yeah, for me, it's like, well, everything runs on software. So why not make it more reliable and make it easier to update? I love it. That's great. Well, clearly you're very well suited and passionate. How did you come up with this idea? So you're clearly passionate about it. Where did you come up with the idea to decide to start Akita? Yeah, that's a great question. It really led out of the research I was doing previously. So I was a professor at Carnegie Mellon. And before that, I was a PhD student at MIT. I was the whole time working on this exact thing, as you described, bringing order and structure to chaos. And so I had grown up around software. Both my parents were computer scientists. My uncle is a computer scientist. There was a lot of software creators, people working with software in my family. And so something I noticed was that they always complained about the tools and how unreliable everything was. If my parents worked late or I would see people in my family working late, it was always because there was some bug. And they didn't realize it was there. And they caught it too late. It just seemed like, man, life could be way better if we catch these bugs sooner for me as a kid. But yeah, so it really was very appealing to me by the time I got to college to study how can we build better tools for software. The other thing I was seeing was more and more things were running on software, but people weren't really thinking about software as part of infrastructure. They think of it as buildings or bridges or things like that. But all of my friends were starting to get on Facebook at the time that I was trying to figure out what I wanted to do with my life. I was seeing all of us were getting smartphones. And so I was like, I think that if people encounter bugs at the same rate my parents did when I was growing up, this is not a good situation. And so I became very passionate about how do we help create tools to build more reliable software. Initially, I thought it would be software at the application level. So I was really drinking the Kool-Aid about we should build better programming languages. That's where the innovation is going to be. Over the course of grad school, I realized that programming languages are just a small part of it, that our tech stacks are like these ecosystems. They're like these rainforests. There are so many pieces. They're so heterogeneous. And so that's how I got really interested in, one, how can we watch these systems and actually help people, communicate back to people what's going on. Whereas programming languages are like we design a language, we design a program. It's top -down, planned garden. We have control of everything. So that was the first thing. And the second thing I realized was it's really about all of the components and how they fit together and not just the application layer or the database layer or the web front end. There's so many pieces. And so that led me to observability because I was like, who's watching everything together? The monitoring and observability people. And then my initial vague dream was, well, if we could design abstractions the way people design abstractions for programming, for understanding these systems, everyone would be much better off. And so it was step-by-step that we came upon this specific thing. But yeah, I guess the point for me to decide to start Aikido was I realized that as a professor, I wasn't able to have this direct access to customers and user data and things that I would get in a company versus academia. And I felt that you can't really innovate on this if you don't have the right data. Yeah. That's so interesting. Well, it's amazing. Again, you just think about how there's such a thread through your life. There were so many things that added up to this passion for like, now's the time. Because it's hard to start a company, especially you left a great job, which we're going to talk about right away. But you do such a good describe. I love that you described tech stacks as ecosystems. I feel like that should be, there's something really elegant in that. And I will just add your point around how you had many family dinners interrupted by a bug that your parents had to go solve. I feel like building Cloudflare, a lot of my family dinners have been interrupted by bugs and that it causes a fire drill for the rest of the students. Yeah. Your kids are going to go into DevTools. I love it. I never thought of it that way, but I think you're really, now that you bring it on, there's a light bulb going off. Okay. So let's just, I want to make this point around how, so you have your PhD from MIT, which is an incredible institution, a PhD in computer science. And then you were working as a professor at Carnegie Mellon on the tenure track, both, which are incredibly difficult things to do. And so I wanted to spend a little bit of time talking about academia. And now you're building these companies because with customers and data, which really makes sense, building the solutions, but just what was it like being a professor at Carnegie Mellon? I think there's some folks who are like, might think about wanting to be a professor and you're the first professor I've had on the show. So I'd love to hear, what was it like? It was really fun. I think what drew me to grad school, I went to grad school for two reasons. One was I knew I wanted to work on programming tools and what was going on in industry at the time, wasn't exactly what I wanted to work on. But the second thing was, the thing that makes me feel the most alive is working with people who I think are smarter than me, who I'm learning from. And both grad school and being a professor were great places for that. I love feeling really intimidated by the intellect of people around me. And I just felt like when I was at Carnegie Mellon, they would want me to say this, it's the best programming languages department in the world. And we had some other competitors. And so we're like, man, US News said, this is like co-top. And we're like, no, no, no, no, we're at the top. But these were, like a lot of my colleagues at Carnegie Mellon were people whose papers I had read when I was coming up as an undergrad, as a grad student, Frank Fenning, Bob Harper, Carl Crary, John Reynolds had been in that department. These names probably don't mean anything to any of these people who aren't programming languages people. But I had read their papers when I was learning about programming languages theory. And I was learning about programming language design. And so it was really incredible to be in a department where I was in faculty meetings with these people. We were in area meetings with these people. We were doing grad admissions together. We were potentially co-advising the same students. And so it was really, really exciting from that point of view. And CMU obviously is also just a really good school, really high admission standards. And so the students were really incredible. And I had a group that was mostly undergrads by the time I left, actually, just because every year you admit a couple of PhD students and you don't have like, I was there only a couple of years. So you don't have quite a stable of grad students in the first couple of years. But three of the undergrads I worked with, actually, I think they took the minimum course requirements for their entire senior year. And they'd spent most of their time doing senior thesis with me, which was super fun. And one of my students actually stayed through the summer with me to work on projects. And I loved being able to introduce them to a less structured way because I feel like courses are one way to learn. But I actually always learned much better hands on and getting really deep into something. And that was one reason I loved grad school. But I really liked being able to give them the experience of just like, let's forget classes for a while. Let's go really deep on this. Let's build something cool together. And then a couple of, so one of the students, actually, the work finally ended up in a paper that got published last year at one of the biggest systems conferences, OSDI. And then the other student actually worked on something that was potentially publishable, but the timing didn't work out. I left academia. They went on to grad school. But there were some really cool projects we worked on. And I think my favorite part was that these students love their projects so much that they just, they're like, our parents are paying for all these classes, but this is actually the better educational experience for us. I love that. Well, it's a little bit like the application going deep. And it's so interesting. I think one of the myths about computer science programming software development is that it's kind of like a solo track, but you're making it sound so collaborative, so team-based, collaborative. Oh, yeah. It is absolutely collaborative. I had a tweet just before I came on here, actually, because someone was saying, I don't like the term superstar researcher because research is such a collaborative thing. And I think that I will say, I was not actually the most collaborative researcher. I was the primary PI on a lot of my grants. I was the only PI on some of my grants. But I think even if you're not directly working with someone on a research project, just who is around you is so important. Because if you have no one around to give you feedback on your ideas, or even for me, just seeing other people who are operating at a high level and doing their thing, even if we're not directly working on the same thing, that's always been very inspiring. That energy is contagious. And so there's that. But yeah, also, most of research, there's a basic collaboration built in. Because a lot of research is this mentor-mentee model, where it always involves a junior researcher doing something with a more senior researcher. And so yeah, for your PhD, even if you have the least collaborative PhD, you're working with your advisor. And so yeah, I would say it's never one person locked up in a room. If you're locked in a room by yourself for your whole thing, I don't know. In school, we watched a movie of Andrew Wiley, who proved Fermat's last theorem. And they just showed him in his attic every day. I would say, if that's how you're doing research, especially in computer science, you're probably doing it wrong. You should probably go talk to some people. But yeah, I think the community aspect has been really, really key for me. I'm feeling like I'm getting a lot, and not just like, this is sucking out all of my ideas and giving me nothing back. Yeah, it's the collaboration, the community. I love that too. It's not a brilliant genius. It's working with others. I think there's something like that. Yeah, even if there have been stuff where I've been the main person working on it, I'm the main person working on it alone. But it's like, who are you having lunch with? What are you talking with them? Who are you showing your drafts to? There's always someone else. And if there isn't, I don't know. I just don't see how you can do great work that way. You're capped. Yeah, right, right. Well, I love it. You're doing a good job giving us an insight into what it's again, some of us haven't. So it's like, as you say, you're like, actually, that makes sense. So yeah, thank you for bringing awareness. What about getting your PhD at MIT? Another amazing institution, again, a PhD in computer science. You're a woman. I mean, there aren't that many women getting their PhD in computer science. I'd love to hear about, did you love your PhD program? What did you like about it? What was surprising? Yeah, I had a really good time. And I think that it was in part because I consciously decided I'm going to have a good time. This is what I want. And I'm going to set myself up to enjoy this. And I think I had been nervous because I had wanted to go to MIT for undergrad. I'd gotten in. And my family was worried because so many people said MIT is not the place for a girl. It's a really tough place. The male to female ratios are not good. Maybe you want to go somewhere more well-rounded for undergrad. So I didn't go to MIT for undergrad. And I had a good undergrad experience still. So I'm fine. But I think that for grad school, I was like, you know what? I'm ready. And I had a professor who had gone to MIT who was a woman. And she was like, you know what? It's a very lonely place to be a female PhD student because whatever ratios you have for undergrad, they're even worse gender-wise for grad school. MIT just generally has a reputation for being a tough place. MIT computer science has a reputation of being extremely sink or swim. So those are not the reasons I decided to go. But I was aware of all of these things going in. I think for me, when I showed up to MIT for my visit day, I was just like, this has an energy like I've never seen before. The professors presented their research. And they actually only had three minutes each. And there was a gong at the end of the three minutes where they had to move on. And just like the level of energy and enthusiasm and excitement, I was like, I don't feel this anywhere else. And this is where I want to be. And so I think for me, I was like, OK, if I want to be here, what does it take for me to be successful here? And I know that I need to feel good energy from people around me. And I need to feel like I have a community. And I will admit that initially my first year, I didn't have that. Then I built it. So there were two aspects of community that I helped build when I was at MIT. First was there were a lot of people doing programming languages research and software engineering research and compilers research when I got to MIT. But people didn't really talk to each other across the groups. And so my second or third year at MIT, I actually worked with a professor on organizing an annual retreat where we got everyone working in these groups together. And everyone gave presentations. And I started organizing weekly seminars. And I made a mailing list of the people in my cohort who were in my area. And I feel like that was actually super key to me having a good time. Because I think that a PhD is very, very lonely. You're actually working on stuff alone most of the time. You have maybe a weekly meeting with your advisor a couple of times a year. You do a paper. You work together for a week. But it's very, very lonely otherwise. I saw a lot of people become depressed, drop out. I think a lot of people don't say it's because of isolation. But I think isolation has a lot to do with it. And so for me, actually, community in that one piece was crucial. And then the other piece was I helped cert graduate women at MIT in my second year. Because I was like, I had no female friends at all in my program after the end of my first year. There weren't other women in my specific area. I think there were only like six to eight of us total in our year in a program of 80 plus. So they were working on very different things. Some of them I would have lunch with every once in a while. But it wasn't like we were close. And so I helped start graduate women at MIT actually off of an email I got. Someone said, I want to start this organization. And we met. And I was like, yeah, I want to do it with you. And she became one of my best friends. But yeah, we went down female sounding names of every department, found all of the women across all of the departments, ended up starting a multi -thousand person organization. We were running two major conferences a year with hundreds of people helping us by the end of it. That's so amazing. Jean, it's awesome because you're obviously like you loved computer science. You wanted to be a PhD. Even though people were kind of like, you shouldn't go to this school. You're like, no, I see something here. And you really are portraying how much you loved it. And it doesn't mean it wasn't without challenges. But then you were like, I'm going to go fix those things that I don't like about it and turn it into a, it's very inspirational. I have goosebumps listening to you speak. It's one thing to kind of talk about things, but you like literally went and did it. Thank you. Thank you. Yeah. And your point about bringing your community together for the women, like the women, the graduate women at MIT across all the different fields that really resonates with something that we saw at Cloudflare. I don't know if this like in a business setting, just to apply the same sort of what we saw was in the hallways, there was lots of women at Cloudflare, but within teams, it wasn't evenly distributed. And so when everything went online during COVID, all of a sudden there's there when our team were like, I don't see women anymore because everyone I'm working with and people like you is so important. So important. And so it was a little bit, one of the things that ended up happening internally, like we kind of did something a lot of our technical women kind of just created community, even if it wasn't on projects they were working on, but just to have that peer see people like them and that made things better. And so I think that's a good insight that lots of teams and companies as well as universities can learn from. Yeah. Yeah. I mean, what was happening before was departments would have women's groups, like every couple of generations, and then they would fizzle out because, you know, there would be a period where there'd be like one or zero women in the department and like the one or zero women weren't able to take on the mantle. And so having, having a school-wide, you know, lasting organization really, really seemed to help. Like they, they fired the women's representative just before we started the group, because they said no one is using our resources. And we said, that's not because people don't need the resources. It's because no one knows. Right. Well, gosh, it's so complicated. Okay. Well, okay. So we have about a minute and a half left. We could talk for hours. I can go on. So there's one thing I want to ask you. So you're a technologist and you're clearly love this, but how do you stay up to current of everything going on? There are so many trends and technologies and programming languages. What do you read or what advice do you have for the group? Yeah. I think that I'm, I guess my one thing is like, I think I do actually do a pretty good job of staying current. I have a few Twitter lists where I'm just like, okay, this is who to follow. You know, there's a, there's, there's like a few publications I'll follow. I have a lot of conversations on the ground with developers, but I think that a lot of people women, especially feel that they need to read everything before they dive in or, you know, I need to completely understand this thing before I can have opinions about it. Or I, you know, I haven't read like all of, you know, whatever publication I haven't read everything on hacker news today yet. So how can I be, how can I, how can I talk about anything? And I think that there's like, I would say, you know, yes, a lot of stuff is happening, but a lot of my opinions I formed by just kind of like talking to people and then like thinking about it. And this is my opinion. Now I'll validate it with a few things. I'll, you know, I'll read a few like expert publications to be like, is this the right thing? But I think a lot of a lot of the perspectives I've developed that people have appreciated because they're not the standard perspectives I gotten, not from starting at the same starting point as everyone else and reading the same things, but from just thinking about what I'm seeing, if that makes sense. Totally amazing. What's your Twitter handle for the group? It's Jean Casor, J E A N Q A S A U R. Amazing. All right. We're out of time, Jean. We'll have to have you come back. Good luck with everything with Akita. Yeah. Thank you so much. Thank you for having me.