The below is a full (unedited), machine-generated transcript of a Youtube session / podcasting episode I recorded with Joey Parsons, founder of effx in the fall of 2020. You can view the video/listen to the podcast on Youtube, Apple Podcast, Stitcheror wherever you get your podcasts.
Erasmus Elsner 0:07
What’s up everybody, and welcome to another episode of Sand Hill Road. So let me kick off this episode by saying that if you talk to software developer these days, one topic that’s almost certain to come up is the topic of microservices. With microservices, things are bound to get complex really quickly. Today, I’m talking to Joey Parsons, the founder of effx, a company that is building a platform for observing and managing microservices across your entire infrastructure. effx is like a catalog or newsfeed if you like, for managing your services. An application instrumented with effx gives the engineer a single YAML endpoint that they can navigate to for understanding the history and state of their micro service. Joey joins the show to talk about his prior life as a rock star infrastructure engineer at breakout companies including Rackspace, SugarCRM, Flipboard, and most recently Airbnb, and how he’s left big tech to join the rare breed of Mavericks, also known as founders. But he’s not alone. This quest recently turned a father, he has a legacy to build
Joey Parsons 1:53
one of the wildest things when I was leaving Airbnb and I was just explaining to people what I was going to do, I was also telling them for the first time that my wife actually was pregnant.
Erasmus Elsner 2:02
And with the backing of Kleiner Perkins, which first incubated him as an entrepreneur in residence, and recently led a USD 3.9 million seed round alongside Cowboy Ventures, Joe is joined by one of Silicon Valley’s oldest venture firms with a great legacy to protect, but let’s hear it from Joe himself. And let’s jump right in.
Welcome, everybody to another episode of Sand Hill Road. I’m super excited to have with me today, Cameron Weibel, as a co-moderator, and our guest is Joey Parsons from effx.
Joey Parsons 3:02
Hey, how’s it going, everybody? Excited to be here. Welcome, Joey.
Erasmus Elsner 3:06
So before we dig into effx, and closing and announcing your Seed round, just recently, I want to take a step back, go all the way back down memory lane and talk a little bit about when you actually decided to start a company. So you’ve been a senior engineer, I would say a rock star infrastructure engineer at companies such as Rackspace, SugarCRM, Flipboard, and most recently, Airbnb. And at one point, you decided to take a first swing at building a technology company. And I found this great tweet of a former colleague of yours, who said: “This is really awesome, I met Joey a few times at Airbnb, and I knew right away, that he was too smart to work for someone else, and that eventually he would start his own company”. So was this founder DNA always part of you?
Joey Parsons 3:56
That’s actually a really great question. I’ve been lucky and privileged enough, as you mentioned, to work for a lot of really great companies in my career, right? And going back to like, the, you know, the early days of Rackspace, in like the late late 90s, early 2000s. And, and really being able to see kind of a, you know, a large enterprise organization that to this day still exist. And so it was a force in the industry, kind of get started from a very small team in San Antonio, Texas, that isn’t, it wasn’t, you know, necessarily a place where, you know, a lot of technology startups were coming from and like the early 2000s, so, you know, be able to see that journey. And then ultimately, you know, 2014 or late, late, late 2004, early 2005, deciding to make the move to the Bay Area, because, you know, that’s where I felt kind of like the best of the best were in the industry. And I kind of wanted to see where I, you know, stacked up and really early on latched on to, as you mentioned, SugarCRM, and I was in the first handful of employees there. And I think that you know, even though I wasn’t like a founder of that company, I really got to see that company grow from, you know, just like an open source project and then building kind of like our Saas offering on top of that, and really got an opportunity to grow with that company from both kind of like running engineering operations on the back end. And making sure that like our stats platform was always up, always available always performance, and also getting to run customer success at the same time. And then after that, I kind of made a detour away from the enterprise side of things and kind of went deep on consumer internet. And, you know, had always seen these these companies grow from just like, you know, a handful of employees to you know, what, like a Flipboard, or a cloud or an Airbnb kind of really became, and at some point, you know, you’ve been in this for such a long time, right? You kind of get that into yourself, it’s hard to be in this area in this in this community of Silicon Valley and not want to make that leap yourself. So last year, I turned 40. Right. So it was, you know, making sure that I had kind of like the energy and you know, there’s no better time than now. So I decided, you know, through the through through Kleiner Perkins to take that risk. And and it’s been, it’s been a great time since so, yeah.
Cameron Weibel
Do you think you had that entrepreneurial spirit growing up as well? Or is that really something that was nurtured during your career?
Joey Parsons
You know, I think that like going back to the late 90s, early 2000s, right. Even in my time at Rackspace, and even prior to that, I was always, you know, trying to build things on the side, right. One thing that’s actually not on my LinkedIn that that actually was a quite an interesting thing was maybe in like 1998, early 1999, I actually had a pretty popular social network that I built from scratch called pic rave, built on the lamp, stack, PHP, MySQL, I regularly had, you know, anywhere between five to 10,000 users on every day, I just at that point, I was, you know, a 20 year old kid, I had no idea how to monetize, I actually had ads running on the site, basically, like almost like wiped out and an entire ad agency that was in South Texas by basically using up all of their inventory. But I just couldn’t quite match the costs of running that sort of infrastructure and storage at that point, with the advertising dollars that came in. And so a few years later, we’re actually shutting down. But I look back at that it was like there was there was actually a pretty great opportunity to there, if I’d figured out how to live at that age, with that sort of significance, you know, multi $1,000 hosting bill coming every month. So I think it was always in me since those early days. But I think that it really made sense for where I was in my life in my career, you know, in late 2018, to make that to make that initial go.
Erasmus Elsner 7:30
And let me let me double-click on this confidence point. At Flipboard, you ran the core platform engineering team at Airbnb, you were in charge of the Site Reliability Engineering, observability, and performance engineering. So you have these really senior roles that are I think, hard to leave actually like Airbnb when my wife was five months pregnant with our first kid.
Joey Parsons 7:49
So one of the one of the wildest things when I was leaving Airbnb, I was just explaining to people what I was going to do. I was also telling them for the first time that that my wife actually was pregnant. And most people were like, Wait, what? Like you’re leaving your job and Airbnb, like, you know, as you mentioned, kind of pretty, pretty comfy job from a comp perspective, right? You’re leaving your job and Airbnb to go start a company and incubated within Kleiner Perkins, like, what are you doing isn’t is, you know, what is your life say? Right. But you know, she had nothing but support for me, she knew that this was something that I always wanted to do, and that I had a compelling reason to do it then. And I actually think that the fact that we were kind of you know, about to have our first kit actually drove me a little bit farther, right, a journey a little bit harder to take the plunge now, because, you know, now I had like, this extra set of hay, like, you know, go out and do this and do this really well. Because now you’ve got now you’ve got a kid riding on that. Like looking back, it’s, it’s still seems like a very wild decision to go out to go out and do this, but I’m pretty happy with with the results. So far.
Erasmus Elsner 9:00
I had the co founder of TaskRabbit on and he actually he came up with the idea of TaskRabbit with his baby basically placed on top of the desk, it gives you a lot of focus and perspective.
Joey Parsons 9:10
Yeah. Interesting enough, I think, you know, is looking back a few days ago, like the first commits into some of the repos for for what what is eventually become effx, looking back at, like, these particular times, and, you know, like, when during the day it was happening, and, you know, a newborn needs to eat, you know, every few hours, right? So, the deal was, like, I would wake up with my wife, I would, you know, change, change my son’s diaper. And then I would hand it off to her and she would, you know, spend the next, the next bit of time breastfeeding, and a lot of that time, I would just kind of like, hop over to my laptop and just code for, you know, 20-30 minutes and then, you know, go back to bed right. And then I’d be laying there in bed thinking about like, the things that I wanted to build when we woke up again, so you know, it really kind of like drove me and motivated me. I wouldn’t recommend doing this. Like, I think from like a sleep perspective. It probably wasn’t the The most healthy thing to do, it just happened to be a great time to really focus on starting starting to build the project. I’m curious on the transition from Airbnb to this role you had at Kleiner, what prompted this switch? And how did you kind of find this avenue to be able to grow this within Kleiner. I’ve been fairly lucky. And you know, the latter half of my career to work out, you know, a handful of really great consumer internet startups, right? from, from cloud to Flipboard, to Airbnb, I worked at clouds, and you know, the early 2011 days, they were actually backed by Kleiner Perkins, right, we actually shared a giant office space with them. So we had like this kind of warehouse side. And then we had a shared door that just kind of like led to the Kleiner Perkins, San Francisco office at that time. And during that time, I actually got to know the former CTO of Hulu. His name is Eric Fang. It was a general partner at Kleiner for a few years, and got to know him through my time at Cloud, right, you know, spend a little bit of time with him. It’s kind of like a like a mentor. Right? You know, eventually, when I left cloud, I ended up joining his team at Flipboard. He left Kleiner to become the CTO at Flipboard. You know, we’re under his tutelage for a few years, he’s always been someone that I’ve gone to when, when I’ve, you know, started thinking about career changes and things like that. And after Flipboard, he went back to Kleiner to be a general partner there. So when the time came to leave Airbnb, I rang up, Eric, we had a great conversation about, you know, all the great changes that were going on with Kleiner, at that point, you know, they were bringing in, you know, some some new partners that were working, you know, a lot on the enterprise and developer tool side, as I got to meet the new members of the partnership, and also spend some more time with Eric around kind of like what I was thinking, it just kind of just made sense at that point. So Bucky Ward, who’s the partner that I work with over there on on enterprise developer tools, you know, he and I hit it off really well. And everything just kind of fell, fell in place, you know, naturally, I didn’t, it wasn’t like I cast this wide search, to, to a bunch of different VCs with, with some of the ideas that I had, it was it was really just kind of, you know, I had a familiarity with Kleiner through almost like eight years at that point, to where it just kind of really made sense to transition into that role there.
Erasmus Elsner 12:04
Talk to us a little bit about the daily routine being incubated as an EIR at Kleiner, I have the impression of the EIR role, it gives you some room in your life to think freely and to experiment, to have coding sprints, to basically have quite a lot of freedom to test out your, your project and your ideas.
Joey Parsons 12:21
I’d say it was very much that right within the role at Kleiner, I had the opportunity to basically, you know, attend any meeting, I wanted to and attend, attend any pitch and spend any time with any partner that I wanted to just kind of get on their calendar or talk about, you know, things I was thinking about, I got to go to Monday meeting, right, where were the rest of the the partnership was, you know, talking about deals that were that were in flight, and how are they going about making decisions on that, but I think that, you know, the real benefit was, you know, being able to talk to entrepreneurs talk to companies within the portfolio around things that I was thinking about. But other than that, it was largely unstructured, there was a lot of freedom to have conversations with as many people as we could around, you know, different ideas. And then a lot of it was just kind of, you know, spent coding, right. So I would spend a little bit of time every, you know, every week in like the Menlo Park office, and then I would also spend time in the San Francisco office in South Park. And it was just really great to have access to, you know, the partnership there and, and all the supporting functions as we’re thinking about this, and get like instant feedback around some of the markets that we were thinking about and, and ideas that we’re thinking about. And it was actually like a great opportunity for me to kind of really narrow down on what I wanted to work on. So I look back on that time, you know, and credit incredibly fondly, right. I feel like I’m still part of like the Kleiner Perkins family, even though I’ve got a CEO in the portfolio, but it was it was actually a really a really great experience, especially as a new dad as well. So it was it was fun.
Erasmus Elsner 13:45
Yeah, sounds perfect. Let’s let’s take a step back and really go high level on microservices, which is really this macro trend that effx is built around. I want to first definitional section here on what microservices are. I found a number of definitions. The one I liked the best was the one by Sam Newman. He says that microservices are small autonomous services that work together modeled around a business domain. So there are four elements. Firstly, the services are small, which stands obviously in contrast to the monolithic architecture. They are autonomous, which means that they can co-habitate next to a monolith. They’re logically decoupled in a sense, and they can also be deployed continuously. And they need to work together. So there are interdependencies between microservices, which makes it complex. And lastly, they are modeled around a certain business domain. So these four core elements, I think they are a definitional start. But as a new father, how would you explain microservices to your five month old?
Joey Parsons 15:01
Oh man, good question, so to a 20 month old I probably related to a toy right? And I probably think through remember Voltron. Voltron was a cartoon, you know, back in the 80s 90s. Right? I grew up watching it when I was in Japan. So I don’t know if it was just a cartoon but it was basically this, you know, the superhero giant kind of like robot right? But the robot was actually made up of five different lions right there had their Tigers like I can’t believe I don’t remember this but was baltra was made up of like these these five different you know, giant cats. I look, let’s call them lions, just for the sake of calling the blind. They all made up Voltron, right. But they all had like their own distinct kind of like characteristics or personalities, right? You know, two of them made up the legs, two made up the arms. And then one was kind of like the, you know, like the chest torso. And then it kind of had a head. So, you know, the the lions were ultimately powerful as Voltron, like the robot that would go out and, you know, save the world. But, you know, they were they were these independent, kind of like, independent autonomous parks. Right. So I think that if I had to explain to my son Alister, like, you know, what, what, what microservices are, I would say that, you know, microservices are kind of like the lions that make up, you know, the the application of the whole, which is Voltron? Yeah, it’s a great question. I never thought about it from that perspective. But I would say that, you know, hopefully, I did a decent job of explaining that to my kid. I’m going to try later.
Erasmus Elsner 16:29
If I look back in history, there was a thing called “structured programming”. In many ways this was the precursor of microservices, and really finding this fine line between what’s a sub-routine, like what’s a sub-function, and what’s a microservice is and when do we start calling something a microservice. And this is something that when I, when I looked into it more closely, I found it quite challenging. What’s your day to day thinking about? When is something in microservice versus just to separate? Yeah,
Joey Parsons 16:58
That’s a great question. The best definition that I that I’ve kind of found is from Martin Fowler, I think he was actually may have been the one that coined the term, microservices, you know, like, quite quite a long time ago. And I’ve actually got it pulled up here, but it’s like, so it’s an approach to developing a single application as a suite of small services, each running its own process, and communicating with lightweight mechanisms. And oftentimes, this is kind of like a, like an HTTP resource API. And then, you know, they’re they’re built around business capabilities, and independently deployable by fully automated automated deployment machinery. So I think that, you know, when when, when you’re thinking about, you know, separate teams, or controllers within kind of like, like a Ruby on Rails app, the big difference there is that, you know, each of these is kind of like its own program or application in itself, right. So it’s running its own process, it has its own runtime, its it, you know, has its own sort of, you know, scale factor or its own failure conditions, as opposed to being a single runtime, like a Rails app or an application that has like a sub routine. So the biggest difference between, you know, a micro service and a sub routine, I think, is you know, really just kind of like around running its own process. So, I think that, you know, there’s there’s definitely a lot of definitions out there for four microservices, right. There’s a lot of you know, other other phrases that have been used to either describe, you know, something similar, like a service oriented architecture, as you know, domain separated as a micro service. But in large part, they’re, they’re, you know, largely the same from, from a technology standpoint, they all have my new details, depending on the perspective of who’s building them. I would say that, you know, maybe microservices, that a company like Airbnb, and microservices, that a company like Flipboard, and even effx, you know, they’re all slightly different, they all have been thought through in a different way. But they end up having some of these core components of, you know, being a small service in some way, like running its own process, having its own kind of, you know, own development velocity, its own kind of deployment pipeline. its own like being owned by like a particular team, where they’re ultimately kind of, you know, responsible for the ongoing health, that service, there end up being like these core components, and you can call them whatever you want. But they’re, they’re, they’re, they’re definitely a a growing trend that we see happening, you know, in companies that are moving from like the monolith to microservices, in companies that are, you know, large organizations that have been, you know, moving towards using this as an opportunity to get to the cloud, even companies that you know, are just starting out these days are figuring out that, you know, sometimes breaking up an application from the start or just doing that from from the very beginning, ends up being like a valuable development methodology to then, you know, continue to scale forward. So,
Erasmus Elsner 19:54
So let me move on to an article that Uber recently published, titled “ Think domain oriented microservices architectures”. Basically, it outlined how Uber has more than 1500 micro services in production. And it has this great graph of how each microservice is a node in the network. And then I think the edges in the network or the RCP or API calls, then it basically gave a list of the names of the different micro services. And a lot of commentators or some that I spoke with, they basically said that these labels seemed meaningless. I mean, some of them like fair split work kind of intuitively knew what the microservices probably doing. And this brings me to the topic of functionality. And I like these two, two sentences on functionality. So the first sentence, a monolithic application, puts all its functionality into a single process, and scales by replicating the monolith on multiple servers. And then the other side of the coin, is the microservices side, microservices architecture, puts each element of functionality into a separate service, and scales by distributing these services, across service replicating each one. What this basically refers to is this great advantage of microservices of scaling. But before you can do this, you need to define the optimal scope of the functionality. And this, of course, also feeds into the size of the team handling the micro services. How do you in your role at effx, where you talk to so many companies about microservices and a microservices architecture? How do you think about optimal functionality? What should go into a micro service?
Joey Parsons 21:38
Yeah, yeah, that’s that’s actually that’s actually a really hard question to answer, right? Because it’s, it’s really different. I would say, for for every organization, I guess, you know, depending on, you know, where they are in their path to doing microservices, I would say like really well, you know, Uber talks about like their domain driven approach, right, where they have this concept of layers, right, where they have domains within those layers where you know, you have like your infrastructure stack, and maybe kind of like your business stack and platform stack and edge stack. And now that’s one way of kind of like organizing around like the different microservices that are not competing with each other. And I’ll give you an example of you know, where this kind of becomes a difficult thing to like, scope out. So let’s say you have a service for users, every app has users write what service talks to the database, were like user information is stored, you know, what stores information and like your user profile, like your name and your email address, and that usually will be a micro service or a service that exists within an organization. So let’s say that, you know, you built this application to this point, you have this user service, and then suddenly, you have a requirement to store like roles, like roles of a user, right? You know, these roles can be a dynamic, right? You can have, you know, an admin, an admin role, a billing role, or maybe even something more granular, right, where you have, maybe you have read access to the billing section, but you can update the credit card or have some sort of like level of administration based on the different components that you have in your application, right, at that point, as, as an engineer, you have a decision to make, right? Like is, does this functionality belong within that user service? Or do I go out and create a role service, right, that, you know, the user service may talk to, right, and that the user service would then, you know, get its role information from the role service, but it wouldn’t be part of that service itself, right? I’ve seen companies do this differently. So some companies might build in roles, depending on the complexity of roles into the user service, because that’s where that’s where the data may exist. And if it’s a simple roll type thing, but if it’s a more complex sort of rolls, you know, environment, then you need to build out, maybe that belongs in another service, my initial kind of like gut in terms of best practices would be to break out those services, right, you’d have a user service, you’d have a role service. That way, if you ever needed to extend that roles, functionality beyond just the scope of the user, you would have that ability to do so. But that’s there’s there’s a trade off in doing that. Because it becomes slightly more complex to understand what’s happening on the user perspective. You know, I would say there’s a world where you maybe create the user and role service in the same service, and then maybe two or three years down the line, you break it apart, right?
Cameron Weibel
To continue on that. I find it difficult sometimes if I’m trying to build a web app to really start and try to architect everything my mind does micro services. And so I usually start as as a monolith and then componentize it later when I understand the scope. Do you also kind of start this way? Or do you really kind of stay strict to the microservice mindset from the beginning?
Joey Parsons
You know, when we when we started building effx, we built micro services from the start. And some of those original micro services don’t even exist anymore. From like a scope perspective. Either they were too broad or too shallow, and we either consumed them into other services or split them out. In the same way within the monolith, you might not get it right from the start Anyway, you may not get it. You may not get it right from from a microservices perspective from the start anyway, but then you can just kind of adapt. We’re seeing more and more companies. These days start on technologies that really are microservices enabling, whether that’s adopting Kubernetes from the get go, and even running your monolith on top of Kubernetes to potentially have multiple services. We’ve seen a lot of companies start on AWS lambda from the start. And there’s the whole kind of like our serverless, functions, micro services, right? Are they nano services or something even even smaller, but I consider you know, serverless functions to be on the same path. And then there’s other enabling technologies on on a bunch of different platforms, whether it’s, you know, Google Cloud run, or Amazon ECS, where, you know, it’s really easy to run containers, which is, you know, ultimately a building block that people are using to orchestrate microservices.
Erasmus Elsner 25:41
One thing I found quite interesting when looking into microservices, that there’s always this human component, if you run a monolithic structure, you tend to have a separate UI specialist, a middleware specialist, a database architect, in a separate function, and then they have to talk to each other to deploy this monolithic structure. And what you basically do in a microservices architecture, at least the way I understand it, is that you try to take one specialist out of these individual groups, and basically put them into dedicated microservices teams. And when I looked into it a little bit, I tried to find out what’s the optimal team size per micro service? And and what kind of capabilities need to be in one of these teams. I think I found some some guy on Reddit, who claimed that the optimal size is three people. But you need to have like, at least one UI person, one server side logics person than one database person on such a microservices team. I’m not sure I agree with this, there seems to be a lot of heterogeneity in terms of what microservices do.
Joey Parsons 26:51
You hit the nail on the head when you said that it really depends on the service that’s being built, right. In terms of team size, and I’m sure you’ve heard of like the two pizza teams and Amazon. Right. And, and the way that they think about, like team size, there is I largely follow some of that same, that same sort of belief, but I think it really just kind of depends on the capabilities of your teams, right, I think that we’re starting to move slightly away from like, this concept of specialists, where I kind of see, you know, things going is that, you know, every team is kind of like there’s autonomous group that’s in charge of some set of functionality, right, almost kind of like that domain approach that Hooper talks about. So you might have a team that is, you know, specifically working on search or billing, right, that billing kind of like domain might be composed of, you know, 10 to 15, different micro services, right. And this could vary based on like company size. So in effx right now, in not not including myself, we have four engineers on the team, we actually and we haven’t broken this up to where you know, every team like there’s, there’s this one team, right, and there’s not, there’s not like, we don’t have like a front end team of back end team and all sorts of things like that. And we’ve actually got close to 30 microservices at this point. Right. So like, our ratio between like, you know, number of engineers and micro services is actually quite large. Right. And, you know, we’ve seen some companies that have, you know, 100 different engineers, but they’re well over, you know, you know, a few 100 microservices, so and they’re doing that, you know, effectively, you know, pretty well at scale. So I’d say that, you know, it’s, it’s, ultimately you got to do what works for you, right? And what will make sense for your organization. And ultimately, the size of the team really kind of depends on the complexity of, I guess, the kind of the domain that you’re working in and, and and what makes sense to do from there.
Erasmus Elsner 28:35
So the last technical topic I want to cover is the data layer. And if we look at the monolith there, you oftentimes have one single logical database, ensuring persistent data across the entire application. And if we contrast this now, with a microservices architecture there, you often have each individual microservice, manage their own database, either a different instance, or using the same database technology. But but it’s it’s it’s typically broken apart, what’s the optimum there doesn’t just get extremely confusing really quickly. What’s your take on this?
Joey Parsons 29:15
So I would say that the the latter approach is definitely the more recommended approach, right, where you have where each each micro service really kind of, you know, manages and owns its own data. Right? So let’s go back to that example of like the user service, right. So let’s say, let’s say we had to two services, a user service, and maybe a search service, right that both had access to the users table. Let’s say I’m on the search team. And I need to change the schema of the user service right out in different fields. That’s important from the search team, right? I could, in theory, break the user service when I deploy this new change to the search service. The better way of doing that is that you know, the user service owns all of its data and exposes an API for them to search service to use, right. So instead of the search service talking directly to that database and requiring a particular version of the schema, it’s basically talking to the user service, which would then have a version of that API within that it presents to the to the search service and all the other search services so that you don’t end up with these sorts of conflicts, right. And I think the other big benefit there, too, is also from like a scale perspective, right? So you know, if you would want the user service to like the size of the database, and the scale the database to appropriately be size for kind of like the amount of traffic that user services getting, as opposed to dealing with like these two different variables of both the search service as well as the user service, right. So I think that there is, there’s a lot of different, there’s a lot of different approaches there. But I would say that, you know, when it comes to like, like the true definitions of micro services, every micro service should really just kind of like own its own phone, its own data.
Erasmus Elsner 30:56
When I looked into microservices, something that was really striking to me, there’s a lot of controversy. And one guy from the monolith campus, Keith Adams worked on the just in time PHP compiler at Facebook, and then later went to slack where he did something similar. He went into this this Twitter fight with the other guy. And he said, like, what, what are you talking about? We deployed 50 times per day at Facebook, what do you need microservices for? And this brings me to this really this killer feature of microservices, which is around deployability. And basically, having large groups of people being able to work in parallel and deploy with high velocity. How do you think about this whole controversy? And is deployability the killer feature microservices?
Joey Parsons 31:44
Yeah, I would say that, you know, deployability really kind of fits into the whole kind of like, autonomous story, right? Like you’re really enabling your organization and the teams within that organization to operate autonomously, right? Like, you don’t need to coordinate like your deploy with, you know, every single other team in the organization that’s employing like that same singular app, right? In the same way that Facebook did, you know, 50 times a day, I think they actually even Did you know, many more times than that. So stay away from those Twitter fights. And a little bit of controversy. Going back to what I was mentioning earlier, even when it comes to how people do microservices, got to do what works well work well, it works well for your organization, right? There’s there’s roadblocks for both of them, right? There’s definitely challenges that come with running a monolith, there’s challenges that come with running microservices, and you’re basically, you know, choosing the one that you feel most comfortable with moving forward that enables your team to build business value for your users, right. And I think that’s, that’s what you know, every company is ultimately trying to do, and if you can do that with a monolith, or even with, like, you know, the Citadel approach where you have like a large, you know, large services and maybe like one main large service, or whether you go down SLA or micro services, it’s really, you know, there’s no right or wrong way. And it’s almost like vim in vim versus Emacs, right? I wouldn’t say that. It’s as much of a holy war as that. But there’s definitely this growing kind of like strain of people telling him like, Oh, you don’t need to move to microservices, here’s all the companies that move back. And, you know, Oh, you don’t, you don’t need to run a mindful monolith. Here’s all the companies that move from a monolith to microservices. And every company did it for probably different reasons. But, you know, they, they’re ultimately just trying to create business value for their users and trying to enable their engineering team to do that. There’s, there’s different ways of doing that and have at it.
Cameron Weibel
I was gonna say, I want to highlight that joy, I think it’s great that you said it is that at the end of the day, it’s the business value like it did at the end of the day, it’s just a tool, so you’re able to remind your customers business value. And I think also, it’s kind of reminiscent of the debate you have between developers about which programming language is the best. At the end of the day, it’s like the one that suits you best, and gives your developers about the highest velocity and work for your company, you could build the most amazing microservices architecture for a product that nobody uses, right?
Joey Parsons
And nobody’s gonna ever know or care that you that. Or you could do that on top of a monolith and end up in the same way, right? I mean, Facebook’s one of the most successful companies out there, and they largely have still run off with just a giant PHP monolith. And yeah, it works for them. But uh, you know, Airbnb got to the point where, where it was already a unicorn and, you know, a force in the industry, just simply running off a Ruby on Rails app, right? And doing that at scale. And Twitter the same way, right. So there’s, there’s, there’s opportunities that, you know, people can build businesses in a bunch of different ways. And there’s so much great technology out there to enable it. It’s hard for me to knock anybody for doing it in a particular way. When, when, when you know, ultimately, like again, the other goal was to create business value.
Erasmus Elsner 34:38
You spearheaded at Airbnb, the move from the monolith to the microservices architecture. What was the tipping point where you said we we need to break this apart and when I looked into it, I think the standard approach when moving from the monolith to microservices architecture is that you identify individual business functions, technical functions, Then you start breaking it one by one apart, you let it run in parallel, you’re tested. And then at one point, it sort of splits up. Talk to us about this process.
Joey Parsons 35:11
So first off, it was like a pretty big team collaboration at Airbnb. But that led to the point where we’re moved to microservices. And it was a multi year effort across, you know, pretty much the entire engineering organization, and there was a lot of really great teams, you know, building enablement to ensure that that happens. But, you know, ultimately, like, the tipping point was that, you know, we were a fast growing company, that was hiring some of the best engineers in Silicon Valley. And we wanted to enable them the ability to move quickly and build new businesses on top of the Airbnb platform. And, you know, when I joined the company, you know, in the middle of 2015, and, you know, we had 150 200 engineers at the point, it that wasn’t, that wasn’t possible, we can move fairly quickly, right, like, we were still, you know, incredibly successful company, our ability from from an infrastructure platform to enable those engineers, those, you know, we were doubling in size, pretty much every year, from that point on enabling those engineers to do their best work, is what we really needed to do, there probably could have been a ton of work that we did, to enable the monolith to be able to do that, right, there’s, there was probably, you know, opportunities there. But I think that, you know, we made a decision fairly early on that, you know, like, let’s, let’s begin kind of, like breaking this out, let’s allow our teams to be autonomous and really kind of like, own their own services and their own applications. And let’s figure out kind of, as you mentioned, a, you know, a gradual approach, right? It wasn’t like suddenly, in the, you know, end of 2013 we turned off a monolith and had all these, you know, hundreds or 1000s of services. It’s a multi year approach. It’s still ongoing today, right? Like, I don’t believe the monorail. The monorail, the monolithic Rails app is still, you know, it’s still it’s, there’s still production traffic going through it, right. But we started breaking apart some of like the primary components, right, the things that obviously have, like their own business logic and their own kind of their own kind of like data model around you, like he might break apart, like, the data that has homes, right, like the actual homes on the platform, you might start breaking apart, like different components of search, you might break apart, like the billing services, and the pricing services, reviews and things like that. And, you know, kind of like the, the more kind of like obvious models within kind of like the Airbnb ecosystem. And then slowly begin kind of like building this culture of, instead of adding to like the monolith, when you add a needed committee and need to add a new feature, instead, you kind of like go down this approach to like, build a new service. And it’s a multi year thing, right? Like, when Twitter famously did this, they were in a similar, you know, similar situation where they were running a Ruby on Rails app. And, and in the early days of Twitter, it was failing all the time. Right. And that, you know, they began moving towards like Java micro services, or maybe Scala micro services. At that point, it enabled them to kind of like, move quickly and solve some of the both their productivity reliability challenges. So
Erasmus Elsner 38:00
Talk a little bit more about how you managed microservices at Airbnb once they were put in place. And I think you talked about this. Previously, there were basically these two approaches, you had this YAML tracking app on the one side, and then you had this slack and pager duty listener, this in house build service, how did this prepare you or shape your senses? For for the need of effx out there? Talk to us a little bit about Yeah,
Joey Parsons 38:24
Yeah, so some of the big challenges that we were beginning to run into is that you end up with, say, 1000, different services that exist within an engineering organization, and you were you were even kind of mentioning from like, an Uber perspective, you know, what all these different names mean? Right? Imagine, you know, imagine being an engineer in a company where, you know, there’s 1000 different microservices, and they’re all just named, very random things, right? No naming scheme is going to survive, you know, 30 services, much less 100 or 1000. Right. So, you know, your search service could be named after like a fictitional, like cartoon character, right? The the home service might be named after something in Spanish. And then, you know, the availability service on the calendar might be named after something that you don’t even quite understand. Right? And, and trying to piece all that information together, especially when things are bad, or things have gone gone down, or there’s like, downtime becomes quite a big challenge, right? Much less understanding, kind of, like, you know, what language The service was written in? Like, what team owns it, like what tier of service it’s in? Where are its best dashboards? Like, what what observability tools I need to go look at to see the health of the service? Where’s the diversion control if I need to make a change, right, all this stuff that, you know, and, you know, intuitively, you would have like an engineer, just kind of like grass, and it’s being really difficult to find, right? Like, you might have bookmarks being passed around, or engineers talking to each other in slack and like your DMS, they might have this information. And, you know, we felt the need, you know, starting with like ownership, like what team is ultimately responsible for this health of the service becomes really important and we had a few initiatives where we create spreadsheets. But like a wiki page to kind of like track that. But then you know, two weeks later would be out of date, right, because it didn’t exist in code. And it didn’t exist in a way for an engineer to be able to easily consume. And then from the perspective of like deploys, and all the different changes that can happen to that service, you know, there’s there’s deploys, there’s feature flags, there’s experiments that are being brought, there’s capacity changes, all these things can change the state of service. And when you’re dealing with one monitor, like one monolithic app, really easy, like there might be like, you know, one UI, we’re seeing this data. But when you have this distributed system of you know, these 1000 components, where one change, maybe two services downstream can affect the service that you’re working on, you need to kind of know that information. So we built a tool internally, that was basically captured all of these change events, to where you can see like, okay, you know, what does change all in like, the last five minutes, and give the person that’s either looking at an issue or debugging an incident, all the context that they needed, so that, you know, let’s say, you get paged in the middle of the afternoon? And it’s like, 4pm, you know, you could easily look into like, Oh, you know, Joey, turn that turn on that feature flag on that service three minutes ago, probably related to that, right. It’s, it’s, it’s, you know, the the downtime that I’m looking at is probably, you know, somewhat related to that. So I think that there’s, you know, it actually became, you know, a pretty, a pretty key component with an incident response, to be able to understand all the different changes that were happening. And ultimately, that’s really kind of like what led to effx, right, I looked at these same problems, through the lens of, you know, friends in the industry that we’re at similarly sized companies to Airbnb, or were starting their own company, or in like the fortune 500 space that were adopting microservices, and realize that everybody was having a lot of these same challenges, right? They all needed this, this concept of like a service directory, a service catalog, but also needed kind of like this way to aggregate all this information about services from all the tools that you already had, and displayed in a really kind of like, nice, consistent way. So that, you know, as an engineer, you understand everything that’s happening within your organization, both from like, the people that are making deploys the deploys that are happening, the changes that are ongoing through a day to day basis, that way, if something goes wrong, you have all that context to help you figure out what to do next, all the different contributing factors that could be leading to, you know, what you’re what you’re looking at.
Erasmus Elsner 42:12
So one thing that’s always mentioned is, microservices often operate in combination with Kubernetes. So how does effx and your product integrate into Kubernetes?
Joey Parsons 42:23
Yeah, so you know that that was definitely a trend that we saw, right. So most of the organizations that we talked to, that that had been, you know, deep into this world of microservices were using Kubernetes. Right, I think it’s, you know, when it would probably like the most ubiquitous choice these days for for doing, you know, container orchestration and service orchestration. So, really early on, that was the first integration that we built into the platform, we wanted it to be really easy for people to get their services into effx with with, you know, really low effort. So you know, we built a an agent that we can basically drop as a pod into your Kubernetes cluster, it discovers all of the services that are running within that cluster and information about them, as well as tracking changes to either, you know, the number of replicas that are running, if it’s scaling up or scaling down, and the status of the deployments right, and how it’s been as a new version have been deployed and things like that. And then we consume all that information into our SaaS platform and, and build out kind of like your initial service catalog. So we felt that, you know, it was it was, it was a great opportunity to, to, you know, go down that path. And I think that, you know, we’ve really geared effx towards, you know, where companies are going, you know, cloud native technologies, especially Kubernetes, and all the different service mesh tools out there. Because we really feel like that’s the future where people are building microservices, and we want it to be able to, you know, really cater to that market, and carry cater to the teams that are using those tools effectively.
Erasmus Elsner 43:44
Makes a lot of sense. So let’s talk about the current state of the business. So you’ve long surpassed the point of the MVP, and you’re at the moment starting to roll out proof of concepts and pilots with initial customers Talk to us a little bit how how that journey is going, how you’re finding them, how you’re working with them on a day to day basis?
Joey Parsons 44:03
Yeah, so 2019, you know, we spent most of that most of that year, just kind of, you know, building the initial product, right, getting to the point where, where we really wanted to show it to people, and, you know, we spent, you know, the early part of 2020, opening up kind of like a pilot program. So, you know, you know, talking to friends talking to folks that we’ve been through been introduced to talking to people that, you know, had written about, like, their experiences of using microservices. And you know, get it into their hands and get feedback, right. And it’s been kind of like this collaborative process where, you know, they, they get their services, and you’re like, oh, wow, we should do this, right? And then we’d spend a little bit of time with them thinking through kind of like, Okay, what, like, what, what’s the value that you would get out of that? And, you know, what pain point is that solving and, you know, how would you How would you see that working right? And, and really just kind of like iterating on that for, you know, the beginning part of the year, up into the point where, you know, just a couple of weeks ago, as part of like our funding announcement, we actually opened up our product for self service, and so as of July 20, You know, anybody can come to the platform, sign up for free, create a 14 day free trial and begin using the product just from just from the start there. So, you know, I think that, you know, we felt pretty confident, you know, during the latter half of the latter half of q1 or q2, that, you know, we built something that provides a lot of really great value for companies, especially companies that, you know, fully adopting things like AWS, lambda Kubernetes, and, you know, modern cloud native technology. And we’ve given them a solution to where they can really understand what’s going on in their microservices environment, track things like ownership, track that activity feed, so that we understand all the different changes that are happening, got to the point where Yeah, we felt that it was time to kind of, you know, plant a stake in the ground and say, like, you know, here we are, let’s, let’s, let’s open this up to let’s open this up to the tiller world. And it’s been an exciting, exciting two weeks, where, you know, the amount of feedback and the amount of engagement we’ve gotten is, you know, has been has been amazing. And, you know, we’re continuing to learn continuing to iterate and continuing to make sure that we have a product that you know, people love and solves pain points for them on a daily basis.
Erasmus Elsner 46:07
This brings me to the last point, the fundraising journey, you recently announced a USD 3.9 million seed round, which was led by Kleiner Perkins, alongside Cowboy Ventures. How did this round come together?
Joey Parsons 46:20
Yeah, so it’s always like an interesting journey. I think that, you know, obviously, I’ve had a long relationship with Kleiner. And, you know, I worked really closely with Bucky Fuller, right, like he was, you know, pretty instrumental. And, you know, they’re very, very early stages of effx in ideating. With me on, you know, coming up with the idea and really helping us through our first year, right. You know, they were able to put us in front of a lot of people and give us great advice for for, you know, what effx, you know, became and continues to, to say, I actually met Amanda Robson, who is a principal at cowboy ventures at cube con. Right. So we had a booth at cube con, and you know, her and I spent some time, just kind of like talking about the product, getting to know cowboy Eric thing, who I mentioned earlier, he’s also an advisor for cowboy for quite a bit of time. So there was a little bit of a connection there, but spent a really good amount of time with Amanda just kind of like talking about the business and talking through some of the challenges and we really hit it off, there’s opportunities when you’re fundraising to find people that you know, really are going to help and have the hustle to really kind of like, help out your business and, you know, and do whatever they can to help you succeed. And I felt like the team that cowboy was that and, you know, they’re just great people, they’re, they’re, you know, great people to be around very, you know, honest, straightforward, great feedback, and, you know, have have really kind of like, help push us to the next level. So, I would say that, you know, that that that combination of both cowboy and Kleiner, I feel incredibly lucky and privileged to have been able to put together you know, put together a really great team here. So, you know, we didn’t go through the process of like running like a full process, right? We didn’t go out and pitch a bunch of different VC firms and things like that we’d found teams that we really connected with him and really wanted to work with and thankfully, they really wanted to work with us as well. So worked out worked out fairly well for us. Yeah,
Erasmus Elsner 48:08
Joey, thank you so much for being with us here today. For our audience, where can we find out more about effx and what you’re up to personally and as a company as well?
Joey Parsons 48:18
Yeah, so if you want to learn more, a little bit about effx, go to effx.com. You can sign up for a 14 day free trial and check out the platform that we’ve been talking about, you know, to find out a little bit more about the company. You can find us on Twitter at effxhq. And then for myself, I’m just Joey Parsons on Twitter. So feel free to engage send me a DM ask any questions if you want to talk about microservices versus monoliths, or talk about entrepreneurship in the face of being like a new dad. I’m open to any and all conversation. So thanks again for the time. I was excited to have this conversation today. And I really appreciate you giving us the opportunity to talk about you know what we don’t hear.