Mike Gordon:

You have to assume that mistakes will be made and changes will break, and so you have to have a good plan to recover from them. But you don’t want the fear of making changes and things happen. And so the problem generally isn’t that the person made a mistake, the problem is, well, what was the system around it that allowed the mistake or allowed it to go into production or didn’t catch it fast enough?

David Joy:

What is up everyone? And thanks for tuning in. In today’s episode of the Big Ideas in App Architecture podcast, I speak to Mike Gordon, who is the VP of platform engineering at Fivetran. Mike and I talk about Fivetran and get into Mike’s role and how his engineering teams are solving for scale. We also get into some fascinating projects that he had worked on during his time at Google, and we also talk about his advice to young engineers looking to lead. So pump up that volume and get ready for this amazing conversation with Mike Gordon.

All right. Mike, how are you doing today?

Mike Gordon:

Good. How are you doing?

David Joy:

Usually doing a Friday call is mostly the most relaxed that I am. Is that the same for you?

Mike Gordon:

Yeah, most of my Fridays are pretty open. Last week I was busy all day Friday, but I’m a little bit better today.

David Joy:

You work for a great company called Fivetran. But before I mess up the introduction, why don’t you let everybody know who’s listening right now as to what your role at Fivetran is and what do you and your team actually do it at Fivetran?

Mike Gordon:

So my role is VP of platform engineering at Fivetran. And a few different companies consider platform engineering to be different things. At Fivetran, our platform engineering team is our infrastructure and SRE, our core software team and group, our quality engineering, and then we have a dev productivity group that manages our CICD and engineering automation. So that’s what platform engineering consists of, and we’re one of five or six global engineering groups that focus on different parts of our system or product.

David Joy:

So how big is your team right now that you’re managing?

Mike Gordon:

In platform engineering, we’re around 110, give or take a few. So a pretty big portion of engineering. Total in engineering I think is around 400, 450.

David Joy:

That’s awesome. So your career, and I was going through this, fascinating career. You’ve been in the US Army before, and correct me if I’m wrong in that, and from there you got into tech, worked at Google, you worked at Hippo Insurance, and now at Fivetran. And it’s been fascinating, especially your Google experience was really interesting. I was reading through it. Tell me how did you decide to get into tech early on?

Mike Gordon:

Yeah. So early on I liked to play with computers. I learned on an Apple IIe way back in the 1980s. And so really ever since I was a kid I liked to play with computers. And so that kind of drove me getting into tech. And it’s good to be in a field I think too where you produce something, and you can look at it and say, “Oh, I had a hand in doing that.” So that’s also a good reason. And then we just have a lot of interesting and hard problems to solve.

David Joy:

Any significant moments early on that really made you confirmed in the idea that, “Hey, I need to be in tech and I need to do engineering as my life’s mission?”

Mike Gordon:

When I was younger I used to tinker with a computer and I used to try and program games and 3D games and it was just something that I’d spend hours on. And so I think that partly influenced it. And then when I was in college, I actually thought about majoring in economics. So I took a semester of macroeconomics, and I barely squeezed out a B from the class. And I said, “You know what? I should probably major in something that I’m best at.” So I ended up majoring in computer science.

David Joy:

The funny thing about people who are in tech today, one of the things I found very common is that they’re also really either artistic or they’re musicians or they’re gamers. So I’ve seen at least one of these traits. So do you have any of these significant side hobbies also like a musician or a gamer or something else that you associate along with being an engineer?

Mike Gordon:

Yeah, I’ve been a gamer, especially when I was younger. I don’t seem to find the time today to do too much of it except to play with my son on his Nintendo Switch. But I think that’s one of the things is I would play games when I was younger and then see if I could write games that were similar to them.

David Joy:

That’s awesome. That’s brilliant. Thank you for sharing a little bit of your past and how you got into this. For folks listening, first time I got introduced to Fivetran was I was trying to work on a problem where I needed to do some data ingestion and some ETL, and I found Fivetran had a connector that will allow me to move data from Salesforce into a data warehouse that we had. And that was my first exposure. But you being in the company, help me understand, what does Fivetran do and bring to the world?

Mike Gordon:

Yeah. So Fivetran is a data movement company, and what we do is we provide a platform so that if you want to take data from any number of, I think we’re almost at 400 sources and connectors, you can just sign up for Fivetran, connect to your source, and it will sync that data into a destination. And it’s quick and it’s seamless and it’s easy to use. And the alternative is really difficult in that, especially if you have say a database, you would have to write some kind of sync job and spend a lot of time debugging it and to figure out how to get data from point A to point B, and Fivetran just does that. And so we like to make data as simple as electricity, you just plug it in and go.

David Joy:

That’s awesome. How different is it from general change data capture?

Mike Gordon:

Change data capture is part of what we do, and so we will capture data from databases for change data. But because we sync from such a large variety of sources, we’ve basically normalized that and said, well, you have APIs that don’t have that concept, or you could have a data lake as a source or a file as a source that doesn’t really produce a change data capture, it’s just a block of data.

And so what we do at Fivetran is we have connectors that normalize that into kind of the same stream and the same format for our core, and then our core takes that input and then loads it into a variety of destinations as well. And so we’ve kind of taken that change data capture concept and applied it to lots of different sources, not just certain databases.

David Joy:

Right. And the way I see this is you’re trying to basically generalize it as much as you can across the industry by providing as many connectors as possible for all sources and target, and kind of truly are becoming the company that is doing data movement. And that’s a fascinating objective, mission, and a goal.

Mike Gordon:

Yeah, it is. And I think one of the big hallmarks of our product too is reliability. And so we want to do it reliably. Because it’s not hard to just sync data, but it’s really hard to sync it reliably.

David Joy:

Right. So can we go a little bit deeper into that? When you talk about reliability, how do you structure it within your design parameters?

Mike Gordon:

We consider it uptime. And so we’re pretty metrics driven in that our reliability is, for every sync we attempt, we have a certain number of retries, and then if we fail at a retry that we consider that a failure. And so we try and keep a level of three-nines reliability for all of our connectors, which we’ve been able to maintain.

And so reliability is one of our most important aspects of the system. So we have concepts, like our syncs are generally item potent, for example. And so if we have part of a sync fail, it should be able to pick up in the middle of a sync and not miss anything, so there’s not this state where it leaves your data from the source to destination in a place where you can’t recover. And so that’s an important part of our reliability.

And the ability to have the item potence and the ability to start and retry from where it left off, are two of the big things that we do.

David Joy:

That’s awesome. And especially in the last seven, eight years, and you’ve been in the space for a while, data has become so critical to an enterprise or to any company, because everybody’s trying to make decisions out of data. And at the end of the day, if a data remains in a stale bucket, you can’t do anything with it. And you can use something like Fivetran to move data into an analytics engine or a warehouse, and then start to make some sense out of it.

So have you seen, especially in the last seven, six years, this explosion of data kind of driving the need for reliability, the need for scale, all those things, into the product that you’re building?

Mike Gordon:

Yeah, I have. And I’ve even seen it as a customer. So before I was at Fivetran, I was at Hippo Insurance, and for three years was a customer of Fivetran. And data, for insurance or really any other industry, is essential. You have to be able to sync data from a number of sources, and for insurance for example you need to be able to assess whether the data you have on a home is going to predict whether you have to pay a claim on a policy. And the amount of data that I observed say teams of actuaries needing, just grew over time. And so it’s just this constant growth and demand of data.

Someone in the company would say, “Oh, you sync this source. Well, I want the data from this source. Can you do it?” And it’s nice to be able to answer, “Yes, we can do it.” And once we do, it’s kind of a point and click with Fivetran and we don’t have to worry about whether it’s going to break or not over time.

And then we would also start, I know previously before Fivetran at Hippo, we would train ML models. And so you see either the proliferation of LLMs that need just a huge stream of data to train, or just even models that try and optimize a different problem. It’s just this endless flow in demand that’s necessary to be able to keep these models running and up to date. And so the demand over time just from the customer side grew.

And then now from the Fivetran side, it’s more my problem to make sure that we can handle that growth.

David Joy:

And does the product currently, is it a product that runs on the cloud as a SaaS solution, or is it something that folks can self-host and run on their environment? How does that operate?

Mike Gordon:

Yeah, Fivetran by default is a SaaS solution, but we do offer an on-premise product too. We call it local data processing. And so it’s a slightly different code base, but we have a lot of big enterprise customers using that product too. If they don’t want say the data to leave their enterprise, they can use it. And we’re working on making those products more unified right now.

But primarily Fivetran’s a SaaS product, and that’s what certainly my experience as a customer was with the SaaS product.

David Joy:

That’s brilliant. And do you operate on every cloud that is available?

Mike Gordon:

We do. We operate on all three clouds, or all three major clouds. So AWS, Azure, and GCP. And part of the reason is that for enterprise customers, they want to be able to choose what cloud their syncs run on, they want their syncs to be close to their data, and so we allow them that choice. So we have the challenge of running in all of the clouds too.

David Joy:

Right, yeah. And you, having worked at Google Cloud and having that background early on as the cloud was picking up early 2010s, and then I remember you and I were talking, you mentioned that at Hippo you got exposed to working and running AWS and then you also have Azure now.

So how do you feel like this cloud… Of course for enterprises to build applications, to grow, the whole gambit of scale, the cloud platforms and infrastructure being available has been really helpful. What are your opinions as to how that has changed or helped you as a person and leading teams at Google, Hippo, as well as at Fivetran drive growth?

Mike Gordon:

Yeah. I think the cloud has made growth more accessible. In 2010 for example, the only people who had true access to the scale of the cloud were big tech companies. And then AWS obviously came out. So you either needed to be a big tech company or have thousands of servers or have a mainframe. And if you didn’t, then you couldn’t scale to the level that you can now where you can spin up thousands of servers by just putting a credit card down. And let’s say you wanted to build a new LLM, you could just do it and run 5, 10, 15,000 servers at a time. And so that’s a big jump, is that accessibility.

But it’s not just hardware I think, it’s also the systems that are provided in the cloud. I know when I was at Google, I joined Google in 2011, and by that point Google had a number of really best in class systems. And so over time they open sourced and publicized these. But it’s not like from outside of Google, you could use some of these systems. So there was a time where you wouldn’t even have access to say time series observability before that.

But now you have Prometheus and a huge array of software as a service solutions for observability that’ll just scale into infinity. And so you can really see that the cloud made that possible.

David Joy:

The rapid pace of technology is intense. I was talking to somebody I think a few months ago who was saying that in 1998 they had to write their own database because they felt Oracle was way expensive. And then today we have a plethora of databases available that cater to so many different workloads because our needs have changed so much, right? Folks want scale, folks want to run across multiple cloud environments. Or folks are like, “Hey, say on the infrastructure side of things, we don’t want servers anymore, we want VMs.” A developer comes and says, “I don’t want a VM, I want a container.” And there are so many options now available, and now all of these different solutions are also available on the cloud.

So I totally agree with you about the accessibility part of it. You can go to AWS and start EKS with Kubernetes, or you can go to GCP and just run GKE, or you can choose whichever database that you want. So I personally feel like this is a great time to be an engineer, because you’re not limited to a solution that you have to make work. You can always say, “Let me go try something else.”

So it’s a little bit of a pivot question, in your team, how do you manage coping up with all of these new technologies that are coming and doing R&D and your engineers trying to say, “Okay, can we try a new technology here?” or apply that in principle to your company tech objectives?

Mike Gordon:

Yeah. We do a few things for that. First is we run twice a yearly hackathons, and so that gives our teams and engineers a chance to, say, try a new idea that might necessarily not be a mainstream idea or something that we would do during the course of the work where we have to get certain things done at a certain time. So I think that’s one thing we do.

The other thing that we do at Fivetran that I’ve introduced is an architecture management and review process, with the idea being, really at any company, and as you get bigger from small startup, you have to start making technology decisions so everyone’s using the same technology. But you also need a forum for people to say, “Well, I have this idea and this thing will work better, and why don’t we do this?” And so we have that forum where anyone can actually propose a change, and then we have a group of senior engineers who assess the change and come to a consensus. But we have at least that open door and open forum for people to be able to say, “I have an idea,” or “I can make this thing better with this,” without us having, say, complete chaos.

David Joy:

No, I mean, I completely understand that. And having a group of people to make that decision makes so much sense. It’s like a group of authority people. And engineers are very attached to their pet projects and stuff they’re doing, and sometimes we can be clingy and we feel like this is the only solution and we sometimes are not as self-critical as we should be. So I think that kind of a policy and having a process like that is really fascinating.

So tell me this, you worked at Google and you were kind of on the side of building a team out there. Expand on that role and that experience. And I know you worked on the Google Marketplace as well, pushing out Gmail and things like that. Let the people know about what you did there and how fascinating was it to work in an environment like that?

Mike Gordon:

Yeah. At Google, I did a few different things over the time I was there. The first thing I did was actually build a team to build applications to manage and design Google’s networks. So Google has, I think it’s still the biggest network in the world. It’s been a little while since I worked there. But the idea of being able to design and inventory every single piece down to the physical connector of a network was something that that organization needed to do.

Because what was happening is they were designing networks in diagrams. Well, it got too big for diagrams, and so they were doing it in spreadsheets. And then it got too big for spreadsheets and they needed some kind of a visual application that would manage that. And so that was the first thing I did, was work on application to manage and visualize and look at if there was a change, it would calculate that change and then show what the difference in the network would be, kind of like a physical network diagram.

So that was really interesting work to do, and it was a really good introduction to the scale of Google and the tools that you had back when I was there in 2011 and on to be able to do that with.

And so I did that for a few years, and then worked on a product called App Maker, which was a rapid application development tool. It was an internal app that we ended up going externally GA with. I managed part of the team there, the editor side of it. So if you think like a Wizzywig app editor that we released. And that was a really fun space to work in. Actually a lot of the time I spent there was more front end focused, and so I had some exposure not just to the backend, but then the front end there, which was really interesting.

And then after that, a few years later, through that time, we needed someone to take on the, it’s the Google Workspace marketplace. So yeah, if you go to Gmail and you try and add an extension, it’s that marketplace. And so we were moving the product from one location to another. I had to build a team from zero to take that on and then start making enhancements and taking control of the product. And that was also a good lesson in scale, because over the years, there were a lot of dependencies built up on this app marketplace where all of Google’s products depended on it. So if it went out, then you could bring down Google Docs. And I didn’t want to bring down Google Docs.

David Joy:

You don’t want an email coming from your CEO directly to you because, “Hey, why is my Google doc not opening?” So I was just curious.

When you said these three projects that you worked on, these are all such significant projects that you have worked on. I mean, one of the things I like about, especially Google Cloud personally, is the unified network that they have, and however they have abstracted that network to be so easily accessible, the way we connect, we do VPCs and everything, so easy within that environment.

So when you first got exposed to the scale of Google and this network, what were your first thoughts? Did you have to even consider the physical lines that are put across continents? You had to consider that in this whole process?

Mike Gordon:

Yeah. Yeah, it was the physical connections. And Google right now has bought some of their own fiber cables, so that was going on when I was there as well. And so we had to take that into account.

And something that really surprised me too when I had joined is, you don’t realize it, but Google has a presence in basically every city in the world. There’s some Google equipment to serve either YouTube videos or run Google Docs. And so you don’t realize it, but they had been working on that edge for a pretty long time. And so now maybe it’s a more typical thing. You have CDNs that can do that for you. But back then just the sheer size of the network and how far it got penetrated into cities was pretty amazing.

David Joy:

Tell me a little bit more about the project that you were saying, the last project around the marketplace. Was it the project that was accessible to every user who has a Gmail account? Or was it what turned into the enterprise solution of Gmail that everybody now has access to?

Mike Gordon:

The idea back then was that you had a way to write extensions into each of the Google products. And you still do, it’s built on app script, which is kind of like an evolution of what a lot of people use VBScript for the Microsoft products. And so Google App script is the equivalent, but it runs in the cloud. And so you’d be able to write a sheets extension or a Docs extension. So you see a Docs extension that’ll check your grammar, for example.

And so there are thousands of these extensions available, and some of them go along with a paid service say that the company would offer. So what they do is they build all these extensions also to integrate with Google Docs so that customers get more value out of it. So it’s accessible to everyone.

I think we called it the enterprise app marketplace because we were focused on enterprises and people who are paying for Google products, but it is accessible. These extensions are accessible to everyone.

David Joy:

Tell me a little bit about your leadership philosophy. Because you’ve built great teams at Google, you were leading teams that Hippo Insurance, and now you’re leading the team at Fivetran. Over the years, how has your leadership philosophy, has it changed much? Or what are they?

Mike Gordon:

Yeah, that’s a good question. And over the years I think it’s evolved. It’s funny because I’ve had an evolution from started in the Army and ended up at Google, and those two are mostly polar opposites. And really at any tech company and Fivetran now too, it’s a very different culture. And so it was a progression, I guess I’d say.

When I left the Army, I went to work for a defense contractor for a while and kind of dipped my toe into tech, but it was still kind of a comfortable place. And then I worked at a hospital in Los Angeles managing a team that would build all of their internal and external applications. And so that was another step, and then Google after that. And so it’s evolved over time, I think.

So you can’t obviously just tell people what to do all the time. It’s really situational, I guess I’d say. And that’s the way I look at it is that, every situation is different, every person is different, and everyone’s motivations are really different too. And so you have to take that into account as you kind of lead a team. So that’s one thing that I take into account.

I think the other thing that I like to see in managers and I try and do myself is, you can’t ask people to do something if you wouldn’t at least be capable of doing it yourself. Maybe I don’t write code all day and it would take me a while to get back into doing that, but I think the point is that I should also stay on top of what we’re doing technically, and we try and hire managers also that can do that with their teams.

David Joy:

Right. So that leads into a question. There’s so much going on in tech, so many different projects coming, so many different ideas. How do you keep up with all these trends and keep up with what’s happening? And going back to a conversation, anybody comes up to you and says something, how do you know that, okay, I get it, I’m able to track what you’re trying to say?

Mike Gordon:

Yeah. I think spending time with some of the technologies myself, whether it’s at the end of a workday or maybe on some of my free time, I think that’s something I try to do. I write a little bit of code on the side. I think reading a lot too. And on Medium for example, there’s a lot of articles that are garbage, but there’s a lot of good ones too. And so spending the time reading about new technologies, and whether it’s from an online source like that or whether it’s from reading books.

Another way I’ve actually kind of found that helps is writing. I think writing really forces you… You don’t want to put something out there that’s half-baked, and so it really forces you to learn and think. And so I do try and spend some time writing, whether it’s either a public blog post or even internally, I send an every other week update. And by being forced to write, I’m also forced to know what’s going on. And so I think writing helps as well.

David Joy:

Yeah. I mean, some people I feel have this innate ability to manage time so well. I don’t have that ability. I think I’ve managed decently, but not to the point where you can do everything that you’ve thought about during the day. How are you with time management though?

Mike Gordon:

It depends on the situation. So at Fivetran, I tend to have meetings early. And so that would normally, in the past, that would be my time, 7:00 AM to 9:00 AM would be my time to catch up and kind of get prepared. I don’t have that anymore, since my meetings are mostly from 7:00 to noon. But then what I’ll do is in the afternoon or at the end of the day is just catch up for the next day then.

And so I think spending some time and just thinking about what are your goals for the day, either today or tomorrow, I think helps to be able to kind of parcel your time out.

David Joy:

Yeah. I think that’s a great advice to folks who are all over the place. I think there needs to be some time to get organized and focus and get back into the things. And calls are going to be never ending in this day and age where we actually all work remotely. So you have to figure that out.

I want to pivot to asking a question around, as you build teams, especially platform engineering is what you’re doing right now, what are a few of the challenges that you see these teams coming across on a day-to-day basis or you have seen and have handled?

Mike Gordon:

Yeah. So I think one thing is we’re metrics driven. And so for any of the challenges, we try and have a metric to say, this is what success means for this. So I talked a little bit about the uptime measurement. And as a platform team, I’m responsible for a few things. One is reliability, particularly of infrastructure reliability. I think two is providing a software platform that the rest of the engineering organization can use and is fast and just works.

And so in doing these things, I think we set metrics for these goals. So for our uptime calculation, we continually make it more restrictive and we say, okay, well, we got to this level. Now what if we consider every error as an outage and go from there? So I think that’s one of the things, is being able to look at the metrics and squeezing in as you go.

I think scale is another one that in platform engineering we really have to think of. And at first it starts to be scale, but then eventually, like I said before, cost becomes a factor. And so we rent compute, and we use it to sync data, and so we want to make that as efficient as possible. And so there’s things we do that, at Fivetran we’re actually pretty successful with the cost side of it. And we’ve put in features like autoscaling. Kubernetes lends itself really well to autoscaling, for example.

Memory management is another thing, and thinking about memory and CPU and thread management. Which are interesting problems. I kind of look at it as for our problems, particularly for platform type problems, whether it’s infrastructure or code, you really have to think like a C programmer. How do I maintain my resources? And there’s a certain type of engineer who really likes those problems and really cares about performance, and so I think those people fit really well in platform engineering. You want to squeeze every last bit out of that CPU. And so that’s another thing we do.

And then having to think about all three clouds is a challenge, I think. We try and make our infrastructure as uniform as possible, and we use some frameworks like Kubernetes to do that. But all the clouds have differences, and so those are challenges for us to tackle. Now, I’d say it’s also a good place for SREs though, because they get a chance to learn all three clouds. And so it’s appealing to be able to say, “Well, okay, you just figured out how to do this in AWS. How do you do it in Azure?” And so we do have those kinds of challenges that people have in Fivetran.

But it is hard to keep organized with all the surface area and all the different things you can do. It’s challenging to keep organized.

David Joy:

Oh, yeah. And the kind of problem you’re trying to solve is a complex one. I mean, Kubernetes is a fascinating project that came out of Google and it’s become actually sometimes very complex to implement. You don’t have a lot of people who are able to nail it down exactly how you want it. But resourcing and recruiting the right people is as equally important to a project for its success.

So have you had any challenges around recruiting? I mean, you will have somebody who might be great at EKS, but you want him to do GKE. And have you had challenges exploring recruiting around that?

Mike Gordon:

Yeah, we’ve had challenges with recruiting. Over the past year, they’ve gotten a little bit better. I know during my time at Hippo, that was kind of the heyday of people changing jobs and tech being in demand, and that was really difficult. And there I actually spent personally a lot of effort on recruiting.

I still spend time on recruiting at Fivetran, but I think it’s actually slowly gotten a little bit easier to recruit. And for SREs, we want them to want to do different things. We want them to be excited about, say, go figure this out now for EKS, and to be able to do that.

So it’s always a challenge. I think recruiting and retaining a team is always a challenge. But I think we’ve been pretty good at it at Fivetran.

David Joy:

The whole idea of allowing people to make mistakes as they learn new things, that’s also critical. I think people who are in technology today are constantly looking to apply things that they learn into something that can go into production.

So what I wanted to ask you with that was, have you had any experiences where you were trying to do something in production and it just went down really badly, and then you had to scramble and figure out something? So tell us an episode or any experience like that.

Mike Gordon:

I’ll just take a view it of where I am now in that, in leading an organization, you want people to be aggressive in making changes and not being afraid to experiment. And so I think, for example, as a code base gets really large, more things can break. You can have more tests, you have more production code that can break.

It’s easy to get bogged down and paralyzed as an engineer to say, “Oh, I don’t know if I can make this change.” And so we do some things to try and foster that kind of momentum to say, “Yes, do go make the change.” And one of them we do is we release multiple times a day. And I think that itself is I think really important, because it gives engineers a chance to get really quick feedback on the changes they’ve made. They can watch it the same day while they still have the context and attention of what they’re working on. And so that’s one thing we do.

And then having good monitoring in place so when they do make a change and it blows up, we detect it really quickly before it becomes a big problem and we can reverse it really quickly. And so I think that’s another thing that’s really important, in that you have to assume that mistakes will be made and changes will break, and so you have to have a good plan to recover from them.

But you don’t want the fear of making changes, and so another thing is too to have a good postmortem process and a no blame process. Things happen. And so the problem generally isn’t that the person made a mistake, the problem is, well, what was the system around it that allowed the mistake or allowed it to go into production or didn’t catch it fast enough? And so that’s one of the other ways I think we address those kind of challenges.

David Joy:

I like what you said specifically around the fact that we need to understand what the systems are around it that caused that and what can we do to go back and put some breaks in between to make sure this doesn’t break again. So I really appreciate you bringing that insight out.

When your team works on these problems, are you looking at large scale deployments or these are smaller operations, and in many ways you get the time to see it in a smaller environment, see how it’s working before you see how it’s going to scale?

Mike Gordon:

Yeah. So I think the answer is it depends. But usually yes. If we make a big change, we’ll put it behind a feature flag and we’ll roll it out to ourselves or one customer or a small number of customers. And then we have certain cohorts that we end up rolling out changes to. And so that’s one thing that we do.

We also have the concept of canary for the… We run a few services. I wouldn’t call us a microservices architecture, because our syncs are basically batch syncs. But they do rely on a few services, and for those services we do have a canary rollout that we roll out and detect early. So that’s another thing that we do.

We’ve done a little bit of innovation around deployment too. And so we have some automation around when we deploy a bad build for a connector in production, we have some automation that will actually roll it back for us too. And so it’s something we’ve been piloting for a while, and I think we’ve finally gotten and tuned it to the point where it’s right enough that we’re using it. And so it will help really limit the size of mistakes as well.

And so all these things I think are things that add up to saying to our engineers, you can be aggressive. Your code goes out quickly. We have controls around it being rolled back if there’s a problem. And it ends up being that we can maybe minimize incidents and maximize uptime.

David Joy:

I’m pretty sure the automation that you have built around has to be tuned to your environment and the project that you have. Is it generalized enough that it can be open sourced for other people to take advantage of as well?

Mike Gordon:

Oh, I don’t know right now. I guess I’d have to ask our SRE team that. Yeah, it’s just something that we’ve been experimenting with now. But that’s a good question.

David Joy:

Yeah. I mean, I’m fascinated by innovation. If you look at this in a meta way, the Kubernetes project came out from a bunch of people trying to solve a problem within Google, turn it into an open source project, and now everybody’s taking advantage of it. So I love the fact that something that you have or some people did, you have taken it and try to put your own spin on it. And I’m excited mostly when I hear people building their own innovation engines and bringing it out. It’ll be fascinating for other companies and folks who are trying to solve the similar problems to take advantage of something like your…

Because it’s a very hard problem actually to catch a problem when you observe it. First you have to observe it and figure out, oh, there’s a problem here. And then know that you have to make the decision to roll back. It requires a lot of intelligence. So I was really fascinated by what you said. So I’ll be curious to know if you open source it or not because I’d love to check it out.

Mike Gordon:

Yeah. I’ll talk to our team. And part of it I think is a factor of just the way that our software runs, is because we run millions of syncs a day, and so we have millions of times it starts a day. So if the last one fails, we kind of have the luxury of saying, “Well, let’s run the next one on a different version.” And so I think that’s part of why we were able to do this.

David Joy:

I wanted to ask you, you have so many syncs running, and these are mostly batch… Or you mentioned batch, but also are you considering real-time experiences for sync connectors as well?

Mike Gordon:

Yeah. I mean, it’s something we always talk about. I know for the batch, we’ve continually reduced the time between syncs that we offer customers. And so while it doesn’t get exactly to real-time, it gets them close enough where they can have somewhat real-time systems.

I mean, we do have other methods for real-time syncs. We have a webhook capability for example that can trigger a sync on demand. And we have been working with some streaming as well, and so I think we’ll probably see maybe us pay more attention to that.

But overall, I think a lot of our goals are around making sure that if you have a large amount of data in the source, we can get it to the destination safely. And so I think our speed and reliability of doing that are our most important things. And then you might see some real-time capabilities show up, or at least us be able to support certain ones over time.

David Joy:

You’ve been a leader in the space for a while. You’ve built teams, led teams. What do you think is the future looking when it comes to the data space? I know we are already into 2023 and it’s been a wild year for AI and generative AI and large language models. That’s one gambit or cohort of things. Is that what you’re excited for when it comes to technology and looking at what’s going on?

Mike Gordon:

Yeah, that’s one of the things we’re excited for. I think data lake seems to be a big one now and is gaining a lot of traction. I think a lot of companies are seeing that certain products that you can build a data warehouse on top of a data lake work really well and syncs are fast and they’re consistent. And so it’s something we support as well, and we’ve had some recent releases of new data lake capabilities for S3 and for Azure. So that’s a big one.

And then I know I’m always looking and we’re always looking at AI. And AI is always hungry for data, and so I think that’s another one that’s big that we’re looking at. And we’re looking at ways we can use AI as well.

Our problem doesn’t always lend itself as well to AI as some others, but you have places in either support where being able to have ChatGPT scan our docs works pretty well. Or we’ve experimented a little bit with AI and the question of whether, could we get ChatGPT to write us the code for a connector and get us 80th percent of the way there? Maybe. Which is something I think you’ll see more in the future, is that engineers will work with some of these AI products as a companion. And so I don’t really see ChatGPT replacing engineers, but you’re going to see this companion where they say, “Okay, here’s my problem. Give me 80% of it and then I’ll take that 80% and turn it into the last 20%.”

David Joy:

I think so. I have similar thoughts as yours. I do not know if you explored the latest version of GPT-4 that has vision analysis or data analysis available. But for somebody like you were mentioning that you worked at Google and you had to do a little bit more explorations around front end.

I did this experiment about two weeks ago when I drew a webpage or how the components needs to be put together on a webpage, took the screenshot, gave it to ChatGPT, and it produced ReactJS components along with HTML and CSSs. I took all of that code, put it into Node.js, and within 15 minutes I had a basic boilerplate running website. Imagine if you got that in 2012, 2015.

Mike Gordon:

Yeah, I know. That’s pretty amazing that it does that. Yeah, I’ve wanted to try that with, I’ve always wondered, could you take an infrastructure design? What if I drew a network diagram? Could it write me the Terraform for that? Maybe it can now.

David Joy:

I feel like if we can train the model on Terraform data, then it should be fairly able to take that diagram and turn it into Terraform code. I know people have taken images of broken hand or bones and uploaded it and ChatGPT is giving you diagnosis, how to fix it.

These are fascinating things, but as you said, it can tell us what it knows from the training data. Again, it will not be able to give you the premium experience that an engineer gives you say at the end of what the result needs to look like. So 80% definitely is where we are right now with these.

Mike Gordon:

Yeah, it seems like it. And it still needs a lot of training data, and so that’s an opportunity for us at Fivetran to provide that data.

David Joy:

All right. So as we go in, about to end, I know we have five to 10 minutes left, I wanted to ask you, to young people or young engineers who are in this space, who are working on big ideas, trying to build applications, or even people who are already engineers and are looking to take that next step as leaders, what are your few advices to them?

Mike Gordon:

Yeah. I think certainly as engineers who are really working anywhere is, try and plan your own work out. I think a lot of us get stuck in saying, “Okay, what’s the next task? What’s the next task?” And I think there’s room for everyone to be a leader and a planner, especially in their own work or work with some of the people they work with. And it’s interesting that writing code and doing the planning out of the sequence of a project, are different skills. And so I guess my advice there would be lead something. Just start doing it. You don’t need to wait for someone to point to you to step up and do that. So I think that’s one thing I would say.

I’d also say that advancement isn’t always a straight line also. And that’s what I think a lot of people see, oh, it has to be this, then this, then this step. And it’s not always the case. Even when I had worked at the defense contractor, I was managing a team. And I said I have to get more back to the hands-on work and understand it a little better, and so I took a job that was a hands-on job and was an IC for a while. And so it wasn’t necessarily a straight line at every step of the way. There’s always some different ways you can go, and not everyone’s path is the same either.

I guess the last one I would say too as people advance is don’t lose the technical skills. Certainly for managers, most managers don’t code, we know that. Most of my work is not code, but I think it’s important not to lose that. And I’ve seen some organizations that say, “Well, we just want our managers to manage. All you do is deal with people.” And that’s the kind of organization where I would question, maybe that’s not a good place for someone who’s kind of engineering focused. Because engineering managers should like the engineering too.

David Joy:

Right. Oh, 100%. And I think especially the last one is so important because it’s also like you are speaking the same language with your engineers, otherwise it’s going to feel like lost in translation. And as tech evolves, everybody wants to keep up or cope up with what’s going on. So it’s a great advice, Mike.

All right. So Mike, thank you so much again for your time. It’s been such a pleasure having you. Great conversation. And I look forward to whatever you and your team are building, especially that project that I hope you can open source, if it’s possible to be open source.

Mike Gordon:

Yeah. I’ll let you know about that. Yeah, thanks for having me on.

David Joy:

All right, that’s awesome. Thank you so much again, Mike. And with that, we’ll close the podcast. Once again, thank you. And we’ll see you in another episode, guys. Thank you.