Ep. #49, Redefining Access Control with Omri Gazitt of Aserto

Grant Miller: All right, Omri. Thank you so much for joining.

Omri Gazitt: Thank you for having me.

Grant: Well, let's dive right in. Tell us a bit about how you got into enterprise software and how you've been building things.

Omri: Yeah, the enterprise. Let's see, this goes back a little over 30 years so I may be a bit older than some of your typical guests.

But right out of college I was going to go back to Israel, that's where I'm from, that's where I grew up, and I think I was about 20 years old and I was going to do a summer working for basically whoever paid me the most money.

I did my college in Houston, that was Texaco. Texaco had an information technology department so I got, I think it was like $13 an hour which was the most that they would offer anybody for a summer job.

Which was great, because I wanted to save a little bit of money before going back. So as basically an intern I was trying to figure out what I was going to do and they sold me on all this development that I was going to do.

Anyway, I joined this place and they have all these mainframes and I'm like, "Okay, what do you want me to do?" They have these logs that they want me to transfer, "Okay, I'll go right in and see."

They're like, "See, yeah. We don't have that on the mainframe." "What do you have?" "We have COBALT, we have MPO1. Well, if you're a really crack programmer, you know BAL, Basic Assembler."

And I'm like, "Let's see." So I went off on this scavenger hunt and I found a C compiler on their system 370 or whatever, and I started building this thing and I just recall it was just such a shock because they didn't think I would get it done, they thought it would take the whole summer, it took me three days.

I was like, "Now what?" They were like, "Okay. Now you have to rewrite it in MPO1." "It works!" And they were like, "Yeah, but we don't know how to maintain it. No one here knows C."

Grant: Nor will they ever learn it.

Omri: Exactly, that's right. It was a funny introduction because on the one hand I was like, "This is completely night and day."

What I learned in college has very little bearing in terms of what the, 'state of the art,' is for enterprises at the time.

It was an interesting lesson, that follows throughout my career, sometimes it's easy to forget that when we live on the bleeding edge of technology, larger companies take a much longer time horizon to adopt those technologies.

So I was wrong point in time, but I was right directional because 5 or 10 years later of course, all the stuff that we were doing, UNIX systems at the time and the PC Revolution and all that stuff was going to go disrupt how those folks did business.

So inside of the cocoon they had no idea that all this stuff was about to come, so I could see it, but at the same time I realized that I had to be a lot more patient in terms of how I thought about the time horizons for enterprises.

Grant: Nothing happens in three days. It's too short. So after that, what else? I know you were at Microsoft for a long time, and some other real deep enterprise companies. Tell us about those experiences.

Omri: So I guess before, as it turns out, at Texaco I met this guy who was a founder and we didn't have the term startup at the time or things like that, or founding engineer.

But he basically said, "Hey, instead of going back to Israel, why don't you join me and we'll do a startup together?"

And so I said, "Hmm, that sounds kind of interesting, let's go do that."And as it turns out, I met him in the Texaco Building, his quid pro quo was they gave him office space and mainframe time, and all sorts of stuff like that.

In exchange he basically agreed to supply them a perpetual free license of whatever was going to come out of Neon Systems, and it was pretty interesting because I was mostly interested in the engineering at the time.

But I learned from him how it is that you go talk to enterprises and understand what their pain points are and what their requirements are, and we knew that we wanted to create something that was basically the bridge between this new world of client-server.

Microsoft was building all these new applications like Access and Visual Basic, and there was an entire industry that had these data hungry applications, but enterprises wanted to connect them to their enterprise data sources. So mainframes, DB2s, IMS, and UNIX systems like Oracle and Cybase and so on and so forth.

So that was a pretty interesting formative experience because I was employee number one, and we went six years with that and we eventually took it public back in 1999, so that I call my Rose Colored Tour Through Startupdom.

But one of the things I learned through that was that we were at the right place at the right time, we were right at the bleeding edge of this disruptive wave that was hitting enterprises and all of them needed what we were building.

The disruptive wave was brought about by Microsoft's new platform, this client-server platform, and so back in 1998-1999 Microsoft called me up, I think it was '98, yeah, and they said, "Hey, we're building this new platform."

What eventually became .NET, "If you want to come join us?" I could not say no to that because it was so fascinating to see this platform wave that floated a lot of boats, including ours back in the early and mid 90s, and Microsoft was about to do the same thing. So I was one of the first 10 people that got to work on .NET.

Grant: Oh, interesting. Okay. So talk about .NET, what made it so interesting and new? For the uninitiated, what's special about it or what was unique at the time?

Omri: Sure. At the time, Microsoft was the one, two and three software vendor, but it was pretty clearly that the cracks were showing. Sun had started out Java around 1996 and the browser was becoming the platform, and Microsoft was trying to figure out how to fit into this new world.

So it was very clear that software architecture was changing, you basically need to invest a lot more in how to build web applications. Microsoft was pretty good at designing systems that enterprise developers could use, like Visual Basic or Access where you would basically have an interesting...

Today we call it low code environments, an interesting environment that was restricted in some ways, it wasn't you could do anything and everything.

You didn't need to understand what the Windows message was, but at the same time you could actually build interesting and powerful applications if you had this opinionated framework.

At the time we also were trying to grow up market, so we were considered the client side company, operating system, what have you, and NT was trying to get its bonafides in the enterprise.

I recall first joining, at Microsoft it was very easy as somebody who was in engineering and product to not talk to customers at all, but one of the things I used to do is every summer I'd go fly out to Wall Street and meet with a bunch of banks over there.

It was just really humbling because they were like, "Oh, Microsoft. Yeah, you guys make mice, right? You guys don't make enterprise software."

We're like, "Uh, we made this thing called SQL, sir." They were like "Pfft, toy." You were trying to figure out what they were looking for, and it just ended up being there's a combination of reputation and feature set, and basically meeting them where they were.

So a lot of them were like, "Look, we would take you more seriously if you built tools for Java, or we would take you more seriously if you ran your database on Solaris or the operating systems that we have."

And it was a really interesting set of decisions we had to make because on the one hand we knew that nobody loved us on Java and nobody loved us on UNIX, and on the other hand we had to figure out how to meet our customers where they were.

So really .NET was about creating something that could be an alternative to Java, but we knew that we could never grow it on the middle tier as a middle tier application server type of framework, and we couldn't really win the database unless we took steps to interoperate with the world of IBM and BEA and Sun and Oracle and all those things.

So we basically had to change the game, and one of the things that we realized could happen was there was this new... The Web Protocols were going to become a lot more important than all these binary point to point protocols, that the UNIX world and the Java world had, so we basically started out by creating this web services consortium and we had our competitors there.

IBM and BEA and Oracle and Sun, we all tried to build software that interoperated, and for us it was a way to level the playing field.

When enterprise came in and said, "Hey, are you Java compliant?" We're like, "No, no, no. That's not the right question to ask. The right question to ask is do we support SOAP or WSDL or UDDI." Or some of these early attempts at web interoperability.

Grant: Interesting. So this is a very different world than we live in today, where I think most people think about Microsoft and the success that they've had in the enterprise, almost as if they are...

Clearly there's a consumer side to Microsoft and a small business side to Microsoft, but the enterprise side seems incredibly successful. So this is a time period when Microsoft didn't have that credibility.

Omri: That's exactly right, and we knew at some level that this was a game of patience.

So we had a few people that had come from the enterprise, we had the person who ended up running the SQL Server division.

They came from basically a healthcare company, and he could tell us as a customer what we needed and what we needed to do in order to be enterprise credible.

For a company that was so engineering centric, it was really hard to hear but ultimately the desire to win overcomes your biases and your almost chauvinism.

And so we ended up eating some humble pie and realizing what we needed to do in order to get more credibility in the enterprise, so some of the things, some of it is like features. SQL Server didn't have... I think it was rollover locking, and then when we delivered that in SQL Server 7, all of a sudden SAP said, "Okay, now we can actually go build our software to finally run against your database."

And so figuring out what the unlocks were, whether they were features or whether they were support contracts. For example, people wanted support for 10 years and our speed of innovation was much faster than that, but we had to learn how to extend our support cycles and offer extended support for a lot of money in order to actually match the enterprise requirements.

Grant: Yeah. You mentioned something which is SAP being like, "Okay, now we can have our ERP talk to your database as the backend."

Which is, I think, a pretty foreign concept to many people today, right? You don't have applications that are like, "Oh, we can run on Oracle or run on..." I guess SAP eventually built HANA for some of their tools to run on, "Or run on SQL Server or Microsoft SQL."

Do you have context as to why that was the case? Was it because you had a special DBA? Was it because there was a shared system? Why were people running applications that way?

Omri: Fantastic question, because it's actually one of the patterns that I think led me and Gert to start Aserto, and we'll get there eventually.

But back in the early 90s these business applications would basically bring their own database, you would basically embed something like Oracle or DB2, or maybe SQL Server, and you'd bring it along with you and you would pay a royalty to the database vendor.

Towards the late 90s and definitely early 2000s, the whole buying motion changed so there was... Enterprises basically said, "We have a site license, and ELA for DB2 Enterprise Edition or for Oracle Enterprise Edition."

And typically the larger the enterprise, they'd have two or three of these and they'd have these heads of architecture that would decide what it is that they supported and what it is they didn't support.

To your point, it was exactly that expertise, the expertise of DBA's system administrators, they wanted to make sure that they had a smaller, a constrained number of enterprise ready infrastructure that they could support. So basically the burden became shifted to the application provider to run on top of that infrastructure, so if you supported Windows NT and supported these UNIXs or this Linux, the application provider actually had to go meet those requirements.

Now, on the one hand it made it a little bit easier because you didn't have to pay a royalty in order to bring something embedded, but on the other hand it required basically interoperability standards to get built, and I use that term in a very loose way.

For example, POSIX was a great interoperability mechanism because back at Neon when we were asked to go port our software to a bunch of different UNIXs, Dec UNIX and Siemens Niechedorf in Germany had these UNIX systems.

They all supported more or less the same system call APIs, and some of them even had application binary interfaces.

In the database world it was ODBC, ODBC was the thing that basically flattened that whole space.

Before ODBC every one of these databases had their own call level interface so we had this NxN problem, right? You had N applications trying to talk to N different databases, and it was like the Cartesian product of all of those in order to get the interoperability going.

What ODBC did and, later on, JDBC and some of these other things was to make that an N+N problem, so if the applications could write to a single API and all of the database vendors had drivers for that API, all of a sudden you're making this problem a lot more tractable.

So one of the patterns that we see here is for that platform shift to happen, there has to be some interoperability mechanism that enables that.

Grant: Okay. And did someone write the spec for ODBC? Did someone write the spec for that and how did that standard become available?

Omri: Yeah. So Microsoft basically wrote a book on it, wrote the spec, the API, and then they were really good at running these DevCons early on and so their strength was the ISV ecosystem that they brought from Windows.

They had to evangelize it, they had to have a critical mass of database vendors that were willing to play ball, and companies like Neon.

We basically built our entire business connecting all these data hungry applications with these enterprise data sources by building to this ODBC spec, and building all these enterprise features around it.

So that was basically how Microsoft bootstrapped that, and once you get to a critical mass or a tipping point, then that becomes the standard, and Sun basically copied that. They said, "Okay, we need one of these for Java and we're going to make it pure Java."

So they were able to parlay some of that initial work and even use some of the same letters, the same acronym and essentially bring that same capability to the Java ecosystem.

Grant: And that was the JDBC?

Omri: Essentially.

Grant: Got it, okay. And so did it mirror some of the patterns and was it like a similar, inspired spec?

Omri: It was. I think more in name than anything else, they tried to bring the Java sensibilities, the patterns, the opinionated way of designing APIs to the Java world.

But the pattern at a 50,000 foot level, the pattern was so recognizable that it was relatively straightforward for all these companies that built ODBC drivers to then build JDBC drivers. That was like, "Your move, son."

They actually were able to parlay the work that Microsoft did into their own ecosystem and Microsoft had to respond by saying, "Okay, we're going to change the game yet again and make it not about Java, but we're going to make it about open standards on the web."

The early versions of those like SOAP and WSDL and UDDI and then Wstar, some of them failed miserably and I have the distinction of being the manager of all of those things at Microsoft.

But eventually we got to Rest and we got to things like Open ID Connect and we got to things like JWT and SAML and O-Off 2, things that to this day are how the web does security and identity, for example.

Grant: Yeah, but along the way you had to do some XML, right?

Omri: Oh yes, lots and lots of XML. Oh yeah. It's funny because I think it was one of the SBPs of Microsoft looks at me and a few of the other people, I ran the XML team at Microsoft, and he looks at me and he goes, "We're all going to hell for what you've done to this industry."

Grant: The crazy part is you introduce a new interesting pattern, a way to orchestrate, organize data that's machine readable, it's not perfect the first time.

The reality is a lot of these things aren't perfect the first time, but it's good enough that it worked and it still is powering many of these things, right?

And so I think what's interesting is the idea like, "Hey, eventually we revisit and we redo it in a way that's a little more efficient and a little different, and we take some of the lessons that we learned." But we wouldn't have learned those lessons had it not existed in the first place.

Omri: Exactly. It's a great lessons around iteration, and at Microsoft if anything I would say our iteration speed or learning speed was way too long.

We were bitten by the bug of trying to make it perfect, and as we all know, perfect is the enemy of good enough sometimes.

So that's one thing that I would say in retrospect we spent so much time trying to get these things right that we got them wrong, because we forgot to go work with folks like Google and Ebay and Amazon and Yahoo who were all building, who were all consumers of the technology, whether they were building on top of Linux or their own custom systems for Java or .NET. In the meantime they were like, "All this stuff is way too complicated. We're just going to try to go do some of our own things."

And they start talking to each other, and all of a sudden we realized the power in this industry is no longer with the platform vendors. The power in this industry has shifted to these companies that are building mass scale internet services. That was an enormous lesson. That's actually one of the things that ended up leading to Azure.

Grant: Interesting. Well, talk about that.

Omri: Yeah. So I think it was in 2005 or 2006, we realized that there were early signs.

One of the things I used to talk about was, "Okay, so we built this platform, now what? Let's start building some patterns on top."

And so I proposed this service to Bob Muglier who was the President of the Server and Tools business at the time, which became the Azure team, and I said, "How about we create these storage bricks and basically have these Rest or SOAP API for being able to push and pull data in and out of our big hard drives."

Because MSN and Bing and Live and all these services, they have these enormous data centers.

And he's like, "That's the stupidest effing thing I've ever heard. Do you know how much it costs to actually move a gigabyte of data over the internet? It's faster to actually put it on a DVD and send it FedEx, it's faster and cheaper." I'm like, "Yeah, but project a few years out."

And of course by the next year, Amazon had S3 out and it was pretty clear that it was doing EC2.

So I would say we woke up around 2006, 2007 to this, and so we started building a team, putting a team together, and some of the things were obvious like you had to build a Hypervisor, you had to build a storage system, you had to build the moral equivalent of EC2.

But I was really interested in how it was that you bridge between the world of the enterprise and the world of what we now call the cloud, because it felt like we had one foot in each camp.

We had all these high scale, mass scale services on the MSN, Live side, and then we had increasing knowhow in the enterprise.

So what we set out to do was build stuff that could bring together the world of on premises and the world of the cloud, and the first service was what we called the Azure Access Control Service. Famous last words, this is part of the inspiration that led to Aserto, but we had services like, for example, the Service Bus where connectivity between on premise and off premise was really hard.

So you had to figure out ways to relay the traffic, and that was actually very valuable. How do you actually have some code running in the cloud that could go talk to an enterprise system behind the firewall, so to speak, and be able to get data out of an enterprise system?

That was the Service Bus. Then the Access Control Service was what became the Azure Active Directory.

Grant: Okay, so the Service Bus was a product that you sold or was it part of the overall platform still? How did you think about introducing some of this functionality?

Omri: Microsoft is really good at packaging, so one of the things that Microsoft did historically and very infamously was it said, "Oh yeah, we have this thing, Word. We have this thing, Excel. We have this thing, Access. Each one of them competes with a different product. What we're going to do is sell Office and Office is going to be at basically the price of one of these products, but we're going to sell you all four and we have a suite."

And the very first version of Office literally had no integration between these products, it had none. Actually it was a box back when we used to buy software in boxes, it had Word and then a coupon for Excel and a coupon for Access. It was that bad.

But the business model was very sound and so Microsoft knew that we had to go package all of this stuff up.

On the one hand we needed to have consumption based pricing and licensing for each one of these services, which we experimented with, and on the other hand we knew that we had to go be able to package them up as an offer together.

From 2008 when we first launched the first version of Azure, up until now, it's come an enormous way.

At first we were just stumbling in the dark, not even knowing who our customer was, we first got confused and we said, "Okay, we want to compete with Amazon and go after the startups."

And then we started talking to startups and they were like, "Why on Earth would I use this thing? My VC tells me that if I use anything from Microsoft they will not fund my next round. It's as simple as that. I don't care if it's free, we'll never use your thing."

And so we realized, "Okay. Well, that's probably not the audience. Over time we want to build better signal value for Microsoft in that community, but we have to find other people who are a lot more amenable to what we have to offer here."

Grant: That's funny, yeah. I still have the experience of trying to sign up for an Azure account and realizing I have to create a Microsoft account and I'm like, "Well, I don't really want another email address. I just want to sign in with my Grant@Replicated.com email address, not create an on Microsoft.com in order to access."

It's just funny to me that they still to this day seem to want to control the identity layer, but by doing so they end up with their emails going to some email address that I'll never check. It's an interesting aside there.

So the Azure piece here, realizing that your customers were not the startups, but were actually enterprises and users that were deep into the Microsoft system and embracing that, I guess.

Omri: Exactly. So back to Bob, who's by the way, in full disclosure, an investor in Aserto as well. He was the CEO of Snowflake before they ended up going public. But he basically said, "We have this thing."

We used to call them workloads at Microsoft, so we had the App Server workload, which I ran. We had the database workload.

We had the file and print workload, and then we had the identity and access workload, and he always used to say, "This is the linchpin workload for Windows Server. Why? Because every server application needs to know who is logged in and what they can do, and they get that information out of Active Directory."

Active Directory had upwards of 90%, probably 95% of market share, of the identity and access workload. It also spoke LDAP, which was the other main protocol. So the thought experiment was, "What does identity and access look like in the age of SaaS and cloud? You had all these early versions of SaaS applications, enterprise, B2B SaaS applications like-"

Grant: Salesforce?

Omri: Salesforce and Workday and Service Now and all these folks, and they had to go build login on their own, there was no operating system to ask who was logged in, and they also needed to go invent their own access control mechanisms.

And so the irony is we thought about access control as being the really important problem and we started building that and then at some point we heard from people that, "We don't even know how to log in." So we're like, "Okay, we got to go solve that first. Log in actually comes before."

So we set out to go build what eventually became... I call it the Interoperability Identity Fabric, so you have things like O-Auth 2, protocols like O-Auth 2 that allow you to now use an identity provider that you're not necessarily running.

So Google can be an identity provider, Facebook could be an identity provider, Microsoft, Amazon, and so on and so forth, and that saves you from having the NxN problem again, right?

Then 10 years ago you had Auth Zero and Octa and none of these companies existed, but they saw this opportunity to leverage some of these emerging standards and build enterprise single sign on, so no one has to go build this thing that they don't want to anymore.

You now have developer APIs for developers and you have enterprise systems for enterprises that make it simple to solve the enterprise single sign on problem.

Access control is a problem that we still have to this day, we'll talk about that I'm sure, a little bit later on.

But that was what we set out to do with Azure Active Directory and we obviously tackled the identity part first, but knowing that we were very strong on Active Directory and we were trying to figure out how to parlay that into a service that would be essential in the new cloud.

Grant: Yeah, it's interesting. And yeah, we will return here. Let's just hit a couple of these other experiences, the stuff you did at HPE and Puppet and then let's dive into what you're doing now at Aserto.

And if you want to mention, I know you had some other startups and things you did along the way and some other roles, but those two seem to be the most pronounced in your career recently.

Omri: Yeah, I left Microsoft in 2011 because I was frustrated that we didn't get open source. I had always been in dev tech and Microsoft absolutely got intel in IBM and basically the standard hardware.

Then it was a little late, but it got the internet. Basically Bill turned the whole company around in 1996 and said, "This thing is going to be the thing."

And in 2001-2002, is no longer as involved and I remember at the time Microsoft was super confused about open source.

It said it was a cancer that was going to kill the rest of the industry. And even at the time at Microsoft you'd ask questions like, "So we have this web server called IAS and there's this thing called Apache, and we don't really have any differentiation.

In fact, we're a little behind it right now with its latest architecture. We can invest 50 people over the next year to go close those gaps, or we could just adopt that thing because it's commodity now."

And people would look at us like we were from Mars and they'd say, "Oh, you're in the F Windows business, I got it."

And you'd be like, "What? No, we have to own the whole stack." So when you're Microsoft and you're just such a successful company, and you have gotten away for so long with building everything, it's simple to assume that you can continue to build everything and that's the right strategy.

I think by 2011 things were starting to thaw out, but I was ready to actually go try my own thing. I wanted to go back to startup land, build a consumer startup, it ran into the ground after a year.

The biggest learning there was I'm not a consumer guy, I'm a B2B guy. And so I ended up being in the startup ecosystem.

Grant: So appealing though, right? You're like, "I've got this idea, I know how to build shit, I'll go get this thing done. No big deal. People will love it." And then you're like, "Why doesn't this work?"

Omri: So just a 30 second aside, when I first started back at Neon, this was in 1992, I asked Peter why he got to what he was building. He said, "Look, two kinds of startup you can do. You can do a consumer startup or a B2B startup."

We didn't use those terms, but that's what he meant. He said, "There are only 10 companies that actually build software that is sold to consumers." Microsoft was one of them, and I think Quicken was another one or Intuit or what have you.

There were a very small number, he's like, "Basically it's a very short head and a very long tail of startup carcasses."

By contrast, there were a lot more viable businesses that could sell B2B. I remember when I first start Build Steady, all my advisors were like, "What are you doing? You have all this knowledge and platforms and cloud and all that stuff. Why don't you just leverage that?" But I had a consumer itch to scratch, so I had to go do that.

Grant: Yeah, sometimes you just got to go try something, right? You've got to go off and see if you can do it, and you're consumed by an idea so you might as well. I get it.

Omri: Exactly. Exactly. So I ended up finding myself, after being in the startup ecosystem for a little bit in the early 2010s, HP called and said, "Hey, we're starting this cloud division. Well, we have one but we're now starting to get serious about it." And I said, "HP, are you guys still around as a vendor?"

They're like, "Yeah, yeah, yeah. All the jokes, but Meg really wants to go build this cloud thing and she's looking for people who are really good at it that could be available."

And I had a few friends that had already ended up there, so ended up joining to run engineering for the cloud division in Seattle. The thing that really brought me there was open source.

When I left Microsoft I was obviously building with open source, but this was an opportunity to actually get a better sense of how open source was built.

We wanted to become part of that ecosystem, what was OpenStack at the time, and then this was a little before Cloud Foundry Foundation was formed.

But I wanted to steer us towards an open source path for application, our PAS strategy as well, and here was a company that didn't have any of the bugs that Microsoft had.

They were not confused about who they were, they realized that they were primarily a hardware company and that they had been the distribution channel for Microsoft and for RedHat and for all these other vendors that sold operating systems, and they decided that they were going to try to get in the game by using open source and becoming part of an open source community and contributing back.

Which was very attractive because that was learning I didn't have, obviously, in Microsoft.

Grant: And so talk a bit about the OpenStack community in general. I think it's a really fascinating parallel, particularly because we've covered Kubernetes a lot in this podcast so interesting to hear your perspective around how some of the lessons from OpenStack were applied into the Kubernetes ecosystem and what was learned there and what went wrong.

Omri: Yeah. So OpenStack started out as this experiment between Rackspace and I think it was NASA. They said, "Hey, let's go create..."

Rackspace needed to go build something that looked like AWS and they decided to go build something together. I think each of them contributed one thing and it's been a long time, but the compute project was called Nova, and then there was a storage project called Cinder.

All of a sudden the open source ecosystem started coalescing around this. There were a bunch of MySQL developers that were just coming off of the Sun acquisition by Oracle, getting disillusioned.

There were just a few people that started getting really interested in what would open source look like if we were trying to build a cloud controlled lane? I would say that project, it was started out by practitioners but enterprises ended up dominating it pretty quickly.

So you had IBM move in, you had HP move in, you had RedHat move in and all of a sudden it became this political system where, on the one hand, the engineers were trying to hold on and keep control of the project. On the other hand you had these large enterprises with a lot of interest in it.

Grant: Was it the vendors or was it the-

Omri: Exactly. The vendors basically took over a lot of the governance, and there was still a technical advisory board. But there was also no guiding hand, so to speak, there's no center of gravity.

So you had all these different projects and they had different leaders, and it was like this loose federation. You could think of it as the decentralized model for open source, and that was in contrast to the BDFL model of the Benevolent Dictator For Life kind of model.

They were pretty explicit about saying, "We're trying this out, we don't know if this is going to work or not." As it turned out, the project fell over because it tried to expand too much, too fast, and these pieces didn't really relate to each other very well architecturally.

So when I think about Kubernetes, I think about the center of gravity was always Kubernetes. The CNCF now is a sprawling thing, but there was this center of gravity, this anchor tenant that really provided a lot of the design pattern.

If you look at something like Crossplane for example, they borrow the Kubernetes API, CRDs, the Kubernetes machinery, so there were a lot of patterns to build on top of. Whereas I would say with OpenStack there just wasn't enough of a core to try to build around, and so there was a lot of hype early on.

OpenStack was, I think, 6-7-8,000 people conferences twice a year and there were a lot of customers, end users that tried to build on top of it and got to tens of thousands or hundreds of thousands of cores on the system. But ultimately I think that it just crumbled under its own weight.

Grant: Right. I think it actually still has success in the world where it's running at all these telcos and powering all these data centers, it just didn't become the platform that we write software for, right?

It's like it could be under the hood but no one really knows about it and it's not really become a primitive that is really enabling developers or application builders or SREs or anyone else to build applications. Maybe it's running some infrastructure at large telcos around the globe.

Omri: Exactly. That was actually one of the decisions that we deferred for a long time, and we eventually had to make as part of the OpenStack steering committee.

There was always this dichotomy of are we building stuff for smaller companies, for startups, or are we building stuff for larger enterprises.

Given the fact that big vendors were involved that were all selling to larger enterprises, the larger enterprise agenda one.

As it turned out, the vertical that was most eager, that basically needed its own transformation was the telco vertical.

They were all going from proprietary hardware-software systems, they all wanted to go to open systems, and so that was the use case that found the most purchase with OpenStack and so more and more of the community's efforts were diverted towards building these higher end telco features.

Things that were deep down in the Linux kernel, architectures that would allow real time kernels to run, architectures that would allow direct memory swaps instead of a bunch of copying between kernel and user.

There was just a lot of, what is it? DPDK was one of the things I remember, one of the features that we were trying to deliver.

All sorts of integration with networking things like Open Daylight and that was the agenda for the community because those were the customers and the customers basically lead you.

Whereas I would say Kubernetes had not really succumbed to that until much, much later. I think it was hell bent on creating what OpenStack wanted to become, the substrate for the cloud. Then after it was able to win broadly, win at the breadth, it started moving up market.

Grant: Yeah, I think there's probably a bunch of lessons you've seen. But one that I think was taken directly from the OpenStack community was around conformance testing, right? So to call it Kubernetes, it has to pass pretty extensive conformance testing and so there's just not the variance between different providers that I think maybe you saw in the OpenStack community.

Omri: Right. If you think about the APIs for OpenStack, they were all common. Let's say you had some storage thing that you wanted to go build a Cinder driver for, you'd go build it and then you would expose all your features.

So this wasn't a write once, run anywhere kind of thing. These were all basically thin shims on top of hardware that wanted to expose itself to the world.

Whereas I think a lot of the things in the Kubernetes world like Rook, for example, that's a software solution and there are things that plug into it.

But I think that there's a lot more commonality, to your point, so that you have a very consistent experience no matter what you're running it on top of.

The other big learning, I would say, is that OpenStack had no adoption from the large cloud vendors. Microsoft wouldn't give it the time of day, Amazon certainly didn't, Google didn't, and so basically you'd have no pull from that. The largest vendors that did have OpenStack based systems were the second tier like HP and IBM and Rackspace. That was just not enough nodes, that was just not enough public cloud infrastructure to make a difference.

Whereas I think with Kubernetes you had Google as your anchor tenant and pretty quickly Microsoft saw an opportunity there, and then eventually I think Amazon got there too.

But when you have two out of the tree large, hyperscale, public cloud vendors that are on that architecture, you've already crossed the tipping point I think.

Grant: Okay. So then let's briefly go into your time at Puppet and then let's talk about Aserto.

Omri: Yeah. So Puppet was a lot of fun because it was right in the middle, I had done startups, I had done large companies, Puppet was 500 people.

On the one hand it had a good brand with devops, on the other hand it was pretty clear that its value proposition was getting disrupted with containers and with the cloud.

When I first got there, the what if or the kinds of questions that I was asking was, "Do we want to be Puppet for the cloud?"

And people were like, "What do you mean?" I said, "When I look around I see things like Terraform kind of being Puppet for the cloud. That's what Mitch will tell you, he set out to build Puppet for the cloud."

And it was a hard transition because I think Puppet at that point was so focused on its customers, specifically folks that were large companies that were standing up lots of infrastructure, tens or hundreds of thousands of nodes.

It was very focused on its knitting, which was try to make it as simple as possible to manage configuration on all these systems.

The physical to virtual machine was super simple, that was really easy. The move to containerization and to microservices was much more of a head scratcher.

Basically when I first arrived there, 100% of the engineering and product effort were focused on the software that we had, and part of the process there was to start transitioning more and more of our innovation, all our product engineering and product effort to working on this new world.

Some of it was just even experiencing the new world, like starting to Dockerize our stuff, starting to run our stuff in Kubernetes.

At some point we started working with you guys at Replicated to take some of our software and make it be able to transition it, run it in different places.

Grant: Modernize it, run in Kubernetes in custom environments. Yeah.

Omri: Exactly, exactly. I would say I underestimated how much of a transformation that would need to be, but one of the biggest things I learned there was about really writing a product that had its own open source ecosystem.

There were three models, there was obviously the closed model and then there was this open source model but you were a single vendor, and then there was this multi vendor open source ecosystem model.

So we tried that latter with OpenStack and later on Kubernetes and Docker was a little bit like that. Puppet and Chef were more of the single vendor ecosystem.

Grant: HashiCorp, many.

Omri: Exactly, HashiCorp is a great example of one that is as well. I wouldn't say that one is better than the other because I used to say, "Well, multi vendor open source ecosystems tend to win out over closed or over single vendor ones. But that's not obvious."

I think HashiCorp has won in some where they had a clear value proposition that no one else was doing, I think Terraform is a great example of that.

In other places I think the multi vendor approach got to scale faster and I would say that there's still people that use Nomad and love it but Kubernetes is definitely the thing that won that generation.

So with Puppet, some of it was about how do you actually look at the new world and some of it was what do people actually pay us money for?

So the conventional wisdom was people want an enterprise product and enterprise support. Well, what does that mean exactly?

So you start digging in a little bit and some customers will tell you, "Well, I don't pay you for all of the agents that I run on my Linux nodes, or between Linus and Windows. 99% of my infrastructure is that. I pay you for the 1% that run on Solaris or AIX or Z Systems. I don't even have Z Systems anymore, but just the fact that you have that available makes me feel like you have the breadth to be able to support me because I'm a Snowflake and I have Snowflakey types of requirements."

So you may have less than 1% of your overall node count may be on a particular platform, but your most loyal consumers are valuing you for that so that's a pretty interesting product.

That's a trade off, do you actually support a long tail even though you know that hardly any people use it, but on the flip side it gives you that credibility with those enterprises?

Grant: Yeah. It's almost like scarcity creates value to some extent as well, because it's kind of like, "Well, this is the only way that I know how to do this and the fact that you continue to do this means that there's no competition there, but I wanted to have standard tooling. So I need you to continue to do that in order for me to use the tool." Make sense?

Especially when you think about the idea of enterprises add new technologies on but they don't necessarily drop old technologies at the same rate so it's an expanding pool. They do drop some occasionally, but I think there's more adding than there is subtracting.

It's kind of like laws in the same sense, there's a lot more laws that are added to the books than are taken off and so you need tools that continue to manage all of that. A lot of what enterprise software does is help end customers manage the complexity of years of legacy tooling or old operating systems, old apps, old systems just because that's what you need to do. You need to manage a lot of complexity.

Omri: Exactly. Ultimately enterprises pay you for manageability. They live in a sea of technology, to your point, and the level of complexity of trying to manage that heterogeneous environment is staggering, and that's what they spend a huge chunk of their IT budget trying to do.

And so anything that helps them make that morass more manageable I think is very attractive to them. Speaking of Rback, that's one of the most obvious things that people paid for when it came to Puppet, right?

So Puppet was a great single workstation tool, and as soon as you tried to make it work for teams, so scale up both in terms of the number of nodes as well as the number of people involved, that was where I would say the interesting monetization opportunities were.

Puppet didn't really get its open source strategy right at all, if you have Luke on your show, Luke Meest, the Founder of Puppet, he'll be the first to tell you that.

Grant: It's hard because they were one of the first vendors out there doing it well and there wasn't necessarily GitLab and even Puppet today, many of these other companies that figured it out better today, the model wasn't as clear.

The commercial, open source model, it was like everyone pointed at RedHat and that was about it, but there's more ways to do it.

Omri: Yeah, exactly. And Luke would say that back then what was emerging was this open core model where it made sense for databases, so MongoDB for example had an open core and then they would build features around it.

For Puppet, there was this interesting architecture where the tool gave you value running it on your own workstation, Puppet Apply, and it had the same exact interfaces, basically the same DSL, Domain Specific Language, for authoring all of your modules and things like that.

But as soon as you started wanting to manage fleets of things you needed what was back then called the Puppet Master.

So that was also open source, basically Puppet decided to open source everything, the server and the client. Luke would say that was a critical error, because that brain, that orchestrator was the thing that actually provided the scale for the system, and enterprises tend to pay for scale.

And so companies like Apple and Google had literally hundreds of thousands of Puppet nodes running and weren't paying Puppet a cent because the open source software was good enough and some of the specific scaling points, things like Rback and other things, they just build point solutions for.

So one of the biggest learnings he had, and I've adopted as well, he calls it the Open Edge model where everything at the edge is open source, so anything that an application interacts with or a developer interacts with has to be open.

The engine is open. But the brain, the control plane is something where you can actually add a lot of value and therefore build a real value proposition that you can sell.

Grant: Yeah. So let's dive into Aserto, so on, let's talk about the inspiration for it.

We talked years ago as you were thinking about it, and so excited to hear how you tell the story today. Let's talk about what the product does and let's talk more about Rback too, what it means and what it is. Let's start with the founding story.

Omri: Sure. So again, back to the 2007 days where we, me and my co founder, were both working on what became Azure Active Directory and the idea was try to reenvision, reimagine what Active Directory would look like in the age of SaaS and cloud and identity and access.

When Gert and I popped our heads up around the summer of 2020, we were like, "Okay, time to do something, time to do a startup."

We knew that we were both in the intersection of developer and enterprise in the cloud, maybe, and we were asking ourselves, "What's still hard to do?"

And we went back and looked at all the different things, and access control was immediately something that we noticed, "Uh, there's an API for that, for everything, except for access control. Why is that true? Let's go back to our work at Microsoft and try to figure out why that's true and why that could be something that we could go after."

We immediately picked up on the fact that it was a much harder architectural problem than, let's say, standing up a service that does text messaging or payments or email or even authentication. Most of those are one and done, they're not in the critical path of your application.

You want a payment to go through and when you get a 201 back from your Rest call, you want to know that you're going to get paid. But your app is not waiting for that.

Whereas authorization, access control is in the critical path of every application request so it has to run close to the application.

That's why the state of the art is libraries in a bunch of different languages, and every one of them is different, there are a bunch of different patterns, it's all a cacophony. Node.JS has its things and Go Lang has its things, and Python has its things, and there's no leverage, no reuse. It's all a bunch of spaghetti code strewn across your application.

So you really want a service, but you want it to have the operational characteristics of a library. You want it to be 100% available to you, not 99.99% available, but 100% available because if the authorizer is not up then your application is down, right?

And you want it to be very, very fast. So we realized it needed a hybrid architecture and that was a new thing, you don't really see developer APIs that have that very often, where you have a component that runs right next to your application and then you have basically a control plane that runs in the cloud.

If you look at the Kubernetes architecture, it gives you words now to describe what that is.

We have a word called Sidecar, that basically is a container that runs in the same pod as you.

So there's a why now aspect to this where I think, architecturally, the cloud native world has evolved to the point where we can now talk about these hybrid architectures as something that you don't have to go reinvent a whole bunch of stuff, you can lay it on top of existing patterns.

Then we of course did the requisite talk to 100 CTOs and VPs of engineering and ask them about problems they have, and specifically about access control. 98% of them basically came back and said, "Big problem I have to build right now. It costs me a lot of money to build and maintain.

It's not really core to what I do as a business, but I have to get it right if I want to go sell into larger customers." So we'd start asking them, "How often do you rebuild these things?"

And they're like, "Yeah, every year, year and a half I have to go back to the well and put a team of three or four people on it. They think it's going to take them two months but it actually takes six months, and there's just an enormous opportunity cost around that."

So we definitely saw that pattern of developer API, that there was room for and at that point it was a matter of can we build this? And so we started looking around, and again we're big believers in open source and open ecosystems, we found obviously OPA in the CNCF that looked to be an interesting engine to try to build around and on top of.

Grant: The Open Policy Agent, right?

Omri: The Open Policy Agent, exactly. So we didn't see a whole lot of other people doing it, but the ones that were inventing their own languages and building their own engines, and we thought that that was actually going to be a distraction.

Instead of doing that, which we know how to do but it's undifferentiated heavy lifting from our perspective, go find a common engine and go solve the architecture problem.

How to bring data to that engine in a way that that engine can operate in hundreds of microseconds or maybe a very small number of milliseconds so it's operating on cache data and solve that synchronization problem? How do you bring data to that engine?

How do you bring user information to that engine so that it has it cached locally? How do you bring resource data to that engine? Those seemed to be the hardest problems, and so that's what we ended up setting out to solve.

Grant: So the position is it's actually the hardest part isn't how to describe the policy. It's more like how do you actually implement this in a way that's hyper efficient and fast?

Omri: Exactly. Because if you are just an enterprise that's walking up to OPA and saying, "Okay, I want to go build on top of this," all the hard problems are still there.

You're certainly going to have to learn a language and you have to learn how to interact with that particular component.

Grant: And the language, you mean RegGo, is that right?

Omri: RegGo, exactly. But the hardest parts are really how do you build a distributed system that allows you to gather all this data that the authorization engine needs to make an authorization decision, as opposed to having the authorization engine go make a bunch of Rest calls to a bunch of systems?

Those could be across the internet for all you know, and those will give you a very rough experience if that authorization service is in the critical path of every application request.

So I think there's a hard engineering problem here, and if you see the need which is every single B2B application has to solve this problem, and the cloud native technologies are just, by themself, they're insufficient to be able to address it properly, we saw a pretty big opportunity.

Grant: Sure. Not just every B2B application, but every application that's internal to enterprises, right?

You're writing an internal tool or creating something, you need to have different roles that people can use and leverage in order to decide who has what permissions. So it's based on that principle of least privilege, right? It's that security principle in a sense.

We talk about this on the Enterprise Ready site, it was always a core feature of enterprise readiness for software companies, is to have good role based access control where you're identifying.

Say someone signs up, I can assign them the role of a salesperson, and that salesperson is going to have different permissions and access than someone with the role of an engineer, and someone with the role of support.

So you have all these different roles and you think about it as even like groups, right? What's the language that you use or define? Because there's clearly resources which are the actual things that you're acting on, there's actors.

What are the words that you use to describe these different key components or players in role based access control?

Omri: Yeah. So we start with the authorizer, right? The authorizer is a thing that takes some inputs and produces an output.

The inputs are what we call the user context, so whether that's a machine or a particular user, you have to know in the context of who you're evaluating this authorization decision.

There's the resource context, which is basically how fine grain you want to take it. So some people say, "Well, every kind of resource in this project needs to be managed in the same way." Some people say, "Well, every document in this folder needs to have its own authorization."

So you can take it as coarse grained or fine grained as you want.

Then finally there is what I would call the authorization policy, so the set of rules that allow the authorizer to reason about this user context and resource context and make decisions, and that's the output.

The output is a decision. Typically the decision would be to allow or deny access to that particular resource, but you can build other types of decisions as well.

So one of the patterns that we heard about early on was, "Well, there's my API and I want to have allow/deny decisions based on user context and resource context. But then I have my UI, I have a React app and I want to actually control whether I'm rendering a set of controls, a set of components or making them enabled or disabled based on the user context."

And it's all spaghetti right now, there's no relationship between these.

One of the early realizations that we made was we could define not just an allow decision but also a visible decision and an enabled decision, and so have a single policy that drives not just API authorization but also some behavior on the client.

Those are some of the convergence points that make people start imagining what's possible.

Grant: Interesting. And so where is the product? How far along? What's the status?

Omri: Yeah. So we launched a private beta back in June and we had a bunch of folks that worked with us, with design partners and a few of those are now customers.

Last month we basically opened up our doors so now we're in open beta. We have production level customers that are running on it, so beta is more of the sense of our APIs are still evolving so we haven't cut the 1.0 on the APIs yet.

It's a little bit like HashiCorp, who has had 0.XYZ types of releases on things because I think Mitchell and Armand, they think that 1.0 means something and we do too.

But at the same time, we're working with a fair number of really interesting customers at pretty large scale points, I would say, to be able to essentially build authorization into their SaaS solutions.

Grant: Cool. And who's evaluating it? Is it a developer? Is it a product manager? Who's the ideal customer?

Omri: Typically it's some combination of developers that are trying to figure out, like, "I need to go and solve this problem."

It'll typically be a staff software engineer. Then oftentimes it has to involve, oftentimes, always has to involve a head of engineering, a VP of engineering or a CTO, and so that's an interesting bottom up versus top down type of dynamic there because you need to have a champion, you need to have someone who recognizes that they want help on this problem.

Oftentimes the three drivers are it's going to be way more expensive for us to build it ourselves, and/or it's going to take way more time for us to build it ourselves, but almost always includes, "And these folks know a lot more about building a secure solution than we do."

And so it's been a very interesting journey, because as we've gotten case studies like customer evidence, our customers basically tell us, "Well, we did the evaluation and we decided that the ROI was 20X better to use your thing."

Which was like, "Hmm, maybe we're leaving some money on the table."

Grant: All good early products do.

Omri: Exactly. But even more importantly I think it's, "Well, you guys think about the end to end. You help us design what a good authorization model looks like, all the way to you know what the audit trails need to look like so that we can sell our stuff into enterprises."

I think that's a critical piece, right? Because every startup wants to grow up to be able to sell into larger and larger companies, especially OSS startups, right?

Where if you look at Puppet, we had 40,000 organizations using Puppet, about 1,100 of those were customers and probably the top 20 paid for 95% of our salaries.

So you have to have those larger companies that are betting the farm on you, and in order to do that you have to meet this pretty big Excel spreadsheet of requirements and at the very top of those will be things like you need to be able to allow me to run it on prem. Right?

You know about that. And right near that top, maybe even neck and neck with that is you need to be able to work with my roles and permissions, you need to allow me to build custom roles.

Every decision that your software makes needs to be auditable and I need to be able to push that into my SEAM system, my Spelunk or my Elk or whatever it is.

So there are pretty significant requirements and when you start adding all those up you start realizing this is not designing what viewer and editor and admin and those roles do. There's just a whole set of machinery here that must be there in order to be able to close that sale.

Grant: Yeah. For sure, that is the whole thesis of the Enterprise Ready piece, it's looking at those vendor security questionnaires and realizing like, "Hey, there's a whole standard set of features that everyone needs to have," and that was the impetus.

I think it's great to see services like Aserto out there now that help folks get there faster because we're all building these non differentiating, features that are table stakes and everyone's reinventing the wheel every time, and there's actually big advantages if we can standardize on how to describe those policies because then you can leverage policies across different applications or you can centralize policy management on the enterprise side.

There's a whole bunch of different reasons why standards are actually really important, and I like that you have focused on OPA and RegGo from that perspective because I think having those standard ways to describe these things is really foundational.

Omri: Yeah. I couldn't agree more. Going back to that NxN and transforming that into an N+N problem, that really I think is why we're so excited about this space.

Because if you think about the life of an IT administrator today, they live in dozens if not hundreds of different console experiences, every one of them exposes a different set of permissions, rolls them up into a different set of roles, has different processes for how to map between what you, the enterprise IT administrator, think of as a sales person and what they call a sales person.

So misconfigurations are rampant, people leave and they still have entitlements, it's a nightmare for the CSO, it's a nightmare for the IT department. It's terrible.

And so enterprises have this big incentive to try to standardize, and if you think about the conversation we had about databases a little while ago, the same pattern is going to end up emerging here where in the same way that I, as an enterprise, wanted to standardize on a small number of enterprise databases, I, as an enterprise, now want to standardize on my enterprise SSO and also my enterprise access control plane.

I want to be able to define for all my users, all these different types of roles or groups or what have you, and be able to map them into all of these applications, both internal and external applications.

That you only get when you actually start getting to standardization.

Standardization is not something that one vendor does, I would say its a wave that floats a bunch of boats, and so we're at the very, very infancy of that and I think we're going to compete with a set of people that will want to go build things that are similar to what we're building.

But just as critical is for us to figure out how to cooperate and build a broader ecosystem so that we can bring about this convergence.

Grant: Yeah. Even if there are three or four competing standards, in a sense, it's better that they're standards versus 5,000 different bespoke ways of doing this, right?

And so this applies everywhere, it's like, "Hey, it's better that there's some standards even if there's a couple competing ones. That's better than none and everything is just completely custom and bespoke and is not reusable, so not standardized."

So even if those end up being consolidated, completely or totally interoperable, something towards a handful of interoperable systems is better than completely bespoke ones.

Omri: Exactly. A good example is you still see access tokens that are Samal, and you also have JWT, most of the new applications are using that.

It's fine to have two, and it's just like a tax we all pay, so to speak. But it would not work if there were like 2,000. Right?

Grant: Right, exactly. When you think about building a product like this, what are things you're applying from your previous experiences?

You've been so deep in Microsoft, HP, Puppet, what lessons are you applying to make sure you don't make some similar mistakes I guess is the first question.

Omri: Yeah. One thing I would say is really understand what problems your prospective customers really have.

I think that it's so easy to go and build stuff and, "If you build it, they will come."But really getting a lot deeper into what it is that is really problematic for them, where it is that you need to be able to meet them where they are, as opposed to have to go invent things that they have to adopt, and then where do you actually add value?

So for us we had that early conversation around do we want to go build an authorization engine? And my co founder, Gert, who's a titan of technology, he helped build the storage engine for SQL Server, and he was Chief Architect at Hulu and wrote the first lines of code on Azure Active Directory.

We had the team that we could assemble to go build an engine, but we realized that that wasn't the place where we were going to get the most bang for the buck, and instead people were really asking to solve things that seemed much more pedestrian but were actually much more practical.

Like, "Well, all our users come from Octa, Raw Zero or Azure Active Directory, and so how do I actually get my user information into your system?"

Like, "Ah, let's go build the directory, let's go make connectors into all these things. Architecturally, let's make them plug in points so that people can build other ones. We don't have to build them all. Let's go and standardize on what a user looks like so there's again NxN to N+M. Then let's go figure out the protocols necessary to take all of that information that's collected by the control plane and push it down to the Sidecar, the open source authorizer that we have."

That's one hard won lesson, I would say. Another one is really thinking deeply about where you want to be open, where you want to be able to provide an open source solution, and where you think you actually add value, where even though some people are asking you, "Well, if you open sourced this, I'd use this."

Is that really the right thing for the business long term? And so we're very clear with people, we say, "The edge, the open source, the authorizer is open source, it's built on top of OPA."

We basically build a set of capabilities around it that make it much more valuable to you in the application authorization scenario and you're free to use that, in the same way that you were free to use Puppet on a single node.

But if you want a control plane that helps you manage all that complexity and solves hard problems like mutual authentication, mutual TLS between the clients and the servers, having what we call a satellite, an edge authorizer become managed, all the audit trails and centralizing all of those.

That's what we've built in terms of value and you can run that on prem if you want, but that's the thing that is not open source and that's something you pay us money for.

Grant: Cool. That makes sense. It also seems like you took some lessons around team building and how you put this together, so talk a bit about how you think about growing the team and scaling out and going to market, the whole inner spectrum of early company activities.

Omri: Yeah, I mean 0 to 1 is really hard, and I would say in some ways it doesn't matter how much experience you have, it's still pretty darn hard.

The first thing that you need is a great partner, and so I found that with Gert, obviously. This is our fourth rodeo together, we worked together on Microsoft and at HP and then at Puppet, and now with Aserto.

We don't agree on everything, but we have a pretty good shorthand and a lot of trust in terms of how we resolve conflicts and issues. I think the initial team, knowing that we had something pretty engineering intensive to go build, we knew that we needed to hire engineers and we were fortunate that we had a pretty good network.

Including a team that we had worked with in Romania of phenomenal engineers that we acquired into HP and then I brought them onboard at Puppet, and now some of them have chosen to join us as well.

So again, this is our third rodeo together so having a team that has a fair amount of trust built is important. At the same time, you don't want everybody to think the same way so you want to build, you want to seek diversity.

The notion of going out of our first and second order circles, but really trying to attract other people that bring different perspectives, that's easier said than done. You have to get your name out there and there's a little bit of a chicken and egg.

We were fortunate that some people found us and some people got introduced to us that ended up being great fits.

The other thing I'd say is we were born during the pandemic and any kind of old fashioned ideas about being collocated were pretty obviously not going to carry to the future.

I recall having developed a pretty strong sensibility around you either want to be collocated or you want to be remote first.

There's not really any room in the middle because if you have half the team remote and then the other half of the team hangs out by the water cooler, it creates this kind of information asymmetry that's really difficult to overcome. And so we're a fully remote team, we do have obviously a set of people, clusters, a cluster in Romania and a cluster in Seattle, a couple people in California, a couple people in Indiana.

But everything that we do, we do online and so I think that has been important from a culture wars perspective.

Grant: Yeah. I totally agree. It's funny, our VP of Engineering and our CFO are both in Austin where I'm located, and a handful of other folks, our VP of Marketing, those two are my direct reports, and I don't see them in person more than I see anyone else on the executive team in person.

That's just the culture, it's like, "Hey, we only get together really online because that's how we..."

And when we do get together in person, we're all going to do a little on site together somewhere.

Omri: Yeah. I'd say one other lesson that I can think of is the lesson of humility.

I would say early in my career I thought I knew a lot more of the answers than I did, and as you put more years into this business, you realize the only thing that's common is I don't know anything, and every situation is different and you need to approach it from first principles.

Some of your experience is going to be useful to bring to bear, because you've seen some things that have worked and some things that have failed. Just because it failed before doesn't mean it won't work again, and vice versa, so I think having the curiosity and the willingness to be able to fail and learn and fail again and eventually succeed.

I think it's just one of the critical attributes that we look for in people. Oftentimes when people come in and say, "Oh yeah, yeah, I've done this. I know what phase you're in, I know how to do this and all that."

It's a little bit of a turn off because I'd say this is the first time we're doing an authorization startup. There's a bunch of things to learn. I did a startup back in 1992 to 1998, doing a startup now, literally there's almost nothing in common between what we did then and what we're doing now.

So having that approach to every day with humility and the curiosity and wonder, I think is really important.

Grant: Yeah, I love that. It's a core value for us as well. To your point, no one has ever built a company this in 2022.

This is the first time that's ever happened, and so there's a bunch of new things and different considerations that you have to have into effect and you have to think about everything as like, "Hey, we're going to try and experiment and try to leverage some of our experience to make good decisions. But hey, we can be wrong, we're wrong a lot, and that's okay. We just try to be more correct faster."

The idea of humility and curiosity really do pair well together. Because I think someone told me, they were like, "It makes sense because only really curious people have a sense of humility." Because they know the reason you're curious, because you know you can't be right about everything, you know you don't have all the information, you know that you want to learn, that there's room to learn. Those two values really pair up well.

Omri: For sure.

Grant: Cool. Omri, this was a great talk. It's so much interesting experience to dig into and thank you for sharing.

You're one of those people I love talking to about a prior generation of software, because I just learned so much and I'm like, "Oh..." because generally a lot of the reasons why things are the way they are today, is because there is some precedent that was set prior and so you can actually learn a lot about why things are the way they are today, but just trying to understand how they got that way in the first place and what was happening before.

Sometimes it was the right decision and sometimes it wasn't. So thank you.

Omri: Yeah, thank you. Always a pleasure to talk to you as well.

You're such a great conversation partner and listener, and I love your perspective because one of the things I've learned in my career is that never assume that because something happened in a particular way, it's going to happen the same way again.

And so having just a breadth of perspective is so valuable, and I always find our conversations a great give and take because I always learn so much when we talk. So I really appreciate it.

Grant: It's two ways. I love that. Thank you, Omri.

Omri: Awesome. Thank you so much.