[MUSIC PLAYING]
Hi, I'm Aaron Liao and I run Developer Evangelism
here at DocuSign.
Today, I'm in our sunny headquarters in Seattle.
And I'm with Eric Fleischman, who's
our Chief Architect on the DocuSign platform.
Thanks for joining us, Eric.
Thanks for having me.
So we're here today to talk about what it really
takes to build what we're calling
a carrier-grade platform.
And I love the way carrier-grade platform sounds.
It's so much sexier than some of the other terms
that other companies use these days.
Eric, can you tell us a little bit more
about what it took to build that and what that means?
Sure.
So our goal when we started this project four years ago
was to build a platform that customers could bet on.
That they could really trust with their most critical
transactions with their most critical business.
And so to us carrier-grade was about dial
tone-like reliability.
Hence the term carrier-grade.
Four to five nines of reliability.
Always on, always available, consistent performance.
Being able to deliver a trustworthy
experience to customers 24 hours a day, seven days a week.
So we've talked about three design principles in the past,
and I think these are all super important.
So let's go through each one.
We've talked about security, trust, and transparency.
Why don't we start with security.
And can you share a little bit about how DocuSign
takes security seriously, what we do
for it, what that means to us?
Sure.
So for a lot of our customers, we house their most sensitive
transactions-- whether it's a real estate agreement
or a compensation agreement--
a wide array of transactions that
constitute the most sensitive things in people's lives.
So to us, making sure that the right people
are interacting with the right transaction in the right way
is--
that is our number one priority by a country mile, that's
the most important thing we do.
So we invest significantly in protecting our platform
from a variety of different external threats.
We do identity related services to make sure
that the person on the other side of the transaction
is who they say they are.
We produce artifacts at the end of transaction
so that people can attest to the legitimacy of the transaction
for long periods of time.
All of these different areas that we invest in
to build the most secure, quite frankly, platform that we can.
And I guess that's where we come up with the term bankrate
architecture, right?
Yeah, so people have this mental model of the bank being
the trusted place with their money, and we want them--
we want to be the trusted place with their transactions.
Brilliant.
So that brings us the trust which
is, of course, as you mentioned, a core principle for us
at DocuSign.
Can tell us about how trust when you're designing and building
DocuSign platform, like data integrity,
continuous availability, maybe things like that?
Sure.
I mean so the funny thing about building a trustworthy platform
for customers is that trust means different things
to different people.
For some people, the trust of their transaction
is knowing the person is who they say they are
and making sure that the agreement never
leaks out, that it never gets into the wrong hands.
For other people, the agreements could be, perhaps,
functionally public-- maybe it's a non-disclosure agreement
in a lobby--
where there isn't so much in the way of sensitivity
of the data in the agreement, but they
care a ton that that agreement is processing 24 hours a day,
seven days a week.
Because there's some sort of real world
process on the other side of it that
halts when the transaction processing
engine doesn't run anymore.
And so we want to appeal to all of the different senses
of trust.
We want people to build a trust us with their agreements,
no matter what their different goals are.
Even within a business, where they
have different types of transactions that they process,
and we want them to trust us with, quite frankly,
with all of them.
So transparency is a popular topic these days.
And I remember in product boot camp you talked a little bit--
well, you talked quite a bit, rather about our monitoring
systems.
Can tell us a bit about those and how they lend
themselves to transparency?
Yeah, to be honest, our belief is
that you can't be trusted unless you're transparent.
The very beginning, even before you've achieved
something worthy of somebody is trust,
that you simply have to be honest about what
you have achieved.
And so we built extensive systems
to monitor the security and reliability of our platforms.
So in the example you gave, the monitoring systems,
we have big scale telemetry systems that, quite frankly,
process tens of billions of events
per day, about 65 billion events per day
as we're having this discussion.
1.2 million pieces of telemetry per second that
are telling us if the system is healthy or not.
And if not, giving us insight into the state
of that transaction on a customer by customer,
as well as system by system basis,
and then feeding into automatic remediation systems
that can repair problems, frankly, before customers ever
notice them.
So you're hitting on something really interesting there, which
is our take on continuous improvement.
Obviously, our real time monitoring
lends itself to that.
Can you speak a little bit more about that?
Yeah, so we're constantly evolving this machine,
whether it's configuration changes, software changes,
shipping major versions of the code, small fixes.
We're in a continuous evolution mode with the platform.
And we use the data as the first and foremost place
that we learn.
There's no better place to learn if customers
are having a great experience with DocuSign
than to simply look at the data and see what is the end user's
experience with our platform.
So we use that as the first input, quite frankly,
when thinking about what do we have to do to make it faster,
or what do we make better about that reliability event,
or whatever it might be.
I remember when I was doing one of my first trainings,
and you presented to us.
You talked about how the assumption was--
or you built everything around the notion
that everything would probably fail at some point.
That's right.
Can we talk about that idea and what
our approach was to get around that or to solve for that?
Yeah, it turns out everything fails eventually.
Given enough time and enough entropy in the system.
Given enough scale, right?
Everything fails.
And that's true from hard drives all the way up
through data centers.
And so we've taken an engineering approach where
we simply, rather than trying to engineer around the failures
and make them as rare as possible,
we've taken an engineering approach
which is to say let's just start with the assumption that
is going to happen a lot.
How would we build a reliable platform
in the face of this thing happening a hundred times
a day, a thousand times a day.
Whatever that very large value of n is.
How do we build a system that would still
deliver a great experience for customers, even
if this event were happening in the middle
of their transaction?
Naturally, I love our customer first approach
and I love everything that we've done to safeguard and be
transparent with our customers.
Any last thoughts you want to leave us
with in terms of platform and--
I mean, you know we do a lot of things in platform.
We build a lot of features for a lot of people,
whether it's expanding globally or standards based signatures
or all of these things, but this is actually the most important,
and to me, at least the most interesting part of what we do.
Making a platform that's continuously available
that customers trust is, to me, at least
the reason I came here.
Thanks so much, Eric.
I appreciate it.
Thanks.
[MUSIC PLAYING]