Making Smart Infrastructure Decisions with Lauren Long

Lauren Long: Essentially, the vision we have for the company is to make technology just more connected. So making it easier for one tool to talk to another so that there is this connectivity layer between different business applications.

Justin Garrison: Welcome to Fork Around and Find Out, the podcast about building, running, and maintaining software and systems.

Hello and welcome to Fork Around and Find Out. I am Justin Garrison and with me today is Autumn Nash and Lauren Long. How's it going, Lauren?

Great. How are you guys doing?

Justin Garrison: We're doing great.

We are excited to talk to

Justin Garrison: you. We are going to yaml indent our way through this host list of things that you do at Ampersand.

Can you tell us about Ampersand?

Autumn Nash: Oh, wait, why are you being mean to us? I'm trying to throw in a pun at the beginning

Justin Garrison: of every show and there's a yaml on their homepage.

Lauren Long: No, no. That was a really good joke. I'm very impressed.

Justin Garrison: See, we can, and like, I just look at the YAML list and I'm like, that is just, we're, we're going to go through this today.

So,

Autumn Nash: okay. Tell us about your

Justin Garrison: company.

Lauren Long: Sure. So we use YAML as we just mentioned, uh, Ampersand is a developer platform for building integrations. So we help SAS builders. We help AI engineers integrate with systems of records that their customers have. So some examples could be, you need to read sales data from someone's Salesforce or HubSpot.

Or you want to read customer support data from someone's Zendesk. And these kind of integrations are kind of hard to build and they're hard to maintain. So instead of doing that in house with your engineering team, you can use our configuration driven YAML spec to build an integration. We also offer components like an embeddable UI library, a dashboard for monitoring and doing customer support, and you can essentially focus your engineering efforts on the parts that make your product special and leave the integrations piece and the data movement piece to us.

Justin Garrison: I appreciate that you call out that, you know, you say, write your integrations in code. With a screenshot of YAML, literally just saying that YAML is code and we're all okay with this. And that's, I'm 100 percent on board. Like if you're writing YAML, own it. Like this is, this is code. And also a little bit of shade on the drag and drop editors right there too, which is cool.

What sort of infrastructure software, like what's on the back end there? Like how are you designing that? Is this, is this YAML spec an artifact of like, we're, we're writing Kubernetes manifest for you? Or is there something else going on here?

Lauren Long: Great question in terms of our, our, our stack underneath the hood.

So we run on Google cloud. We use Kubernetes. I'm an ex Google engineer. Call

Justin Garrison: it

Autumn Nash: out from the start. Dude, Lauren's just, she is a superhero out here.

Lauren Long: So, you know, we use a lot of, a lot of, uh, technology that, uh, you guys have already talked about on the show previously, we use Google compute engine. Uh, we use temporal, uh, which is an open source product that is helping us with the orchestration piece.

It helps with the workflow executions and some of the scheduling piece that we do. And it also helps us with retry logic, things like that, a bunch of other technologies I'm happy to dive into. But we were very heavy on the scalable and open source technologies.

Justin Garrison: I don't think we even started with like, we started with your name and the company, what's your position there?

Lauren Long: Yeah. So I am the co founder and CTO.

Justin Garrison: How did you, how did you decide like this was a problem? Like if you're a founder, you're going to build this thing. Like you were at Google, I'm assuming for before, and you're just like, I need to go build something else. And this is the thing that looks like it needs to be built.

Lauren Long: So I was on the Firebase team at Google. Firebase is a developer platform, and I was leading the Cloud Functions product, and then I led the launch of a new product called Firebase Extensions. So Firebase Extensions is a marketplace of prepackaged solutions that help Firebase apps add additional functionality.

With the click of a button, as we say, and a lot of those additional packages that we developed that were the most popular end up being integrations related. So they were doing things like. Integrating with Stripe or integrating with Twilio and we realized through that process that integration is actually a very hard problem and be something that if you did it right, developers are very happy to offload to a third party.

What I had realized while building that product was a lot of what we were doing was helping people integrate with their own tools. So Stripe is your app with your own Stripe instance. Twilio is your app with your own Twilio instance. But what's even harder is if you have to now integrate with your customers, different tools.

So if you're building integration with your customer's notion, each customer's notions will look very different. And you're not, you now have this exponential problem that you have to solve in terms of all the customizations everyone wants to do. And this becomes even more the case in tools like Salesforce and PubSpot.

Spot these heavily configurable, heavily customizable tools where everyone's salesforce set up looks different. They're gonna have custom objects, custom fields. And if you are a SAS engineer trying to build integrations for that works well with all of your customers. You're going to just spend all of your time doing that and still not be able to keep up.

So you really need a dedicated platform like Ambers and that will take care of that complexity for you. So you can work with clean data, normalized data to build the additional magic that your app will do on top of that data.

Justin Garrison: Can you describe one of those, like a common integration that people are doing?

Like when I tie these two, these two things together, Salesforce, like, is it bringing Salesforce people into notion or what are those sort of integrations look like?

Lauren Long: There's a lot of AI companies now, and a lot of them are solving sales and marketing problems. So they're helping people do outbound better.

They're helping people to do cold calls. They're helping people to do lead scoring. And for any of those AI agents to do their work well, they need to access the data that already exists. So if a salesperson has already put lead data into their CRM, the agent needs to know what those leads are. All right.

And then be the agent needs to be able to write data back. So the agent goes off and enriches the data with additional data sources. Maybe it does some pulling together from linked in from the Internet and add some additional context. There's now a need to write back to the CRM. So then the human agent.

Who then looks at that data later can see this nice view of all the context that has been collected. So you need that bi directional integration of both reading and write in order for these agentic workflows to actually work well.

Justin Garrison: And then under the hood, you say you're using Temporal, you're using Kubernetes, you're using GCP.

What, how does that plug together? Like, if I look at your, again, go just go to the homepage example, I see a schedule in there, right? It's like star slash 10, like every 10 minutes and then every 10 days, it's going to trigger something. What does that look like? I mean, that's a cron job, right? But is that like temporal then goes and fires off a Kubernetes pod that has your integrations connected into it and then says, Oh, I suck in this data and stick it over there.

Lauren Long: Yeah. Great question. So what we've tried to do is. We've tried to find the commonalities between all of our integrations and build the framework around those common patterns. So we integrate with over 100 different SAS products. And what we found is there's some patterns there, so there's kind of the more structured data, so the CRMs and the marketing automation and the customer support tools, where you can essentially almost think of it as a giant database, and each table represents a different concept, and there's rows inside of these tables.

And then there's more semi structured data, like Notion or Slack, where it's more content heavy, and within a document, you might have different information, and then it's more structured. And then if you go even further down the, uh, structured side, you have just, you know, data warehouses and databases and things like that.

So once once you, you can squint at a tool and figure out which pattern it fits into, you can also figure out what are the, Interactions that someone wants to do with it. So I mentioned read and write. We also have subscribe, which is more like real time updates of getting notified whenever something changes in the, in the source system.

Out of those, you have things like synchronous behavior, so when you want to do a write and then get a result back right away to know whether or not the write succeeded. You have asynchronous things, you have scheduled things, and with those common patterns, we're able to build abstractions for them within our own system.

And some of those abstractions are built using Temporal. When you do do a scheduled read within our integrations, for example, we do kick off a Temporal schedule. And that schedule has a bunch of input parameters in it that tells it which SAS tool. It's going to read from what are the configuration that it needs to know about that either the sass builder or the end customer has specified and with that input is able to then follow some instructions in order to get the output that we need.

And then we have another part of our system that's more pub sub based that does data transformation that does the relay of the data. To the sass builder. So I guess at a high level, we've tried to find patterns in terms of how these sass products operate as well as patterns in terms of how people want to integrate with them.

And then we've built frameworks around it internally in our platform.

Justin Garrison: Why'd you choose temporal? Like it seems like it's a, it's a workflow engine. It can, it can do a lot of stuff. And there's a bunch of things that do stuff like that, right? I mean, you could, you could do that with Jenkins. You could do it with Kubernetes jobs.

You could do it with all these things. You do bash scripts and cron job, whatever. Like, why'd you go down that route? Especially if you're coming from working at Google, you had a, like PubSub exists there. Like you could fire off something and have it come, you know, read the queue and do it all manually with functions, right?

Like some people would try to build that from scratch.

Lauren Long: And we definitely considered it, but ultimately we landed on temporal because it does a lot more than than just the execution of the workflows. It also has a dashboard that's very easy for us to debug. So if we have a customer support request and someone says this integration isn't running, can you look into it?

We can very easily query our temporal dashboard, figure out exactly what happened. What are the errors that got logged so that Customer support piece was really handy and also has a bunch of other functions that would have taken us time to build like retry logic. We can be pretty specific about what are the conditions for retry?

What are the conditions for not retry? And what's the schedule for retry? And we can also manually trigger retries within the UI pretty easily. All that we could have built but it would have just taken a lot longer to build than using something out of the box.

Justin Garrison: I know a lot of people that have done that with like step functions, right?

Like they're like, Oh, look, some functions has a retry. I'm just going to use that. And it's just like, well, like it's not, it's not the best interface for it. It's a, it's a pretty low level sort of like, if you didn't catch the exact error, you might have some problems there. Temporal is firing off these jobs.

It's getting that configuration. It's doing that data. And you have hundreds of integrations. You say, really? It's like anyone can integrate any of these two SAS platforms together. And a lot of it sounds like a more business friendly Zapier or if this than that, if people remember those tools, right? It's like, Oh, we can tie these APIs together in magical ways and just let you be creative with it.

And some of those are usually prescribed and they're like, Oh, you have to do it. Like if this and that was very structured, you can only do certain fields, Zapier. And what's the there's Microsoft has a not power tools. It's power automation. Um, whatever the tool is called now where it's like, yeah, I can, I can tie this API.

I can have some runner and then I can call another API and like, hopefully somewhere in the middle there, if it fails, what challenges do you have with that? I mean, like, obviously there's a ton of challenges tied together, hundreds of APIs, but like, what do you wish it would do? What do you, what is the thing you're missing or this thing like, Oh, we need to improve in this area.

Lauren Long: That's a great question. I think our biggest challenges haven't been in forever related. I think that for tools that we chose have served as well, um, is really just. The API is we integrate with, sometimes we scratch our heads as to why certain design choices were made. You know, why do they, or certain choices just, you know, came about because no one made them before we started the company, I never thought that there were so many ways of authenticating to an API, it turns out there's a lot, and there's a lot of nonstandard ways of doing it.

Not everyone follows OAuth and people that claim to follow it sometimes will require extra parameters, extra headers you have to pass in that. Now it's some bespoke code you have to write. So I think really just the inconsistency between APIs has been the most surprising. And you can definitely tell that for certain companies their API was an afterthought.

That it was not well designed.

Autumn Nash: How do you deal with the different APIs and kind of trying to keep it all uniformed for your product? And how you take everything in?

Lauren Long: We have an open source connectors library and as a part of that we've also tried to develop what are the set of Configuration that we need to know for each API, and what are things that can live in a configuration file versus in code.

So each of our providers, we call them the APIs we integrate with, will have a configuration file that has certain things that are common. Like what is the base URL for an API? What are the headers you have to pass in when you're making a request? What kind of API key or OAuth tokens does it accept?

Those are things we can have some structure around. And then there's things like pagination logic or errors. Like some API has returned 200 okay, no matter what.

Justin Garrison: Here's your error JSON 200 okay. Exactly.

Lauren Long: Exactly. So then you have to actually write code to be able to read the nested structure inside of the body to.

figure out if it was actually an error or not. So those are things that live in code. So, uh, we've had to kind of make a decision as to what are things that are common, that can be configuration. What are the things that actually just have to be code. And we try it as much as we can to push everything to configuration.

But of course, sometimes, uh, there's a lot of code to be written also.

Autumn Nash: There's always that one part that just has to be different. And you're like, but why?

Justin Garrison: Yeah, yeah, exactly. I think the distinction between like, this is just some data and this is some software, right. And being able to. Not always clearly define it.

Like it's, it's hard. Cause at some points it was like shift, like some, some of the data, like you think it's a URL, but actually like, Oh, that's a different URL in this case. So I need data or I need software to change that at some point. And you have to shift some data into software and some software can be like, Oh, this is just a common pattern.

We can stick it in the config file. How does, how does your API. For that change over time, right? Cause like you don't control Salesforce's API and if they change their configuration, Hey, we have a version two. Now you have to update what things are data and which ones are code. Is that just, okay, user, go figure it out.

We're going to migrate you at some points, or is that like, you're going to try to hide that as much as possible?

Lauren Long: Our approach so far has been we hide that from our builders so they have one consistent interface to work with and we handle whatever needs to get changed in order to move on to the next version in a breaking change scenario.

And so far that has worked out. I think in the future, we may encounter scenarios where we want to actually support two versions of an API, in which case there would be in our YAML file a way for builders to opt into going to the next version ahead of time, for example, but I think we'd like to avoid that as much as possible and just give people one consistent thing to work with.

Justin Garrison: A lot of the problems you're describing here, just remind me of Amazon, like AWS, all of the 200 services, the APIs are not consistent. And then they threw out whatever the version two SDKs and everything like, Oh, you got to opt into this new SDK. By the way, it breaks a bunch of stuff. And, and, and then some services didn't support it the same way.

And some things had different ways to do auth. That's a lot of just like stuff to maintain and figure out for yourself. Like, if you're trying to hide that from a customer, it's like, I'm going to give you a clean interface to all these other services. That's consistent. That's just a lot of like, you have to keep track of versions, not only for only versions for the SAS, but like versions of possibly even like customer per SAS, right?

Because some customers might have newer versions of the APIs depending on how they signed up or when they signed up or what access they have into that platform. Right.

Autumn Nash: Okay. I almost think that's your value prop, though. Exactly! You got it! Because people are always like, Oh, well, I'll just build it myself and it's cheaper.

And not just that, but like, a lot of products are built by people that have great ideas, but they don't know how to implement them. And this is one of those things where you can tell. You were a former engineer at a high level because you've dealt with that problem probably, and you know that it's going to break something else.

So you've made it in a way that completely makes it worth paying that cost because it's going to make it so much easier on your developer. So a lot of times you're like, why are we solving this problem? Because nobody asked you for that. This is something that you know, you can point directly to the value of your product to make a developer's life easier.

Like you've made it where they're not making consistent, like over and over and over again changes to their applications. You're making it where they can focus on what they actually are building and not all these APIs. Like that's a huge value that you know that every time somebody updates these multiple APIs, you're not breaking somebody else's product.

Lauren Long: Totally. Autumn, can we hire you for marketing? I got you, girl. I got you. You know, but you're spot on. And I think that's kind of the trap that some people. If they haven't built with these APIs before, they'll think, how hard could it be? You know, the API is documented. I'll just go ahead.

Justin Garrison: I mean, like integrating two things is, is pretty easy.

Integrating five things is a little more difficult. Integrating a hundred things over a year is extremely difficult, right? Like those things aren't just like linear. This is a little bit harder now. It's like, Oh, that old software that no one knows how this. The code works anymore. It's still using the old API.

Someone has to go in and figure it out and then break it and then make sure it works again. It's not

Autumn Nash: even just putting two things together, though. You can completely denormalize your data if APIs change. You know what I mean? You can break multiple steps of a process. Like it's. You're talking about, I think right now, or during zero interest rates, people kind of were ideophares and they're just like, I have an idea and I'm going to make this startup and you're like, but why?

You know what I mean? And now we're kind of getting to the point where like, we, I think people are being more thoughtful about why they're starting companies. I mean, some people aren't, but whatever. And I think like, it's been like a long time since like, we've seen people really solve a problem that you can point directly to how that adds value to your developers and think about the engineering hours that people spend trying to fix something when an API breaks stuff.

Like you can take down half of an app. You can completely like, not even just the big breaking changes, small erosions of your data normalization can completely cause re architectures and re fracturing of your application. You know what I mean? So the fact that for one, you're going to give them two different options, right?

So they can then check it out, figure out what kind of change they want to do, but roll it back if they need to. Your company is giving such value to people trying to use it because how many apps are just a bunch of APIs under it and taking in data and then giving people a useful way to do it, right? So,

Justin Garrison: but Autumn, we write, we call it AI and then it's, uh, sorry, let's just talk about that.

You are three APIs in a good

Autumn Nash: idea. That's not just throwing AI on something. Y'all, people who are startup founders, hire Lauren as an advisor. She'll give you good ideas and not just putting AI on things. Cause like, but this is exciting. It is a full value. Like you can walk in and tell somebody, these are the ways that I can make your business better for paying me this small fee.

Like I'd give you a big fee for that. You can directly and at like business meetings, say this bottom line versus your developer hours. You know what I mean? That's like, that's an easy sell. In a meeting, you know, when you're trying to get money for something. And I think that's amazing.

Justin Garrison: Lauren, what, what did you learn in this process of building this as a product and selling it and everything else?

Like you probably went in thinking this is going to be easy to do this part of it, or something was going to be hard and maybe it wasn't. What, what have you learned through this process?

Lauren Long: So I, I like to compare and contrast this with my past experiences and I'll compare with Firebase because that, that was where I spent a lot of my career.

And I, and I, what I realized is Firebase was a primarily developer facing product and our buyers were developers or users were developers. And I had thought that for Ampersand, that would be the case also, because that's what we do. We help developers build their applications, build integrations faster and better.

But what we're actually realizing is developers aren't the only people that are affected by this problem. It's actually a lot of other folks like people who are trying to sell that can't close deals because their product is lacking certain integrations that a customer wants or customer support folks that are having Trouble responding to customers that complain about integrations because they have no visibility into why things went wrong is also the founders, the CEOs, people that are thinking strategically about where they can unlock data sources so that their application can be more powerful, more usable and do more things.

So it's actually a problem that affects a bunch of people beyond developers, and that was actually kind of, uh, in hindsight, obvious, but I didn't know that when we started the company. So that's been interesting to see also.

Justin Garrison: What you described there, too, is just like something that a lot of people that have moved from monoliths to microservices, they're like, Oh, well, now I need to integrate all these microservices, all the databases somewhere I need to, my application needs to do a bunch more work to take a bit from that one and a bit from that one.

And a lot of what you're doing is the same sort of like we're moving data around and we're making sure that enough data isn't enough places to make it hopefully useful for whoever's trying to consume that. Cause back in the, we have one database, go to the Oracle database and get all of your data. This 80 table join, uh, you'll be fine.

And now we're like, Oh no, we need to, we need to pull those apart. Even though it's a different part of the business doing that, it's, if it's like you say, it's, if it's not the developer directly, they don't know why that's a problem. They don't know why that's hard to do and enabling them to say, Oh, get that little bit of data over here and then call this one.

And then you can get your full reports, your, your internal application, your API, your page can have everything you need to do your job.

Autumn Nash: But sometimes it is the developer or you're another part of the business and you're taking all those APIs to put it in that one database to serve multiple microservices.

So it's like,

Justin Garrison: don't get me started on microservices. I'll pull in from the same database. That's just, uh,

Autumn Nash: argue microservices and monoliths when you're like talking about the same exact thing and nobody knows what they're talking about.

Justin Garrison: Where do you think besides the. APIs on all these providers are sometimes garbage.

Where does it break? Where does your system like fault? You say that like in temporal, you get a lot of observability, or at least you can visualize and retry things to make sure it's going to run again. But at some point it's like, Oh, that broke. And we don't know why API change, config change, whatever. Is that the main portion that like those runners are still kind of fragile tying these things together?

Or is there somewhere else where you're like, Oh, this needs to get better. We need, we need to improve. In a certain area, if you don't have, if you don't have an answer, that's fine too. Cause like, that's a, that's usually like, I often think of it as like, what was the last outage we had? What was the thing that like, where we got to improve on for next time?

It's like, okay, is that something that was because we didn't design it properly? Was that because it was something out of our control? Was that, you know, how does that affect us?

Autumn Nash: It could also be how your last release went, because that's a lot of info is trying to make it better, make the process better the next time.

Lauren Long: Yeah. If I, if I think about the. The last outage we had, and we, we since solved that problem, was we have autopilot mode set up on our Kubernetes. And essentially what that means is when we have certain metrics that it measures, and when it's past a certain threshold, it'll automatically scale up, and then when the metric comes down, it'll automatically scale down.

And it worked, and that was great. But we, our code didn't really handle the scale down part very well. So when it scaled down, some of our processes were, didn't handle the cancellation properly, and kind of just got shut down prematurely. We've since fixed it, but if I think back to the last thing we had to fix it for Ys, that was it, handling scaling down.

Autumn Nash: I think that's really interesting, though, because nobody ever talks about scaling down. Everyone's always like, but what if you scale up? Like, they're always like, but what if we don't have enough capacity? And nobody talks about. Trying to anticipate what happens when the capacity goes away because you don't need it anymore because it is a complete, it is a whole nother set of problems that people don't always talk about

Justin Garrison: coming from, I mean, like a lot of people talk about, like you said, scale up and like cold start. Right. And no one talks about the like cold shutdown. I was like, what happens when we're just like, it's dead. Like we, we lost that process coming from doing Firebase and cloud functions. Why Kubernetes?

Lauren Long: I obviously considered using Cloud Functions and Cloud Run and all of the more quote unquote serverless products.

And ultimately we decided to go with Kubernetes because A, it was just cheaper for what we needed. Like I think Cloud Functions Whoa,

Justin Garrison: hold up, like Cloud Functions, that, that, that is a cool story right there. Just like, cause I tell people all the time.

Autumn Nash: So much shade right now. Everybody just sit down, be ready.

Functions are cheap

Justin Garrison: to a scale limit, right? And then they're more expensive because it's like you bid is the most expensive thing you can buy for computes

Lauren Long: is the most expensive compute. Exactly. Yeah.

Justin Garrison: As long as you don't use much of it, right? As long as you're scaling to zero. And at some point you're like, Hey, I can just do the math in this threshold, cross the boundary where I have this running all the time, or I have so much of this stuff running that that expensive compute that's handled for me.

That gives you a lot of value. Use it all the time. I tell people all the time, use functions. Use serverless. Absolutely. And then that threshold, you say you're over that threshold where even coming from a serverless world where you're like, I, you know that stuff amazingly well, I'm sure like you were just like, you could build anything you want on top of Firebase and cloud functions.

You're like, ah, we got to go to the Kubernetes routes.

Autumn Nash: That's essentially the premise of cloud services though, right? You use cloud services when you're not sure about your scale and when you're growing and you're still small. Right? Like, because it does the heavy lifting of you not having to worry about it.

Undifferentiated. Yes. Thank you. Like, you're not having to worry about those processes. You figure out where your scale is. You figure out what your margins are of the capacity that you need. And then when you get your startup application, whatever, in very stable, predictable manner, hopefully, you know, or a predictable scale, at least.

Once you're done building that part of your application, then you can spend more time rebuilding your infrastructure yourself and building it to that capacity. That is the premise. It's just because people got hammer happy, just like they are with AI, with the cloud, and they want it to use the cloud for everything.

And that's not what it's for. You know what I mean?

Lauren Long: Yeah, you got it. And we do use cloud functions. Actually, most of our server is run on Kubernetes, but there are certain parts of our infrastructure that are. Spiky. So maybe, you know, once every hour we'll need a lot of capacity and the rest of the hour is zero.

That's a perfect use case.

Autumn Nash: Y'all hire Lauren. Like, can we just talk? She knows how to do startup ideas that actually add value that have like that longevity. And then did you hear her just explain how to use like on prem versus cloud? Because if one more bro on Twitter tries to tell everybody everything can be done on prem is just as bad as everything that can be done on cloud.

Do you see how she knows the difference? Like, Lauren, I love you.

Lauren Long: Thank you. But I think, I think you're absolutely right. It is, it is just about picking the right tool for the job. I mean, there is all, there's all these primitives that you can use and you have to. Think about your traffic patterns. Think about what performance characteristics you need and then pick the right tool for the job.

And I think of it in terms of a spectrum between Cloud Functions, between Cloud Run, which is running Docker containers, fabulous product, Kubernetes, and then we're on autopilot mode, so it's almost like the Sort of serverless way of doing

Justin Garrison: easy. It's the easy managed Kubernetes sort of

Lauren Long: exactly.

Justin Garrison: Did you start that way?

Was this like, I mean, cause like, did you go into it saying like, Hey, we know we're going to have this much usage and we just need to build Kubernetes from the start.

Lauren Long: Yeah, we, we, we did do that from the beginning. And another reason why we decided to do it this way is there are certain things. that in our product that are ongoing processes that we need to run and that's not a good fit for Cloud Function.

Cloud Function is better for ephemeral processes.

Autumn Nash: If Lauren ever sells the startup because she's going to be very successful. So if she ever sells the startup and she's on the market, someone hire her, give her so much money.

Justin Garrison: Autumn's always trying to get people jobs up front. She's just like, I don't care.

Autumn Nash: People are out here listening to like, random tech bros on LinkedIn, taking it as God's word out here, and like, just lighting millions of dollars on fire, and Lauren's like, yes, I built it the right way the first time.

Lauren Long: I also need you to be my personal publicist. Is anything I said

Autumn Nash: alive, just out here using common sense and technical skill to actually build things the correct way.

Not because it's your favorite tool in the box. It's true. I'm gonna call Lauren the next time some dude tries to argue with me on LinkedIn. All

Lauren Long: right. I'm here. I'm here for you.

Justin Garrison: Does, uh, does temporal put all the glue, all those things together? Like, is it just like, Oh, this piece runs in Kubernetes. This piece runs on cloud functions.

This one's cloud run.

Lauren Long: So Temporal is an orchestrator is not compute. So it doesn't actually care where you

Justin Garrison: can trigger all of those jobs. And you just say like, Oh, this one is this cron job that fires off at the top of the hour. We're going to do functions for that because it's, everyone's going to do it right now.

Right?

Lauren Long: You could, it would be a little tougher to use temporal inside of cloud functions. Cause you do have to initialize. The client that will listen to the temporal orchestrator. So if you had a cloud function, you'd have to kind of initialize it every time. It is actually far easier to use temporal with Kubernetes, um, or something else that doesn't shut down.

Justin Garrison: That agent has to check back in and check on those jobs. Makes a lot of sense.

Autumn Nash: Exactly. Yeah. I think that's what, like, what Oren just said is also really true. People think of these products and magical terms, right? But they're all compute and orchestration and like, they're like, you know, it's the same stuff.

Database, networking,

Justin Garrison: compute is tied together in a different way.

Autumn Nash: Exactly. And it's like when you're solving a math problem, right? something in calculus or just, I don't know how you bake a certain type of recipe. Like, right. Like if you're going to do a croissant, you're going to, you need the butter to be flaky.

Like they're all recipes for something, but you're, it's how you glue all these things together. And I think if we looked at it in like a non bias way, like that, how are we going to glue the compute together? How are we going to have it orchestrated? And like. It would make our job so much

Justin Garrison: easier. And no matter what Google search AI tells you, don't put glue in your recipes.

Did it tell you that? It was telling

Justin Garrison: people to put glue in their

recipes. It did tell people to eat glue. Is that what you put in your cookies yesterday, Justin?

Justin Garrison: My cookies were bad for I don't know what.

Autumn Nash: She's funny too. Lauren does type two fun. She is a great engineer and she just threw shade at Justin.

Look. Me and Lauren are best friends now. I'm sorry.

Justin Garrison: It sounds like so many things have gone right during this process. What is something that a customer has done that surprised you or you're like, you are holding it wrong? Like the iPhone, like no you did this wrong and maybe that's our fault because we gave you too much leash maybe that's because you just don't know what you're doing.

But what's something that a customer has surprised you doing with this tool?

Lauren Long: Customers surprise me all the time and they're not wrong. They're not holding it wrong. I just didn't realize that was a way of holding it.

Autumn Nash: You can't see Lauren's face, but her face, like I felt it

Justin Garrison: just, just the, like, I can see her in a customer call says, Oh, that's interesting.

Right. That is just like the most. Oh, okay. Hasn't

Autumn Nash: had that moment. You're just like, Oh, Oh really? Oh, wow. Okay. I guess that's what we're doing. Also, Justin, you're not allowed to send anybody cookies as a thank you gift.

Justin Garrison: Oh no, my, my baking is not, is not good.

Autumn Nash: We need you to ask for help and go to the grocery store.

Justin Garrison: Was there anything that like one of those customers did though that was like, Oh, we should build that in. Like, oh, that's, that's a surprising thing that you did that maybe originally I thought was wrong, but now that's like, oh, that's gonna be our feature, right? Like someone else is gonna want to do that.

Lauren Long: Yeah, recently we had a customer ask for permissions for write and read to be split up. So, so normally we use the same permission model for. Both read and write, and it's based on the user who is using integration, and then they asked for a use case where they want the read to happen through an admin account.

So it has full access, whereas they want the right to happen as the user's permission set. So then the right is controlled at the user level, which It's actually a very good use case. We just haven't encountered that. That's

Autumn Nash: a really good best practices.

Lauren Long: Yeah, yeah, definitely. So, you know, we'll definitely build towards that.

So there's many things like that where we actually do learn a lot from our customers. And even though some, some of them, you know, might seem odd in the beginning, there's a reason why people do it that way. And it's usually a good reason.

Autumn Nash: Did you hear that you guys, she has a feedback loop, hire Lauren, she listens to her customers.

Justin Garrison: It feels like a lot of the integrations, a lot of the pylons are going to be, you have to now understand their org chart. And their process, right? Because a lot of these integrations seem like they're going to fall in that zone of like, you know, the networking stack has the layer eight is political, right?

And like it's somewhere in there. You're like, I need to figure out why these two teams won't talk to each other and to do the thing that would be easier than than firing off a cron job every five minutes.

Autumn Nash: That's because people are worse than technology. Half the like bad problems that happen. You're just like, bro, who decided that orgs were split up this way and that you two can't talk to each other?

Lauren Long: Yeah, there's definitely a lot of things we have to learn, like, for example, you know, the how people's relationship with their customers are we have to learn because We not only have to build a product to cater to our customers who are the engineers of the SaaS companies, we also have to cater to their customers so that we have to understand those relationships.

You know, what are their touch points? Do they do white glove onboarding? Do they do self serve onboarding and build the pieces that make those processes happen? I also personally, just as an engineer who's never done sales before, have had to learn what a CRM is. Why do people use it? What, you know, what is the lead?

What is an opportunity? So yeah, definitely lots of learning on the non technical front.

Justin Garrison: Why'd you name it Ampersand?

Lauren Long: So we like the name Ampersand because it essentially the vision we have for the company is to make technology just more connected. So making it easier for one tool to talk to another so that there is this connectivity layer between different business applications and people can build UX workflows, intelligence on top of that layer.

And we think we can really power that connectivity layer. So the Ampersand symbol. It would just, and it represents that connectivity piece. And it also represents the fact that we're augmenting the engineering capacity of our customers. So it's as if they have additional engineers on board that will help them with their integrations.

Justin Garrison: I, my, my initial thought was this is like, it runs in the background for you, like a background process at the terminal. If I put an ampersand at the end, like that process, that was my initial thought, I'm like, Oh, it's cool. It's just a background process. And it does the thing for me. And then my second thought was, Oh, this is like an improv.

Yes. And sort of like if you've ever done improv, like that's the, the prompt that there is, like, oh yes. And, and so it's like you were just like, yes, and I can connect you to over here and Yes. And I can do that other thing. And, and those are the two places that I, I kind of went. But I mean, it's like you're gluing all these things together and just ending all of them instead of oring them, or,

Autumn Nash: I think it's really smart because it's kind of like you're the glue that glues all the APIs and pieces together.

You know? 'cause your service is going to make it so much easier for people.

Lauren Long: Yeah, yeah, definitely. Yeah, we are the glue. We were joking that we should have super glue as our swag. Like ampersand labeled glue, .

Autumn Nash: I feel like sometimes people name things these like catchy, like little like symbols and you're like, but that actually really works.

And it's like a cute logo, you know? But also like it makes sense and then you, I feel like that just opens you to be able to be like, and then let me tell you why were the glue.

Lauren Long: You know what I mean? So perfect. Exactly. You can, you can use it in your recipes. You can use it too. Not doing the

Autumn Nash: food . Just not Justin's cookies though.

Justin Garrison: What's next for? The product and for the infrastructure evolution.

Lauren Long: So on the product side, we definitely want to expand into more of these systems of record. So far, we've been very focused on the go to market vertical. So building sales and marketing and customer support. Related integrations, there's a lot of other sass builders out there who need different types of integrations.

We want to expand our footprint there. We also want to continue to extend the flexibility of the platform and make it easier for people to add things like transformation functions or custom additional mapping support. We already do a lot in terms of mappings, but I think there's even more that we could do there to really make it a Highly flexible, highly extensible, very robust platform for people.

Justin Garrison: Does that get in the very complex mode of like embedded some TypeScript inside a YAML? Like I have a YAML and then I have this TypeScript block and then I have more like, is that, that, that seems really difficult to do some of those like data transformations in, in a more, I don't wanna say data only, but in YAML, right?

Like in something that is like this, we don't want to have this be fully general purpose code here.

Lauren Long: Yeah, I think right now we have a Yammer file, but in the future, I definitely see folks being able to define certain transformations in code using the language of their choice, and then the artifact of the integrations will be a directory of different files, not just a single file like we have today.

And then once we go there, that's actually another good use case for something like cloud functions. We can have sandbox isolated compute dedicated to a customer. Without it affecting the rest of our stack. So that's a potential future direction. There's also other ways of making maybe pre built transformation functions.

Like certain things are common tasks that SAS companies have to do, like anonymizing sensitive data or Maybe stitching different data together to get

Justin Garrison: rid of all that stuff. Exactly. Yeah.

Lauren Long: Something like that. I can, I can imagine us having these prebuilt already. So you just say, okay, I don't have this integration and then I want this piece of data PII removed, but then I still want to be able to run my LLM on it and still get all the insights.

So that's something else we can help with.

Autumn Nash: That's also really spurred the fact that you're going to. Enable it for customer private, like compute, because a lot of businesses can't share hosts with other people, you know what I mean? So if there's a way for you to make it where it would just be that, especially if for data, data is such a complicated thing because there's different accreditations and there's FIPS and HIPAA and all those different things.

So depending on how the cloud run would do it, it would be interesting to see if you can give them all like further different audits and stuff.

Lauren Long: Yeah, and that's, yeah, actually another future direction that we could go in is having Ampersand be deployable on someone's VPC. So if they don't want the cloud offering making it possible for them to be able to deploy in their own cloud, it's something else that we're built for.

So we've chosen our stack in order to make that future possible. It's another reason why we're using open source technologies.

Autumn Nash: That's actually way better than trying to give them their own dedicated host and then deploy it for them, because if they already have their own VPC.

Justin Garrison: How does that work? Like choosing open source, but also using cloud functions, like cloud functions, I can't run in Amazon, right?

Like that is a very proprietary interface for running functions somewhere. How would you export that? Or I mean, because you have to, like, recreate a new interface that is portable or rewrite it for Amazon, right?

Lauren Long: There are actually frameworks that makes it more portable. So, so the serverless framework, serverless.

com, that makes cloud function more deployable throughout different clouds. So, so there's, when we get there, there's, there's ways we can make it more portable.

Justin Garrison: Well, Lauren, this has been so much fun. I've learned a lot. Where should people find you online if they want to reach out or get in touch?

Lauren Long: Yeah, absolutely.

So people can find me on LinkedIn. Uh, my, my, uh, first and last name, Lauren Long. I'm also on X slash Twitter, although not as active these days, but I, I still, uh, will, will respond to folks, uh, there. So it's Lauren Z Long is the handle. And yeah, find me on the Ampersand company, LinkedIn, or the Ampersand X.

I monitor those also.

Justin Garrison: If you ever want to leave X and come over to blue sky for her to find out now has a guest on the show. So we have a starter pack for it. So anyone that is in blue sky, so we're, we're adding those, anyone that's out there, that's following us, you can check that out. And we have anyone that is, has been a guest is, is in that starter pack.

So it

Autumn Nash: even helps me to follow our guests. Yeah,

Justin Garrison: it only goes up to 150 though. So at some point I need to like, switch it over to a, not a list of season

Autumn Nash: one. And season two, we could

Justin Garrison: have years. Yeah, we have, we could break it out. Cause we're only going to have 50, uh, 50 years, something like that.

Autumn Nash: And then we'll bring back like the retro episodes one day.

Justin Garrison: You can try to get repeat guests too. And see if like, you can get the whole starter pack collection. Thank you so much for, for telling us about Ampersand, tell us how it works and what you do and kind of those challenges around it. That's been a lot of fun. So

it was nice meeting you. so much. This is a lot of fun.

Yeah. Great meeting you guys, Justin and Autumn. Thank you.

Justin Garrison: Alright, and thank you everyone for listening, and we will talk to you again soon.

Thank you for listening to this episode of Fork Around and find out. If you like this show, please consider sharing it with a friend, a coworker, a family member, or even an enemy. However we get the word out about this show helps it to become sustainable for the long term. If you wanna sponsor this show, please go to fa fo fm slash sponsor and reach out to us there about what you're interested in sponsoring and how we can help.

We hope your systems stay available and your pagers stay quiet. We'll see you again next time.