Cloudflare U: Workers & Magic Transit

So I want to first off thank everyone who's tuning in, all the students that are interested in learning more about Cloudflare and also the new grad applicants. We're so excited you're watching. Today will be a great episode of Cloudflare University. We have Nick Wondra and Aly Cabral here and they'll be discussing workers and magic transit. Firstly, I'd like to introduce myself. My name is Ellie and I've been on the recruiting team here at Cloudflare for the past two years. I help run the intern program and I also help with recruiting university students. And with that, I'll let Aly and Nick introduce themselves. I think we can start with Aly. Sounds great. So I'm Aly Cabral. I'm the director of product for workers, our development platform. So including serverless functions and a KV storage, and we'll get into some more of that later. Yeah, thanks. I'm Nick Wondra. I'm an engineering manager here at Cloudflare. I currently manage the team working on the magic transit product. I've been at Cloudflare for about four and a half years and both at Cloudflare and previous in my career have really spent the majority of my time working on building software that helps make networks faster, better, more reliable. Really excited to be talking to you all today. Awesome. Nick, I had no idea that you have been at Cloudflare for four and a half years. I thought I have in two years, but you must have really seen a lot. Yeah. I mean, it's been an incredible opportunity to join Cloudflare when we were about 250 or so employees. And now I've lost track north of 1500 or so, I think. And so it's been a really awesome journey to kind of see the growth and trajectory and also what's remained consistent in our mission and how we approach building products and shipping new features and enabling our engineering product teams to really do their best work. Absolutely. Well, thank you so much, both of you, for being here today. I'm really excited that you're on this episode. I think we should start off by talking about, because we're speaking to a student audience, just talking about both of your academic careers and kind of your experiences post-grad that led you to Cloudflare. I know, Allie, you have a unique background as well because you didn't know you wanted to be in product management right away. So I think we should dive in. I'd love to hear more about that. Yeah, sounds great. So I actually got my college degree in mechanical engineering, so not in the software space at all. Yes, in engineering, but really only took a couple of formal coding classes at university. I was interested in just knowing how the world worked. I chose mechanical engineering to tell me mostly just how the things around me functioned in a broad spectrum way. I wanted to know why toilets flushed the way they did, just very curious about how the world worked. But the computer actually stayed pretty magical for a bit of my college career. I ended up doing a lot of side projects to get more knowledge that I wasn't getting in classrooms about how to build software. I did my college's mobile app challenge. It was a nine-month challenge where you actually built a mobile app for a specific goal. You came up with the idea for the mobile app. In my case, it was an event posting student mobile app for our university and then allowed people to say if an event had free food, of course, because you get more attendees when you have free food at college events. But in that world, it really gave me a taste of the power of building software. In the mechanical engineering realm, to take an idea, a new idea for a new piece of hardware or a new thing in the world and run with it, you had to have a lot of capital. As a student, you don't. You don't have, or in my case, I did not have the capital to start up a company that's focused on building a thing because I had no idea how to get money to build that thing. Even if I had the greatest idea in the world, I would, first of all, have to have a lot of confidence in it to spend someone else's money if I was to get investors or have the money myself, which I just didn't at the time. Software gave me, as a student, power to execute on my ideas, and that's really what gave me a taste of the space. I ended up getting a mobile developer job out of college with a mechanical engineering degree and all for working for IBM. Then, having been a software engineer for a couple of years there, I actually started getting more of a taste on what it meant to be a product manager in the space. I did that just by working with my team. At the time, the product manager on that team, to just understand what the role was, again, naturally curious person, and then started gravitating to some of those responsibilities on the team myself. The product manager knew I was interested and just learning a little bit more, started giving me some tasks that would help me grow in that area. Eventually, my manager came to me and asked if that's something I wanted to try. At first, I actually wasn't sure. It's one of those things that you're told you can always get less technical, but you can never get more technical in your career. That's something that people tend to tell you, so I was very cautious about making the step into product management because I didn't know if I would like it, and I didn't know if I would get to go back to engineering if I didn't. I actually ended up trying it for a bit and working with my manager to say, if I don't like this, I want to go back to engineering, but then I've never looked back since. This is a role that gives you a lot of freedom and creativity to decide what we build next, work with customers, do a lot of interesting work. I think both career paths I could have been equally happy in, but this is the one that I was led down just by the circumstances of my life. I could have easily been in manufacturing designing wine bottles because that wasn't my other job offer at the time. Well, I love that side project that you created, something to tell students when there's free food. Of course. That's genius. That's great. Thank you so much, Ali. Let's hear from you, Nick. Yeah, sure. I actually sit in our office in Champaign, Illinois. We're a couple hours drive south of Chicago, so why does Cloudflare have an office in Champaign, Illinois? That's really what brought me to Cloudflare or me coming to Cloudflare helped found that office. My background is I went to school at the University of Illinois, which is in Champaign, Illinois. When I graduated, I had a lot of family in the Chicagoland area and close by. I was thinking I might move back up there and get a tech job in Chicago, but when I looked around at what opportunities existed right here, this is a really prime university for computer science and a lot of other sciences and engineering disciplines. There's a small ecosystem of a bunch of tech companies, mostly Bay Area tech companies, who look at that opportunity to grow technical talent out of a satellite office really close to a university. I had a lot of really amazing opportunities to stay relatively close to family, relatively low commute time, all that stuff. It's a great community to be living in and I had a lot of really interesting tech opportunities here. I graduated with a bachelor's degree in computer science and actually a bachelor's degree in engineering physics. I haven't really used my physics training at all. I went into a computer science job right out of school and I knew that I was going to do that, but that sort of cross -training in a hard science and especially something like physics where there's a lot of emphasis put on building mental models and asking questions of those models and scientific rigor, I think that really helps reinforce a lot of the skill set that you want and need as an engineer and I think especially going into the networking field. I actually kind of stumbled my way into jobs in networking. My first job out of school here in Champaign was as a quality assurance engineer with Riverbed and I just happened to know someone who I went to school with who got a job there and said, hey, you should come work here and I didn't I took a networking class in college, but I didn't really have a direction of where I wanted to steer my career. There was a small office here in Champaign for Riverbed and it was all quality assurance engineers and as that office grew, I was able to grow my career alongside that. At a certain point, we had enough people here to say, hey, let's form a development engineering team here and I stepped into that role and then when we had enough development engineers, hey, we need a manager here and I think similar to Allie who described she had managers and leaders who created opportunities for her and pointed her in a direction maybe she wasn't even steering herself, I was really fortunate to have early managers in my career who pointed out, hey, you've got some of the aptitude and skill set and seem to really enjoy the type of work that comes along with managing a team of engineers and this is something you should consider and that really kind of steered me on that path. So I was at that company for about seven years, stepping through those sort of different roles and kind of seeing a lot of different stages of the engineering process all while building products that focused on network optimization and I learned a lot about how to think about and debug and build software that really solves some of the fundamental problems of networking. I left Riverbed to join a small startup in the network security space. I had a connection with one of the co-founders and so myself and two other engineers I had connection with started a small satellite office of a really small company. We were only eight people but three of us sat here in Champaign, the rest of the company was based in Mountain View. So we did that for a while and I was at the company for about a year and we were, you know, series A funded but kind of got to the end of my year with them and we weren't making market fit, like there were other other companies in the space that were a little bit ahead of us and we didn't, we had tried a couple of different unique perspectives and our founders made the wise choice of like we still had money in the bank but like we didn't have a perspective that made sense for like how are we going to make a difference in this space, like why is our perspective and our capability unique enough that like why isn't that other company just, they're going to do it, right, so why would we try and do what exactly what they're going to do and so they made the wise decision for us to close shop and while there was a hard process like that's what ended up leading me to Cloudflare. Myself and the other two engineers here in Champaign, we kind of all thought, you know, we want to stick together and kind of continue to work together as a team and Cloudflare is one of the companies that we talked to about acquiring our startup and actually our startup didn't come to a deal with Cloudflare, we ended up walking away and interviewed a bunch of other places but kind of at the end of that process myself and my other two colleagues here in Champaign thought, you know, we really like Cloudflare a lot more than these other places we might wind up and so we went back to Cloudflare and said, hey, like would you hire just the three of us outside of acquiring our startup, just hire the team of us and Cloudflare took a risk and, you know, formed an office here around us. So I joined Cloudflare again about four and a half years ago and spent the first couple years here building and growing and scaling what's now Argo Smart Routing, again, you know, focus on network optimization and making, you know, this incredible footprint of the Cloudflare global network using that to make our customers' traffic move faster than what the Internet can do on its own and then, you know, as that product matured, had an opportunity to step in and help lead the direction of what's now Magic Transit. That's great. I'm so glad that you said that bit about Cloudflare taking a risk and how it paid off in creating the Champaign team and Champaign office because I think a theme of workers and Magic Transit is how Cloudflare takes these risks and it really pays off. So, yeah, thank you so much, Nick. I think that we should go ahead and get started. We have about 20 minutes, so I want to dive in. So, Allie, I want to hear everything about workers from a perspective of a technical student that doesn't know much about workers and Cloudflare, you know, what is workers and what's the origin story? Sounds good. So, workers started with an internal need, right, to build applications faster and that turns out that's a common need across all developers in the industry, right? We want to build things. We want to move quickly and a lot of serverless platforms. So, serverless basically, in general, means you don't have to worry about how many servers are powering your application logic. That is completely abstracted away from you. You can just deploy the logic and then the provider, like the cloud provider or us in this case, decide how many machines or resources it needs to run the workload you throw at it. So, that's what a serverless platform is. Workers allows developers to work on the code that matters without worrying about the boilerplate. So, often, the code you write for one user looks a lot different than the code you write for a million users. And why is that? It's not because the nugget of that business value changes. It's not because the idea changes that much, but there's so much stuff around productionalizing software that is hard, like knowing how to load balance workload across those million users, across multiple machines, knowing that you're using security best practices, knowing that you have high performance and are optimized to handle those workloads that are thrown, knowing how to scale up. All of that is a lot of boilerplate that is not actually adding to the value of your application, but is necessary to get online so that your users can use the application. So, Workers is built with the mission so that the code you write for one user looks a whole lot like the code you write for a million users, at least from the infrastructure perspective. Kleffler has built this great suite of products that make your applications faster, that make your applications more secure, that make your applications more reliable. And with that, we can offer a platform, a serverless platform, that out of the box has that baked in. You don't have an extensive add-on to get your thing online for millions of users. Instead, you get a usage rate, and that rate is consistent across all workloads you throw at it. So, really, it's a platform, like I like to say, it's a serverless platform you do not have to graduate out of, right? It's not something that you need to do your toy project on, but then actually, when you have real load, go move that someplace else. The unique perspective, the mission here is that production behavior is built in. That sounds great. So, about the Workers team, can you tell us what the team look like, or what does it look like, where are you all located, and what is unique about the team and exciting to be on this team? Sounds good. So, we have team members that are spread across the globe. We have someone moving to the Lisbon office, we have folks in San Francisco, though the large contingent of the team is in Austin, which is where I am. There are definitely individuals that are spread across the US and the world. I just hired one of our new intern who is going to be out of Washington. So, we're definitely, this is rapidly evolving, right? We think about where people work in this time, but there's definitely the majority of the Workers team is in Austin. Now, how the team looks is that we have three engineering managers across the team and an engineering director, and they have independent engineering teams, and those pair with product managers, and then we also have designers on the team, and then product marketing folks. So, there's a whole extended team as well, but that's basically the rundown. The core Workers team is about 30 folks at the moment. Great. And so, for a new grad, why do you think, you know, why would they want to work for Workers? Like, why do they want to work on Workers? What's exciting about this? And, you know, how do you see someone coming in who's recently graduated or even an internship, how do you see them making an impact? Yeah. So, we had interns last summer that made incredible impact. So, one of them was mine on product management, and he focused on so many things. One of those being digging into our user data and deciding what are key indicators of future growth. For example, when a user adopts KV, are they more likely to grow at a faster rate after they have that adoption? Looking for kind of indicators like that. Oh, maybe they're using this secrets feature in Wrangler. Does that mean they're going to grow faster? And starting to, like, take the data science of that and try and come up with some theories, test them, and figure out where those nuggets are so that we learn how to build better, like, make better decisions about the future work and where we want to invest going forward. So, that is a very impactful project that an intern just took and ran with and delivered way more than we could even imagine. So, that in and of itself is incredibly powerful. There's such a broad space here for Workers. There is so much work to do from the product management side. Refining that work with data is incredibly important for us. And then on the engineering side, there are tons of great projects. One of them was revamping or, like, working with the team to revamp some of the documentation and, like, how our users interact with the documentation. In developer products, as this one is, documentation is an extension of your UX. It is how developers interact with your product. So, taking that and, like, doing user testing, figuring out how, like, what gaps there were and how we needed to respond to that is incredibly important and also really nice to do with fresh eyes, right? You don't get those fresh eyes for long. Mine are very stale now. Even only nine months in, right? I haven't been in a cloud for a long time, and I still have very stale eyes. So, those fresh eyes are incredibly important, and you get to have that high impact early because you're representing our users who are coming onto the platform at high rates, right? And then another one was we had an engineer work on a deploy to workers button so that anyone who built a project on top of workers could add a button to their repo and then just have users click it so that they could deploy it to workers seamlessly. So, like, take that application I built, deploy to workers, just giving, again, another great crisp onboarding experience for people getting up and running with workers for the first time. So, we saw a ton of great impact last summer, and I don't expect that to slow down, right? There's tons of work on the worker side, and there's a lot of opportunity, right? It's about knowing the most important opportunity to execute on, not that there's a lack of opportunity here. So, that in and of itself is really, really powerful. Absolutely. And I just love your energy and excitement about it because I really think it comes through. So, I definitely think the feedback that we received from this past internship class was how shocked they were about the impact that they could have in a short few months and the responsibility that Cloudflare gives them. So, I definitely see that. Awesome. Okay. So, I, you know, want to give enough time for Magic Transit. So, moving on to Nick, it will be kind of the same question. So, tell us about Magic Transit. Tell us about the origin story. Absolutely. So, if you look at the history of products that Cloudflare has built in sort of our core networking performance and security and reliability business, you know, 10 years ago, almost to the day, we launched initially where Cloudflare can sit in front of your web servers, you know, servers that speak HTTP on the Internet, and we will proxy your traffic and provide DOS mitigation and, you know, other security and performance features. And so, you know, for folks who are on the call who are familiar with the OSI network layer model, they're sort of, when you think about networking, there's a lot of different parts of that stack. There's lots of different concerns that happen. And that integration we had with our customer servers was at layer seven. It's a very high layer in the network stack. And this is a really great place to enter because there's a really sort of narrow surface area of, like, the way you get customers onto that platform is through a pretty slim DNS integration. So, it's very easy to integrate and get customers on and start moving their traffic through the Cloudflare network where we then sit in between the Internet at large and those customers' web servers. We can provide all those really great features and functionality for them. About, I think, two and a half or three years ago now, we launched another product called Spectrum, which is similar missionally, right? We're trying to make the Internet safer, faster, more reliable for customers. But this is moving down that network stack to layer four. And this is Spectrum is a TCP and UDP proxy. So, any application on the Internet, maybe it's not HTTP. Maybe it's, like, Minecraft or, you know, an SSH server or something else. You've got something else sitting on the Internet that's not web, that's not HTTP. But you have the same problem. You want to protect yourself against DDoS attack. You want to protect yourself against, you know, latency and slowness and outages in the Internet. And so, Cloudflare can now service customers who sit in that space or users who have that type of workload on the Internet. And so, like, the natural evolution of all this is to look at, okay, we're doing – we built a solid suite of products at layer seven. We built a solid suite of products at layer four. Like, what's the next evolutionary step? And that's where we start to get into what has become Magic Transit. You know, we were looking around and talking to a bunch of customers and prospective customers about, like, hey, like, how can we solve your problem for you? And some of them would say, like, you know, I'm not even sure what's running in my network. I've just got IP addresses, and, like, my job is to protect them. But, like, I'm not the person who's running these applications. I'm not the person who owns the servers. But, like, my job is to make this network secure and safe. And so, that really pointed us in a direction of how do we start integrating an even more fundamental layer of the network in the Internet? And what that became is Magic Transit. And so, Magic Transit really is the culmination of taking all of the learnings and tools and the DOS mitigation and security and performance features that we've built over the last 10 years and applying that at a lower layer in the network stack so that we can provide those same value to a larger number of customers and a larger set of use cases. It's really challenging for a lot of reasons. There's sort of a step function difference between those first two evolutionary stages where, you know, we're sitting as an HTTP proxy initially, and then with Spectrum, we sit as a TCP and UDP proxy. And those sort of proxy behavior means, like, we're actually terminating traffic and terminating connections and participating in the conversation. And that affords us actually a lot of flexibility to use a certain set of techniques and tools to service our customers. When we start to go down to layer three, now we just get individual packets on the Internet, and we got to decide, based on this packet that I'm looking at right now, is this good or bad? Do I drop it or do I let it through? How do I move it through the network? There's a whole suite of different challenges and problems that come along with this space, and it's really forced us to have to learn a lot of new tools and techniques and even create new roles within the company to figure out how do we onboard customers to what is now a much larger surface area of integration, the lower layer of the stack is a lot harder. A lot of the things we think about on the engineering team and the engineering side is, you know, we're obviously trying to innovate and build new features and functionality, but we're also investing a lot in building new tooling and for ourselves to support this product, and then thinking about how do we productize those. A really great example, actually, is what I had three interns over the summer, and they worked on a project where we have this need where the way that we integrate with customers' networks, sometimes something bad is happening on the Internet between us and our customers, and we need to figure out how to figure out is that a problem on Cloudflare's side, is it a problem on the customer's side, or is it a problem on something on the Internet between us? There's this tool called Traceroute, which effectively is a way of observing, you know, all of the hops through the network that a packet takes between point A and point B, and so one of the really common problems here is, like, when we observe a customer saying, hey, traffic coming through Cloudflare is not getting to me, how do we figure out where the problem is, and whether it's something Cloudflare can directly help with, or we can point the customer to helping them solve their own problem, or it's some intermediary, you know, network provider on the Internet, and how do we help kind of steer traffic around that? And so what this team of interns did is they built out a tool that runs this Traceroute capability from all of our 200 -plus data centers around the world. You've got to imagine, you know, Cloudflare has not just a single server or a single data center that all traffic's flowing through. We're operating in over 100 countries and 200 data centers around the world, and so they really had to solve this problem of how do we collect this Traceroute metric from our entire global edge all at once, and then present that information in a way that is easily consumable, and so they, you know, they worked to build kind of a full-stack solution, both from building and deploying some software that sits on our global edge that actually runs that Traceroute utility, and then sends that traffic back to our core data center, where we centralize a lot of our information that flows through our network, and then present a nice, you know, front end that internal teams could use to, let's say a customer phones us up and says, I'm having a problem with Magic Transit. Now our support team has a tool they can use to go and get some more specific information about what's happening, and what's great about that is that tool has been really fantastic for our internal teams, and we thought, like, why don't we just make this available to our customers as well, and so towards the end of the internship, they actually launched this capability as an API endpoint that our enterprise customers in particular can use to run these diagnostics themselves and help put them in a position to solve their own problems. That's fantastic, and I'm glad that you mentioned the work that interns have been able to do within Magic Transit. I think that, like we said with Ali, it has a huge impact on Cloudflare overall, and you know, it's a visible impact, which I think is so exciting for interns. Absolutely. Well, we have about a minute and 25 seconds left, so Nick, just really quickly, what is the team makeup of Magic Transit? You know, where are most people located and things like that? Yeah, absolutely. We just launched the product a little over a year ago, and we've seen a really great, you know, traction with the market, and it's leading us to really think about how we invest more heavily in 2021. Today, all the engineering team sits with me in our Champaign office, but you know, I've got some open roles right now in our Lisbon office and our Austin office looking to hire, you know, people who are interested in working on low-level networking, data plane, and Linux kernel, you know, that's sort of like the machinery that actually plumbs data through our network, but also these sort of, like, diagnostic tooling, like, you know, there's a vision here for, okay, Cloudflare can build tools that help us solve customers' network problems and then make those products. How do we build the best set of network diagnostic tooling that exists in the world today, and we're for a lot of roles to fill that need as well. Yeah, absolutely. We only have a few seconds left, so I just want to say to everyone that's listening, we have plenty of internship and new grad roles available. Please go to our careers website, which is just Cloudflare.com backslash careers, and make sure to check out the university department. You'll see all those roles there. Huge thank you, Nick and Allie. This has been such an incredible conversation. Thank you. Thanks for having us. Bye, everyone.