Originally aired on March 11, 2022 @ 4:30 PM - 5:00 PM EDT
Join us for an exclusive conversation with the former Engineering team of Vectrix.io, a SaaS security startup that was recently acquired by Cloudflare in February 2022.
In this segment, we’ll discuss what it was like to build a SaaS security platform from the ground up, develop an Engineering culture amid a global pandemic, and what the team is looking forward to most now that Vectrix is a part of Cloudflare.
To learn more about the acquisition and what customers can look forward to in the coming weeks and months, check out the following blog posts:
Hi everyone. Thank you for joining us today. My name is Alex Dunbrack and I'm the former co-founder and COO of Vectrex, a SaaS security company that was acquired by Cloudflare about a month ago. Today I'm joined by the former Vectrex engineering team, which includes Frank Meszaros, Sam Bostick and Josh Bicking, as well as one of my two former co-founders and our Chief Technology Officer, Matt Lewis. In today's segment, Building Vectrex, we're going to talk with our engineering team here and discuss what it was like to build a SaaS product from the ground up, what it was like to develop engineering culture while fully remote and in a global pandemic, as well as what they're all looking forward to now being a part of Cloudflare. Before we dive into it, just some background on what Vectrex was. Vectrex was a SaaS security platform that enabled IT and security managers to scan and detect security issues across the wide variety of SaaS applications that they used. This could include misconfigurations and insecure settings, shadow IT, data loss prevention or DLP and other variety of security issues as well. So very excited to be here today and chatting with these guys. So let's just kind of hop right into it, I guess, here. Matt, I'll start with you here. I remember the super early days of Vectrex. We recognized this problem in the space. We started to build this or think about what would a solution look like. So if you could maybe tell us about how you approached laying that initial foundation from an engineering perspective. And what was the intended purpose of that prototype, that V1? What was the goal from that? Yeah, I think that's a great question. And I think a lot of the common engineering things apply. But from my perspective, I was still pretty busy at that point. So it was often thinking of what is truly the most minimal effort that we can give to put not really like an MVP of minimum viable product, but maybe even before that, just like a minimum viable proof of concept of can this thing even be accomplished from a feasibility standpoint? And then on top of that is really being able to see the data. And maybe it wasn't the best metrics, but it was a good motivator from my kind of internal perspective was looking at that data and seeing how excited I would get as a security engineer in my day job, really being able to analyze that data and kind of like thinking if we were able to run with this ball and I was able to dedicate all of my effort towards it, how valuable could it be to me? And I was kind of using myself as a proxy metric for a lot of the other industry. So I think it was definitely coming down to kind of like the basic engineering principles of just feasibility testing, making sure we could do it. And then yet, meanwhile, bias or not was how cool that I think it was personally. Yeah, for sure. I mean, it was a lot of hard work and just getting that that first version stood up. But I think that was even made harder by the fact that it was really just you at the time. Right. You were the only person that only you were the technical co-founder. So, you know, building without employees is one thing. Tell me about when when we made that decision of all right, it's time to start hiring out our engineering team. What did you seek out in those first hires? Yeah, for sure. I think I think it's a really good question, like to to kind of like put the put the note on it. A lot of engineers kind of specialize, whether you're an SRE or a security engineer, you're back in software, front end software engineer and platform engineers, lots of other kind of like real specialties in engineering that coming from my perspective and like having to be the technical co-founder writing that view on myself, you like it or not, however much front end experience you may have is is kind of irrelevant to the question. It has to get done. It has to get done. So I think I'm like carrying that torch forward. It was it was a game of maybe, you know, as you continue to grow as a company, you can continue to kind of clamp down on engineers and say, hey, we're now getting really specific and saying we're looking for SREs with exact domain specific expertise in managing, you know, Postgres at scale or any other like specific technologies. But I think when you kind of take a step back and you really think about it from the startup perspective, a lot of my kind of drivers from that technical perspective of an engineer is looking for engineers who are quick in their mind of maybe not knowledge perspective of every technology and having the deepest knowledge set in a specific technology, but rather just being really good, adaptable engineers who have all the really core kind of baseline fundamentals that we think makes a good engineer. And then kind of like being able to apply that in the startup use case to not only be able to switch between front end and back end and SRE work and anything else that we demand from that technical perspective. But on top of that is making sure also that they're flexible in the product and the feature set that they're delivering, make sure that we can continue to kind of move on the value proposition perspective from a product standpoint. And our engineers can continue to get closer and closer to kind of solving the problem for the customer. So I think flexibility and fluidity are kind of the two pretty core metrics that I was looking for early on past just the normal good engineering kind of prospects that you're looking for. Yeah. Yeah. Hiring was was no easy feat. That's for sure. But it was it was great to watch you stay true to those ideals and the things that you wanted to see as we continue to grow out. And so, you know, Frank, I'm curious, you are first engineer, first hire altogether. What attracted you to the opportunity at hand with Vectrix? I think, well, there were all sorts of things that were attractive to me. You know, I had been working at a startup prior to that and kind of had seen some relevance to the problems that Vectrix was purporting to solve and had kind of experienced the challenges firsthand of having a lot of different component technology scattered across a lot of different SAS apps. I realized how quickly it was to leave an API key somewhere you didn't expect to or whatnot. So the problem was exciting and interesting to me, but it was also relevant to. And I think that was something that really attracted me to it, but also just the stage at which I found Vectrix. It was there's three founders. I really liked that opportunity to kind of grow alongside the company, both technically and also kind of learn more about the ins and outs of what building a sustainable business looks like and what building building the flywheel of a SAS product looks like, too, and just kind of watching your product grow and delight users ultimately. Yeah, it was incredibly unique. And especially as that first hire, too, it was just trying to navigate the landscape. And I think you were a big part of that. And so, Sam, I'm curious. I know that you came prior to Vectrix from a pretty well-established technology company that we would all know. I'm curious, from your perspective, in terms of the hats that you wear as a software engineer, how did that differ from a larger organization coming in as engineer number two? What were some of those differences? Yeah, I feel like the biggest difference is that, you know, you really have to be more self -reliant as like a team. You know, you're not going to end up having like a dedicated team. You're not going to have a dedicated SRE team. You know, you guys are responsible for the whole cake. There's nobody there to do the icing. So, you know, I really feel like that was both an exciting challenge, but it was also a challenge. So it was just it was different. You know, in a lot of good ways, you know, learn a lot very quickly. But you've got to be willing to learn. I remember very clearly, Sam, I think it was your first week, you know, you started. We were working on our maybe a prototype design with with an outside agency. And we threw you on that call with us because, you know, the more the more the merrier. And, you know, when we were that small of a startup. So, so, so many different responsibilities, I think. And so, Josh, I'll jump to you here from your perspective in terms of, you know, mentality around shipping and these things that are product development and engineering broadly. In terms of the tenants of that, you know, philosophy or belief system. How did that differ? How did that differ at Vectrix from a larger organization? What were some of the trade offs that, you know, maybe it's speed or what have you, but would love to get your perspective on that. Yeah, of course. So one of the cool things about Vectrix and then working at this like fast paced startup was the malleability of pretty much all of our processes. And if something was not working from a process perspective, we could all get together and talk about a different way to do it. And when we encountered problems that, you know, something wasn't working that we were doing, like on a customer call or something like that. We could easily pivot and easily move to some kind of solution that would better fit the needs of our customers. And usually creating that solution involves wrapping up very quickly as Sam was talking about, but also finding the happy medium between, you know, we need to get something out the door, we need to compete as a very small crew. But we also need to do it better than competition. Like we need to build something quicker and better and faster. All of those requirements grouped together alongside the flexibility to, you know, just a lot of wiggle room in how we solve those problems was what really attracted me to Vectrix and made me really excited to work there. Yeah, yeah, it was it was a great, you know, humbling experience to watch you guys navigate the trade offs and the realities of being a startup and not, you know, a larger organization. And I think, I think the work, you know, proved itself out here now that we're at Cloudflare. So, you know, to change gears a little bit and talk about, you know, building a solution to the problem at hand. I know we'll speak a little bit more in depth about what this means, but Vectrix was an API driven product. Matt, I'm curious from your perspective, if you can just share with us, what does that mean to be an API driven product and why be an API driven product over, you know, maybe ingesting logs or, you know, looking at network traffic, those other options and avenues? Yeah, what it means to be an API driven product probably could keep philosophers going for a while. But what I can say about how we specifically approach that and kind of the decision making around it is, you know, a lot of a lot of security companies really at the end of the day are data companies. They require that data from a specific source and whether it's an endpoint security product, you're going to have to require that from the endpoint operating system itself or whether you're a network security product and you're tapping the network like Cloudflare is famously known for being a network security product. And then kind of like on top of that is you can look at logs or APIs and start sourcing data from there. So we specifically honed in on when we were developing our product coming in from 2019 and 2020 perspective, we understood that the world is not only continuing to grow in SaaS apps, but that the best data source themselves is the SaaS application itself. And it gives a really unique perspective as an operating system then moves to networks. However, in the SaaS application world, you're not maintaining that infrastructure yourself. And so you don't have control of the OS. And so how do you get data at rest? The really only best second guess ability that you can do is going to be tapping the API or getting logs from the vendor. Now, when we started kind of like looking at those two different options to pull from, we understood and noticed that a lot of SaaS applications themselves have API accessibility. Very accessible and often pretty much on all kind of like contract tier with your given vendor, you have the ability to kind of programmatically hit that API. Comparatively, logging is definitely something that's a little bit more up in the air often with vendors about how much they're willing to give you and strict rate limiting and a lot of other kind of technical feasibility constraints that we saw. And on top of that, it often required a higher contract tier, like an enterprise tier to be able to do. And so I think really, it wasn't just an engineering perspective thing, but it was really a culmination of let's look at the value proposition that we kind of bestow to a large kind of total addressable market. And that it kind of just seemed to be the natural entry point in as an API. And it was just really a kind of win-win-win situation for product, for pricing, for rate limiting and technical feasibility constraints to go down the API and it was ultimately led us down a path of really good, high quality data that we could pull for the kind of platform of our product. Yeah, yeah, I mean from the earliest of days, it felt pretty novel to me the way that we were going about this but, you know, Frank from your perspective I know that all of you guys hopped on to customer calls over time. Was this API approach something you know the people that you were on those calls with had they seen this before? Were they able to, you know, understand and recognize the value from the onset? I think they were totally able to see the value on the onset. To say we're the first API driven product is probably not true. Maybe within our domain of CASB, definitely one of the early movers, but I think just kind of having that sort of API driven product was not totally a foreign concept. I think we've seen a noticeable uptick in products that do something around that. And to your point, yeah, I could totally see the value because the time to value was so small, you know, within five to 15 minutes, they were integrated with some of their most important vendors and seeing security findings in the dashboard. So I think just providing that single pane of glass across all the things was a huge value add for them, because they weren't having to jump around a myriad different tabs just to get the information they needed, it was all kind of condensed into a single point of control for them. Definitely. Yeah, yeah. And something I remember that was a pretty constant theme was when we were speaking with these customers, you know, we'd get these frequent requests of what's next? What vendor are you going to support? And so, Sam, from your perspective, that process of feature and integration prioritization, how did that work at Vectrix? You know, it was really just balancing, you know, like you said, but, you know, we'd hear from customers or potential customers what they're looking for. But then also, you know, we are API driven. So looking what was actually feasible from an implementation standpoint, what isn't going to, to Frank's point, the time to value, we always want to keep that low. So what isn't going to have a whole bunch of hoops for the customer to jump through to get that initial, you know, value prop out of the product. So really just a balance between what's the customer looking for and what can we as a small team of engineers actually implement quickly to, you know, give the customer more to work with. Yeah, yeah. It was interesting to navigate through that. And I think we did a pretty bang up job following the voice of the end user. We were customer obsessed, I'd argue. But those are great thoughts, guys. Kind of to shift gears once more into, you know, we were approached by Cloudflare. We see a lot of alignment in our philosophies and the way that we, you know, go about solving problems for an end user. So now that we're here, you know, I'd love to ask all of you guys, and I'll go one by one, but how did you know about Cloudflare before we were acquired? What were your takes on them as a company and product? Matt, we can start with you. Yeah, I think how I knew Cloudflare is a great question. Well, I used to play a lot of video games, probably like most engineers. And so with that Cloudflare, you know, like coming from the video game perspective, kind of pre-Cloudflare days, DDoS attacks would happen super frequently. And it was really, really disruptive to your day as you're trying to play a game, you got to figure out, oh, great, like the server's going offline. And so I really learned about Cloudflare through the gaming community of how large impact that could have. And we have a global network that not only is doing DDoS protection, but it's also masking IP addresses such that there's a little bit more anonymity baked in there too. So I think from my perspective, I knew about it a lot through the gaming community, but then after that, as I kind of like continue to grow myself and start building my own websites and publishing them, the easy step was to use Cloudflare from a security and performance perspective. And it was one of those few products that you would kind of learn about later as I've grown to be a security professional was security and performance can really be one in the same together. And that's pretty rare across a lot of security products. So I knew about Cloudflare through video games, and then it's kind of prestige continued to hold with me as the value proposition I was able to directly glean over my professional career. Totally. How about you, Josh? So as a more tech hobbyist kind of person, I always love when tech scales not only up but also down to like one single user or one hobbyist. So I've been using Cloudflare prior for like two years to protect some servers I had running in the garage that were running a couple like web services and stuff like that. Even before we had thought about this sort of merger and Vector is working with Cloudflare and they've been in my mind an industry leader in so many fields. I've loved reading their blog posts. They're a huge, like, wonderful source of information and up to date like what's going on on tackling web scale problems, their commitment to security and trust and especially accessibility of security is how I think of Cloudflare. Totally. Sam? Yeah, the CDN, DDoS protection. So, you know, two like very edged things. And then the blog, it's like Cloudflare and Netflix are like the two kind of tech focused blogs that we do on a regular basis. So those are, you know, it's really cool to see like an organization that has, you know, both, you know, the product and the engineering presence online. And, you know, Cloudflare definitely has that. So I knew coming in that it was definitely a, you know, a good shot. Totally. How about you, Frank? Yeah, you saved the least intense one for last. But no, I mean, really, it was just the startups I've worked in the past with, they just all use Cloudflare and I knew about Cloudflare, but I think this speaks more to how good of a product Cloudflare was. I never had to think much about it in my day job. You know, it just, it was on, it worked. It just was a very constant part of my life. And I didn't really, I think, you know, come to appreciate it up until recently as I kind of moved further down the stack and got more responsible for helping out with things related to infrastructure. And just how nice it is to have a piece like that become such a, you know, you don't even have to think about it at this point. It's just so easy to use. It's kind of the beauty of Cloudflare products and the way that I think a lot of us start using them is they know it's there, but maybe don't have to run into it that often, easy to set up all those things. And I think there's been a lot of overlap in how we approach things as well at Vectrix. But, you know, Matt, actually, that's probably a pretty good segue. I'm curious from your perspective, as we have, you know, joined and we're integrating now and we're deep in that process, from a shipping culture perspective specifically, you know, was there overlap in how, you know, Matthew and Michelle have set up, you know, this organization and the ideals present here? Was there overlap in how they approached, you know, building prioritization and things of that nature? I think there is a lot of overlap. And I think I can kind of like reverse the answer there when I think about it and getting back to the previous discussion was often, to Frank's point, you wouldn't have to think too much about Cloudflare until you had kind of this, like, maybe weird, like one-off kind of task that you thought, well, it's an ingress request into our data center. So maybe Cloudflare does it and you would often kind of discover more Cloudflare products as you would go ahead and jump into the UI and say, oh, maybe there's a rule set that I can create in order to kind of help out traffic and kind of steer it myself. And so kind of jumping to that shipping culture, it's become so apparent then as kind of time has moved on that how Matthew and Michelle kind of continue to architect the Cloudflare organization was around that shipping culture. Yet again, Cloudflare being known to kind of build that network and the value proposition really doesn't stop or even really just start at CDN and DDoS, but it's so much more of that global network. And so from there, that shipping culture of Cloudflare works so well with even an early stage startup like us. And I think especially a security startup like us, where we knew that we couldn't just build really awful code like maybe many other startups, but rather we had to be really diligent as a security company ourselves, we have to be secure. And security doesn't just mean security, but it means maintainability, well-tested code base, well thought through, and a lot of other kind of core criteria of what good engineering practices are. And so I think Cloudflare really meets that marriage perfectly between shipping value proposition, just like a startup does, yet meanwhile, as a good security company or network company, you have to be up, you have to be reliable, you have to be maintainable, you have to be well-tested, and all the other core practices that necessitate good engineering work around a defensible code base. So that marriage is kind of a match made in heaven from Cloudflare's ethos and internal company architecture around how to ship and how an early stage startup that's in the security space that cares about the code base does too. Yeah, it's been pretty encouraging, I think, from the onset to see that parity. And I only imagine we'll discover there's more and more as time goes on. But Josh, actually, almost to what we have been talking about at this high level of Cloudflare has been this network-first company. That's where their expertise has lied for over 10 years. From your perspective, as we talked about, we're this API-driven product. What kind of expertise are you guys, as the former engineers of Vectrex, bringing to the table to this organization that didn't historically dabble in APIs that often? Yeah, of course. So API-driven products, they come with their own specific set of challenges in a lot of different ways. A company I worked at prior, they had tried to build a more API-driven security product before. And it was very challenging just because APIs can be inconsistent, or they can go down, or they can even return data that doesn't reflect the current state of the world. And using that space and still deriving value from it and deriving value that customers can look at and use stuff that's actionable is a specific set of skills that we've definitely perfected over the course of building out the Vectrex product. And I'm just more so bringing that to the Cloudflare side. I'm excited to bring that vision of a turnkey software-as-a-service security solution to Cloudflare and also get more resources behind it. Instead of being less than a dozen engineers, hopefully we're going to have a little more resources and ultimately just a greater impact on making the Internet a safer place and making SaaS security easier for people to use. Yeah, I think I've observed so far that everyone involved in our acquisition and now integration has been excited for us to bring that knowledge over. But also, I think we're all collectively excited from the Vectrex side to work with their network-first ideologies and expertise. Matt, I'll shoot it right back to you, actually. So now that our Vectrex product is now going to be Cloudflare's CASB product as part of Zero Trust, can you tell me a little bit about how you see us as the right fit in addition to access gateway and browser isolation? Yeah, I think that's a pretty good question. And being a technical person I am, I'll go right back to the architecture. And thinking from a security engineer's perspective, security is this constant game of, like I said, being a data company first. But from that security operator's perspective, you're looking for omniscience in certain aspects of being able to get effectively as much data as you can get your hands on. You can move down the motion later on as you continue to grow in that first aspect. But the step one of a security engineer is you need to start harnessing good quality data and moving on from that. So when we think through Cloudflare and we thought through as founders this acquisition, the whole motion here, the immediate value proposition that you can kind of glean from being back to your roots as a security engineer, an IT administrator, or anybody who's really a security stakeholder in an organization comes down to the ability to get as much data as you possibly can. So when you think about Cloudflare and the level of scale they operate at, in conjunction with our abilities to now, in their Zero Trust suite, pull in that API data, that critical other kind of missing lens from the network perspective, you have yet again this match made in heaven where you have all of your network traffic that accessing gateway can do all the fantastic things that you can do powered by Cloudflare's global edge. And now, meanwhile, we can kind of sit from an out of band perspective and pull in all that critical data at rest from those APIs of your SaaS applications. Now we can correlate all of that data in between and in the future so we can continue to offer really industry leading levels of insights to security operators. And I think it's critical that we don't kind of just harp from like a vendor perspective trying to sell something, but really thinking about it from an architecture lens and understanding as a security operator, the better, higher quality data and the more of it that you can have, the better. And for that reason, API plus network is just a simply better value proposition to them. And that's what I want to chase down. Yeah, yeah, I think I'm not just excited. I think there are tons of cloud existing Cloudflare customers that are that are excited to get this comprehensive suite of security solutions that are at their fingertips that really give this this broad view into how they are operating from a security perspective. Great. So we got a couple minutes left here. Matt, you actually mentioned this, you know, the scale of Cloudflare with their thousands and thousands and thousands of customers. Curious from each of you, and I'll start with you, Frank, what excites you most about that, that scale that we are going to be jumping into ourselves? We didn't have the same access to the scale, so I think we're really just, I think, going to see just, I mean, how the true capabilities of how our product scales. And I think, too, just to Matt's point about collecting more data, like, I think that's really going to improve just the observations we're able to make and kind of building out a more robust pipeline for processing all of this stuff. So that's what I think excites me the most. It's just like the universe of discourse that is now available to us has dramatically increased. And as such, the data that we now have access to and the insights we will be able to glean on top of that data. So more data, more insights, more features. All good. How about you, Sam? Yeah, I mean, I think we built a pretty cool product, you know, very, very confident in it. And so I'm really just excited to just get it in the hands of more customers, you know, just have, just take the customer impact that we already had and just turn it up by a million. You know, I'm really, really excited to just get this in the hands of more people. I think it really is something that's just going to make places more secure. And the more that we can do that, obviously, the happier, happier everybody should be. Totally. Josh? With the end goal of visibility into the corporate network, an API driven CASB being one piece of that. I'm just excited that, you know, Cloudflare customers and users will have that end goal of like end-to-end visibility. And I'm just happy to be a piece of that and happy to help solidify that for their networks. Great. Matthew, wrap us up here. Yeah, I think to me, just a lot of it comes down to really echoing the sentiment of what they all said there. And I think kind of like to Frank's point, just continuing on that journey in Zero Trust and continuing to just build the feature set insights is going to continue to be powerful. So I would say just echoing the sentiment there, it's really unparalleled. Absolutely. Well, thank you all four of you for joining here today. For anyone watching that is interested in beta testing or getting started with Cloudflare, CASB, or any of the Zero Trust products, please visit the Cloudflare website and there's a beta wait list that you can enter there. But until next time, thank you again for tuning in. Over and out.