February 7, 2025 • 45 mins
Today we find out how building a product at Big Tech can be very different than a startup. Lauren Long has done both. Building parts of Firebase and eventually taking the things she learned to build Ampersand. We discuss what Ampersand is and go into detail about what the back end looks like. We even drop some hot takes about serverless and Kubernetes. We think you’ll love it!
Show Highlights
(0:00) Intro
(1:00) What is Ampersand?
(3:00) What is the backend?
(4:00) What is Lauren’s background
(6:00) How are people using it?
(10:00) How is Temporal used?
(14:00) How to keep APIs in check
(21:00) What did you learn?
(24:00) What has broken?
(26:00) Why use Kubernetes?
(32:00) What have customers done?
(38:00) What’s next?
About Lauren Long
Lauren Long is the CTO and co-founder of Ampersand, an API integration and workflow engine for enterprises to integrate their data with hundreds of applications. Lauren co-founded Ampersand after working at Google on their serverless products and saw a need for a different kind of integration for customers. She’s a developer with a great intuition on how to build reliable and scalable systems.
Sponsor the FAFO Podcast!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
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.
Welcome to Fork Around and Find Out, the podcast about
(00:21):
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.
(00:43):
How's it going, Lauren?
Great.
How are you guys doing?
We're doing great.
We are excited to talk to
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?
Oh, wait, why are you being mean to us?
I'm trying to throw in a pun at the beginning
of every show and there's a yaml on their homepage.
No, no.
That was a really good joke.
(01:04):
I'm very impressed.
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,
okay.
Tell us about your
company.
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
(01:27):
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
(01:47):
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.
(02:08):
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?
(02:29):
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?
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
it
out from the start.
(02:49):
Dude, Lauren's just, she is a superhero out here.
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.
(03:10):
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.
I don't think we even started with like, we started with
your name and the company, what's your position there?
Yeah.
So I am the co founder and CTO.
(03:32):
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.
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.
(03:56):
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
(04:21):
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.
(04:43):
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.
(05:04):
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
(05:26):
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.
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
(05:46):
notion or what are those sort of integrations look like?
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.
(06:08):
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.
(06:28):
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.
And then under the hood, you say you're using
(06:50):
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
(07:13):
pod that has your integrations connected into it and then
says, Oh, I suck in this data and stick it over there.
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.
(07:34):
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
(07:55):
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
(08:18):
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.
(08:38):
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.
(08:59):
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.
(09:22):
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.
(09:43):
And then we've built frameworks around it internally in our platform.
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?
(10:03):
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.
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.
(10:27):
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
(10:49):
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.
I know a lot of people that have done that with like step functions, right?
(11:10):
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.
(11:32):
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.
(11:54):
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
(12:14):
this thing like, Oh, we need to improve in this area.
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
(12:37):
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.
(12:58):
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.
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?
We have an open source connectors library and as a part of that we've also
(13:21):
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?
(13:43):
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.
Here's your error JSON 200 okay.
(14:04):
Exactly.
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.
(14:25):
But of course, sometimes, uh, there's a lot of code to be written also.
There's always that one part that just has to be different.
And you're like, but why?
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
(14:45):
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
(15:06):
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?
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
(15:30):
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
(15:53):
as possible and just give people one consistent thing to work with.
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.
(16:17):
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?
(16:40):
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.
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.
(17:02):
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.
(17:24):
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
(17:45):
these multiple APIs, you're not breaking somebody else's product.
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.
I mean, like integrating two things is, is pretty easy.
(18:08):
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
even just putting two things together, though.
(18:28):
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
(18:51):
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.
(19:12):
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
(19:34):
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,
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
idea.
That's not just throwing AI on something.
(19:56):
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.
(20:16):
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.
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
(20:39):
part of it, or something was going to be hard and maybe it wasn't.
What, what have you learned through this process?
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.
(21:01):
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
(21:23):
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.
(21:46):
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.
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,
(22:06):
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.
(22:27):
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,
(22:49):
your API, your page can have everything you need to do your job.
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,
don't get me started on microservices.
I'll pull in from the same database.
That's just, uh,
argue microservices and monoliths when you're like talking about
(23:12):
the same exact thing and nobody knows what they're talking about.
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.
(23:34):
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
(23:55):
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?
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.
(24:18):
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.
(24:39):
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.
(24:59):
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
(25:24):
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?
I obviously considered using Cloud Functions and Cloud
Run and all of the more quote unquote serverless products.
(25:46):
And ultimately we decided to go with Kubernetes
because A, it was just cheaper for what we needed.
Like I think Cloud Functions Whoa,
hold up, like Cloud Functions, that, that, that is a cool story right there.
Just like, cause I tell people all the time.
So much shade right now.
Everybody just sit down, be ready.
Functions are cheap
to a scale limit, right?
(26:07):
And then they're more expensive because it's like you
bid is the most expensive thing you can buy for computes
is the most expensive compute.
Exactly.
Yeah.
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.
(26:28):
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.
That's essentially the premise of cloud services though, right?
(26:51):
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,
(27:16):
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.
(27:37):
And that's not what it's for.
You know what I mean?
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.
Y'all hire Lauren.
(27:58):
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.
(28:18):
Do you see how she knows the difference?
Like, Lauren, I love you.
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
(28:42):
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
easy.
It's the easy managed Kubernetes sort of
exactly.
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
(29:03):
usage and we just need to build Kubernetes from the start.
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.
(29:24):
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.
Autumn's always trying to get people jobs up front.
She's just like, I don't care.
People are out here listening to like, random tech bros on LinkedIn, taking
(29:45):
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.
I also need you to be my personal publicist.
Is anything I said
alive, just out here using common sense and technical
skill to actually build things the correct way.
(30:06):
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
right.
I'm here.
I'm here for you.
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.
(30:27):
So Temporal is an orchestrator is not compute.
So it doesn't actually care where you
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?
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.
(30:49):
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.
That agent has to check back in and check on those jobs.
Makes a lot of sense.
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?
(31:10):
But they're all compute and orchestration and
like, they're like, you know, it's the same stuff.
Database, networking,
compute is tied together in a different way.
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.
(31:30):
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
easier.
And no matter what Google search AI tells you, don't put glue in your recipes.
Did it tell you that?
(31:51):
It was telling
people to put glue in their
recipes.
It did tell people to eat glue.
Is that what you put in your cookies yesterday, Justin?
My cookies were bad for I don't know what.
She's funny too.
Lauren does type two fun.
She is a great engineer and she just threw shade at Justin.
Look.
(32:11):
Me and Lauren are best friends now.
I'm sorry.
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?
(32:32):
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.
You can't see Lauren's face, but her face, like I felt it
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
had that moment.
You're just like, Oh, Oh really?
(32:54):
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.
Oh no, my, my baking is not, is not good.
We need you to ask for help and go to the grocery store.
Was there anything that like one of those customers
did though that was like, Oh, we should build that in.
(33:16):
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.
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
(33:37):
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
a really good best practices.
(33:59):
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.
Did you hear that you guys, she has a feedback
loop, hire Lauren, she listens to her customers.
(34:20):
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
(34:41):
easier than than firing off a cron job every five minutes.
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?
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
(35:03):
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
(35:26):
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.
Why'd you name it Ampersand?
So we like the name Ampersand because it essentially the vision
we have for the company is to make technology just more connected.
(35:47):
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
(36:09):
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.
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.
(36:29):
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,
(36:51):
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.
Yeah, yeah, definitely.
Yeah, we are the glue.
We were joking that we should have super glue as our swag.
Like ampersand labeled glue,
. I feel like sometimes people name things these like catchy, like
(37:13):
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.
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
food . Just not Justin's cookies though.
(37:33):
What's next for?
The product and for the infrastructure evolution.
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
(37:55):
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
(38:16):
flexible, highly extensible, very robust platform for people.
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?
(38:39):
Like in something that is like this, we don't want
to have this be fully general purpose code here.
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.
(39:01):
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
(39:23):
anonymizing sensitive data or Maybe stitching different data together to get
rid of all that stuff.
Exactly.
Yeah.
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.
(39:47):
So that's something else we can help with.
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
(40:07):
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.
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
(40:31):
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.
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.
How does that work?
Like choosing open source, but also using cloud functions,
(40:52):
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?
There are actually frameworks that makes it more portable.
So, so the serverless framework, serverless.
(41:13):
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.
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?
Yeah, absolutely.
So people can find me on LinkedIn.
Uh, my, my, uh, first and last name, Lauren Long.
(41:35):
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.
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.
(41:58):
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
even helps me to follow our guests.
Yeah,
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
(42:18):
one.
And season two, we could
have years.
Yeah, we have, we could break it out.
Cause we're only going to have 50, uh, 50 years, something like that.
And then we'll bring back like the retro episodes one day.
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.
(42:39):
so much.
This is a lot of fun.
Yeah.
Great meeting you guys, Justin and Autumn.
Thank you.
Alright, and thank you everyone for
listening, and we will talk to you again soon.
(43:02):
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.
(43:26):
We hope your systems stay available and your pagers stay quiet.
We'll see you again next time.
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.
Welcome to Fork Around and Find Out, the podcast about
(00:21):
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.
(00:43):
How's it going, Lauren?
Great.
How are you guys doing?
We're doing great.
We are excited to talk to
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?
Oh, wait, why are you being mean to us?
I'm trying to throw in a pun at the beginning
of every show and there's a yaml on their homepage.
No, no.
That was a really good joke.
(01:04):
I'm very impressed.
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,
okay.
Tell us about your
company.
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
(01:27):
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
(01:47):
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.
(02:08):
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?
(02:29):
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?
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
it
out from the start.
(02:49):
Dude, Lauren's just, she is a superhero out here.
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.
(03:10):
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.
I don't think we even started with like, we started with
your name and the company, what's your position there?
Yeah.
So I am the co founder and CTO.
(03:32):
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.
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.
(03:56):
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
(04:21):
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.
(04:43):
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.
(05:04):
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
(05:26):
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.
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
(05:46):
notion or what are those sort of integrations look like?
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.
(06:08):
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.
(06:28):
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.
And then under the hood, you say you're using
(06:50):
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
(07:13):
pod that has your integrations connected into it and then
says, Oh, I suck in this data and stick it over there.
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.
(07:34):
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
(07:55):
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
(08:18):
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.
(08:38):
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.
(08:59):
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.
(09:22):
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.
(09:43):
And then we've built frameworks around it internally in our platform.
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?
(10:03):
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.
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.
(10:27):
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
(10:49):
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.
I know a lot of people that have done that with like step functions, right?
(11:10):
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.
(11:32):
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.
(11:54):
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
(12:14):
this thing like, Oh, we need to improve in this area.
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
(12:37):
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.
(12:58):
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.
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?
We have an open source connectors library and as a part of that we've also
(13:21):
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?
(13:43):
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.
Here's your error JSON 200 okay.
(14:04):
Exactly.
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.
(14:25):
But of course, sometimes, uh, there's a lot of code to be written also.
There's always that one part that just has to be different.
And you're like, but why?
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
(14:45):
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
(15:06):
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?
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
(15:30):
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
(15:53):
as possible and just give people one consistent thing to work with.
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.
(16:17):
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?
(16:40):
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.
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.
(17:02):
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.
(17:24):
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
(17:45):
these multiple APIs, you're not breaking somebody else's product.
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.
I mean, like integrating two things is, is pretty easy.
(18:08):
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
even just putting two things together, though.
(18:28):
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
(18:51):
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.
(19:12):
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
(19:34):
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,
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
idea.
That's not just throwing AI on something.
(19:56):
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.
(20:16):
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.
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
(20:39):
part of it, or something was going to be hard and maybe it wasn't.
What, what have you learned through this process?
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.
(21:01):
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
(21:23):
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.
(21:46):
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.
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,
(22:06):
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.
(22:27):
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,
(22:49):
your API, your page can have everything you need to do your job.
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,
don't get me started on microservices.
I'll pull in from the same database.
That's just, uh,
argue microservices and monoliths when you're like talking about
(23:12):
the same exact thing and nobody knows what they're talking about.
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.
(23:34):
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
(23:55):
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?
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.
(24:18):
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.
(24:39):
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.
(24:59):
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
(25:24):
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?
I obviously considered using Cloud Functions and Cloud
Run and all of the more quote unquote serverless products.
(25:46):
And ultimately we decided to go with Kubernetes
because A, it was just cheaper for what we needed.
Like I think Cloud Functions Whoa,
hold up, like Cloud Functions, that, that, that is a cool story right there.
Just like, cause I tell people all the time.
So much shade right now.
Everybody just sit down, be ready.
Functions are cheap
to a scale limit, right?
(26:07):
And then they're more expensive because it's like you
bid is the most expensive thing you can buy for computes
is the most expensive compute.
Exactly.
Yeah.
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.
(26:28):
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.
That's essentially the premise of cloud services though, right?
(26:51):
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,
(27:16):
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.
(27:37):
And that's not what it's for.
You know what I mean?
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.
Y'all hire Lauren.
(27:58):
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.
(28:18):
Do you see how she knows the difference?
Like, Lauren, I love you.
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
(28:42):
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
easy.
It's the easy managed Kubernetes sort of
exactly.
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
(29:03):
usage and we just need to build Kubernetes from the start.
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.
(29:24):
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.
Autumn's always trying to get people jobs up front.
She's just like, I don't care.
People are out here listening to like, random tech bros on LinkedIn, taking
(29:45):
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.
I also need you to be my personal publicist.
Is anything I said
alive, just out here using common sense and technical
skill to actually build things the correct way.
(30:06):
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
right.
I'm here.
I'm here for you.
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.
(30:27):
So Temporal is an orchestrator is not compute.
So it doesn't actually care where you
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?
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.
(30:49):
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.
That agent has to check back in and check on those jobs.
Makes a lot of sense.
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?
(31:10):
But they're all compute and orchestration and
like, they're like, you know, it's the same stuff.
Database, networking,
compute is tied together in a different way.
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.
(31:30):
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
easier.
And no matter what Google search AI tells you, don't put glue in your recipes.
Did it tell you that?
(31:51):
It was telling
people to put glue in their
recipes.
It did tell people to eat glue.
Is that what you put in your cookies yesterday, Justin?
My cookies were bad for I don't know what.
She's funny too.
Lauren does type two fun.
She is a great engineer and she just threw shade at Justin.
Look.
(32:11):
Me and Lauren are best friends now.
I'm sorry.
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?
(32:32):
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.
You can't see Lauren's face, but her face, like I felt it
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
had that moment.
You're just like, Oh, Oh really?
(32:54):
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.
Oh no, my, my baking is not, is not good.
We need you to ask for help and go to the grocery store.
Was there anything that like one of those customers
did though that was like, Oh, we should build that in.
(33:16):
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.
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
(33:37):
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
a really good best practices.
(33:59):
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.
Did you hear that you guys, she has a feedback
loop, hire Lauren, she listens to her customers.
(34:20):
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
(34:41):
easier than than firing off a cron job every five minutes.
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?
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
(35:03):
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
(35:26):
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.
Why'd you name it Ampersand?
So we like the name Ampersand because it essentially the vision
we have for the company is to make technology just more connected.
(35:47):
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
(36:09):
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.
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.
(36:29):
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,
(36:51):
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.
Yeah, yeah, definitely.
Yeah, we are the glue.
We were joking that we should have super glue as our swag.
Like ampersand labeled glue,
. I feel like sometimes people name things these like catchy, like
(37:13):
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.
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
food . Just not Justin's cookies though.
(37:33):
What's next for?
The product and for the infrastructure evolution.
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
(37:55):
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
(38:16):
flexible, highly extensible, very robust platform for people.
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?
(38:39):
Like in something that is like this, we don't want
to have this be fully general purpose code here.
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.
(39:01):
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
(39:23):
anonymizing sensitive data or Maybe stitching different data together to get
rid of all that stuff.
Exactly.
Yeah.
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.
(39:47):
So that's something else we can help with.
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
(40:07):
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.
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
(40:31):
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.
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.
How does that work?
Like choosing open source, but also using cloud functions,
(40:52):
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?
There are actually frameworks that makes it more portable.
So, so the serverless framework, serverless.
(41:13):
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.
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?
Yeah, absolutely.
So people can find me on LinkedIn.
Uh, my, my, uh, first and last name, Lauren Long.
(41:35):
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.
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.
(41:58):
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
even helps me to follow our guests.
Yeah,
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
(42:18):
one.
And season two, we could
have years.
Yeah, we have, we could break it out.
Cause we're only going to have 50, uh, 50 years, something like that.
And then we'll bring back like the retro episodes one day.
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.
(42:39):
so much.
This is a lot of fun.
Yeah.
Great meeting you guys, Justin and Autumn.
Thank you.
Alright, and thank you everyone for
listening, and we will talk to you again soon.
(43:02):
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.
(43:26):
We hope your systems stay available and your pagers stay quiet.
We'll see you again next time.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!