This is identity at the center. If it has anything to do with
IAM, this is the go to podcast now your hosts Jim McDonald and
Jeff Stedman. Welcome to the Identity at the
Center podcast. I'm Jeff and that's Jim.
Hey, Jim. Hey, Jeff, how are you?
Not so bad yourself. Doing great.
Really excited about the episode today.
Salto dot IO or Salto as the company is called.
I first got introduced to them at the Octane 2023 conference.
They had a booth near where I was sitting and I thought, you
know, I've got all these identity at the center stickers.
Obviously I can trade them. They're like currency.
Go around. You can trade them for whatever
booth giveaways they had. And they had these killer socks.
And so I still wear these socks, right?
But I I just had to find out what do they do.
And they solved a problem that became apparent to me, you know,
many years ago in one of my first Okta projects.
And as I was going through this project, my question was, OK,
well, how do we take the configurations from a lower
environment and move them into production?
And the answer was, well, basically just redo them in
production. And it was a blank stare and a
moment of silence because it was like, seriously, that's the
answer. And so I just for years and
years that was the answer. And these folks at the booth
explained to me like that's the problem we solved and they
showed it to me. I'm like, Oh my goodness, so
much better than the socks. And these were good socks.
But that was like it was like an eye opening experience.
So really kept these guys in mind, and I talked to many
clients about that over the years, and today we're gonna
have an episode about it. Yeah, why don't we go ahead and
talk about that episode? So today definitely is a fully
sponsored episode sponsor Spotlight as we call it.
We have collaborated with our friends over at Salto to create
this special discussion that we'll talk about get to learn
more about Salto. I'm not super familiar with it,
Jimmy. You're more familiar than I am
with it. But I think this is also maybe
the first time you've heard the term stare and compare.
Is that right? You've not heard that?
Before exactly. That's the origin of that.
And I've I've stolen that. Actually, people didn't know
that that wasn't mine, so now they know.
Well, to be fair, I've heard that one for years, at least 10
years ago, so I was a little bit shocked.
But hey, we always learned that they knew, right?
So today's sponsored episode is by Salto.
They specialize in DevOps for business apps.
You can find them on the web at salto dot IO.
We have a special web page salto dot IO slash idac and that's
where you can find out more information.
I'm excited to welcome Gil Hoffer.
He's the Co founder and CTO at Salto.
Welcome to the show, Gil. Thank you, Jeff, and thank you,
Jim. Thank you for having me.
Yeah. Thanks for taking the time.
And obviously Jim is has got a little more I think insight into
what you guys work on. But I always like to start with
the person, tell me a little bit about your identity origin
story. How did you get into the world
of identity? Is it something that you chose
or did it choose you? Great question.
So well obviously Identity is part of everyone, right, but in
the in the context of computers and and software.
So I think the first time that I started dealing with Identity
was in my previous company when we had to start building some
SSO solutions etcetera. So that's the first time that I
started learning about it. And then in salto our customers
all the time talks with us. Well, we understand what you're
doing, but can we do it with Octa?
Can we do it with Azure ID or Entra etcetera.
So they they pulled us back in. I thought I was out of the
Identity game, but they pulled us back in.
That's how the identity space works, right?
Just when you think you've escaped orbit.
Nope. There's some gravitational pull
that that brings you back in. Jim mentioned what he sees Salto
is doing. But I want to give you the
opportunity, right? You're the expert.
Tell us more about Salto. What do you do?
Of course so at Salto we're a DevOps platform for managing the
configurations of business and IT applications.
So as you all know, typically a modern company is using a few
10s if not hundreds of those applications SAS applications.
Typically to run their business, you would need to configure or
customize them in order to in order for them to fit your
business processes. Typically this is being done
very manually using UI, no low code kind of ways.
And at SALTO, we enable our customers to bring all of those
best practices and processes that are typically being used
for development and DevOps and rely on the fact that we're not
using AUI to do all of those, whether we have code and we
enable our customers to to use these kind of IDs when managing
those configurations. So instead of just clicking and
steering and comparing and having endless spreadsheets with
everything that we've done, we can use git, we can automate
changes, we can implement once in a sandbox and then deploy
those changes to production etcetera.
Everything becomes much more process oriented, automated,
repeatable, just like the way that we typically work with
DevOps and and code, but applied to the different business and IT
applications that we support. So what was the genesis for this
idea of Salto? How did this thing get started?
What was the the idea that I was like, oh, we need to do
something about this? Yeah.
So, well, for that, I need to go back to our previous company, so
before Salto with a company called Ravello, Ravello Systems
and a very different domain. And we were actually an
infrastructure virtualization company.
We're a virtual cloud provider. We develop our own hypervisor
and virtual networking, virtual storage etcetera.
And for the SAS company, I started around 2011 and as any
other company those days we're using all kind of different SAS
applications run our business, right.
So Salesforce and NetSuite and Zendesk and Girai and Mercado
etcetera. And frankly speaking, the way
we're managing those business applications, it was probably
the least professional thing that we did in that company.
It was like that host potato that we kept on bouncing between
departments and all kind of consultants helping us.
And really no one knew what's going on with those
applications. And luckily the business with
Ravel picked up very nicely and the company grew quite a lot.
And then at one point in time, I remember I was running
engineering back then we had a project to redo our pricing
scheme and I was sizing the project.
I said well, yeah, it will take us about two months to implement
this. And then I remember it as if it
was yesterday. I remember our VP of Product
Management coming into my room and asking me, well Gil, I
understand that you say that it will take two months in the
product, but what about the implication on on Salesforce and
and the NetSuite? And I was looking at him and I
told him, well, I don't know anything about those systems.
Let's let's look and obviously there were all kinds of
implications and we started pulling the responsibility over
those systems in house into engineering, started shifting
resources etcetera. Things got slightly better.
Then it was early 2016, we got acquired by Oracle.
Now one might imagine that Oracle great respectful company
knows how to manage these kind of systems, right.
So after we got acquired, everything became so much more
complicated in the way that we manage all of those systems
including identity by the way, where the interesting project
about integrating the different identity systems.
And we realized that things that typically when we manage in in
code, in a system the way that we're used to would take us a
few days, takes us many, many months to actually achieve and
implement. That's when we started looking
very deeply into the way that companies manage their business
and IT applications. And we realized that the way
that those systems are typically being managed, it feels very
similar to the way that IT infrastructure was managed about
20 years ago. About 20 years.
I was managing a large team that dealt a lot with data centers.
And a typical guy on my team would start his day with a box
in his hand, go down to the data center, put that server into a
rack, pull out one of those nifty foldable keyboards, and
start typing commands all day long.
Right. Installing stuff, obviously not
scalable, very error prone. And back then, well, the IT
organizations dealt with it like they know with red tape and
bureaucracy and you got an SLA of two months for a new server,
etcetera. Who remembers those days.
And the way that the industry dealt with that was by importing
best practices from the way that we used to manage software and
applied into the way that we manage infrastructure.
So all of a sudden it wasn't an IT person going into the data
centre. It was automation with, if you
remember Chef and Puppet and these kind of projects back then
and today, it's all about infrastructure is code.
So you Terraform for example, so you can manage everything in a
source control repository. But at the core of it is that we
enabled the industry, as an industry to manage
infrastructure the same way that we manage code.
Everything became very repeatable, well defined
etcetera. By the way that we manage the
configuration of our business and IT applications.
It still looks like 20 years ago, everything so manual done
directly in production or if you would like to do it in a in a in
a staging environment or development environment before
you would typically document it meticulously and then repeat
those changes again as Jim mentioned before.
So that was a realization that, well, we understand the problem.
It was already solved in a different domain, All right.
That feels like a good idea, good business to start.
And let's bring all those goodies to the way that
organizations manage their business and IT applications.
So that was around five years ago when we started a company.
And today it's really exciting because we have so many
customers using us to manage those critical systems.
And I just took it a few days ago.
So five different continents across all kind of different
applications, a different domain.
So that's a lot of fun that. Sounds pretty exciting and I
wanna we wanna ask definitely some questions about how this
works right and use cases and things like that.
But I think I am always interested to hear about company
names. How did you come up with the
name Salto? Why call it that?
Yeah well it's not the it's not the best story but so as I
mentioned before Salto with a company called Rovello Rovello
Systems and in Salto of two two Co founders and before Revelo
they had two other companies. One of the the one before Revelo
was called Kumarnet with AQ and the one before Kumarnet would
was called Pentagon with AP. So you might imagine it was PQR.
We needed something that starts with an S and then we needed it
to be short and the domain to be available.
And just as we're about to start, Salto Rami, my partner
and CEO, he was earning Italian, he he was earning Italian.
He went to Rome for a few months in order to brush his Italian,
and he suggested a saltare. A saltare in in Italian means to
jump to leap. And I told him, well Rami, it's
it's too long, no one will be able to actually pronounce it
correctly. And Salto, both in Italian and
in Spanish it means to leap. It's basically the the noun of
Philippe like somersault and and we thought that it is also a
nice metaphor because we're basically enabling the industry
to leap forward and take all of those IDs that I mentioned
before and apply them here. So connect all those.
The fact that it starts with an S that it is metaphorically
relevant to what we're doing and the domain was available that's
the company name and there are by the way there are endless
pans that we're using on Salto. We'll get to it as we talked
about the the technology. Yeah, having the domain
available is is very key, you know, right.
I thought of and realized that as I was doing that introduction
earlier and talking about my early experience with Okta may
have come off as like, Oh no, he's kind of criticizing the
Okta's approaches. But the reality of it is, is
they've opened the API to make it available for Salto to even
exist. If it wasn't for the API,
there's no way you could have the Salto product be able to do
what it does. Is that correct?
Yeah, it's 100% correct. And without API wouldn't be able
to do that. And the problems that we're
dealing with in SALTO, they're not specific to Octa.
So it's actually quite common. For example, support Zendesk and
Dura and Salesforce and NetSuite and and multiple different
applications. It is quite common that there is
no way to actually deploy changes from a lower environment
to a higher environment. And come to think of it, there
is a lot of investment that those vendors need to make in
order to to make it available to very easily have sandboxes that
are synced from production to be to make it easy to deploy those
changes and to understand what are the difference between
different environments etcetera. It's not surprising that those
features are missing in many cases, because for every vendor
to build them it's it's costly. No, it's good.
So it's kind of a tip of the cap to them.
One of the things that one of the things that I want to make
sure that we don't do is, you know leave anyone in the dust in
terms of explaining what Salto does.
So I was wondering if you could, thinking of it from the
perspective of an Oct administrator, what would they
use Salto for and how would they go about doing that?
Yeah, of course. Great question, Jim.
So typically an Octa administrator let's try and
portray a day in his life. OK, so let's say there's a
requirement to go and implement a certain change to the to the
configuration of Octa, let's say to some authentication policy.
So the first step for the for the admin to do is first of all
to analyze what would be the impact of that change.
So what are all the other configuration elements or parts
of the implementation that will be impacted by that change.
Then that admin would go and implement the change in a
development environment that should be very similar to the
production environment. And after testing, you should
eventually also be able to deploy those changes to
production while also being able to roll back if needed.
So that's what the admin needs to do.
Now let's describe how it does that with Salto.
So with Salto, the admin will have all of his environments,
all of his different tenants connected to Salto, and Salto
automatically reads the configuration of all of those
tenants on the background. We use those APIs.
We read all of the data all the time and we use a format which
we call NaCl Knuckle which stands for not in our
configuration language and just happens to be the chemical sign
formula of salt. So we read all of that
configuration into Salto and the first thing that we enabled that
admin is visibility. So you can very easily
understand what is that you have implemented.
You can very easily understand all of different dependencies.
So for example, looking at that specific policy, what is it
dependent on and what depends on it?
So we'll be able to know what we might break when we make that
change. Then that admin would go into
the lower environment that should be synced from
production. We can help with that as well.
Implement the relevant change in Octa using the UI doesn't need
to change the way that he works in his day-to-day.
And then Salter would automatically detect what was
changed in that environment, show it to the user, enable it,
enable him or her to also push those changes into Git.
So we'll have proper paper trail for everything that was changed
and deploy those changes to the higher environment.
So in alternative universe, what you should have done is develop
those changes in that in that lower environment in Octa test,
right, Typically and we see it with customers having like very
long spreadsheets which document everything that they changed and
then they would need to go and reimplement those changes in
production. And this is extremely risky
because there might be all kind of differences between a
different environment that he is not aware of.
And then the fact that it tested something on the lower
environment is almost meaningless because it typically
would have tested it on a different environment.
He's unaware of the differences between those different changes.
And then when deploying to production only production is
the environment which is representative in this case.
So that would be the alternative.
Obviously for a smaller Octa setup it might be OK because the
configuration might be in a scope that one can understand on
his own sound for customers. We're talking about teams of
10/15/20 Octa, administrators in a single organization, in a
single tenant, managing 100,150 thousand users.
That configuration is insane in most cases.
And going and implementing a change directly in production,
for example, or a massive change in a in a preview tenant and
then reimplementing it in production, that's a very risky
move. By the way, you didn't lose me
on that NaCl sodium chloride, which I mean, when you figured
that out or that came up, you must have just like that must
have been quite the moment. Yeah, I remember.
Yeah, I don't want to blame for the for that name because we're
sitting in a room and we're saying, well, we need to have a
name for our language. What are we going to call it?
And then I was just playing with with all kind of letters so well
and it's still that's that's clever.
Very clever, very clever. So I think he got into why it's
problematic or risky to do things manually.
Is that what most organizations are doing that don't use salto?
Are they doing it manually or are they kind of rolling their
own solution? So typically we're seeing one of
three alternatives. The organizations are really
unaware of the risk and they just go and make changes
directly in production and they don't care.
In many cases, the bulk of the organizations that we're seeing,
they're very much aware of the risk and then they would
typically deal with it in a process kind of solution,
meaning that they will have lots of documentation would go and
implement those changes typically three times.
Typically it will be in a development environment, then in
testing environment or UAT, then in production environment.
And the way that those changes would work would be manual with.
Very careful documentation in spreadsheets, in tickets,
etcetera for these for these organizations, we both reduce
risk but also reduce a lot of manual work.
Meaning we have, we've seen, we see with sound for customers
processes that used to take them many days if not weeks are
reduced to minutes because there's no need to create a
documentation. That documentation is basically
the state of the system that we look at and you don't need to
reimplement those changes because just click a button and
deploy etcetera. The third type of organizations
are the ones who these are the most advanced.
These are companies that typically adopt for example
Terraform as a way to manage their Octa tenants and that it
deals with the bulk of the issues that I mentioned.
But it creates other challenges because for those of you are
familiar with Terraform, Terraform is a very popular open
source project and infrastructure for managing
typically infrastructure like AWS tenants etcetera.
The main challenge there is that they would need to go and create
HCL files or Terraform files that describe the configuration
that they would like to deploy. So typically Octa admins are
experts in Octa, meaning they really know the way around Octa
and the Octa UI and creating policies and they're experts in
identity and access management, etcetera.
Creating those directly in Terra forms HCL can be very
challenging and time consuming. So yeah, yeah, just staring.
And compare, I mean I I think that's the most common, right,
especially for Octa organizations that are
organizations that are smaller kind of have a limited budget,
limited scope of Okta. That's what they're doing to me.
It's extremely dangerous because you can miss type A
configuration. Other words you brought it over
but you left out a letter or you know how many times do we
misspell things in our day-to-day lives where you know
fortunately we have spell check there to to save us, right.
We we think there's only 1L in in in a word and there's really
two that that kind of thing and it can take you hours to find
out. So not only do you have to stare
and compare it correctly, but if you do your push and it's not
working now you've got to unroll it.
Well, what makes you think you are going to unroll it correctly
if you didn't roll it correctly. So I think it's extremely
dangerous, extremely risky, especially for major deployments
that are customer facing. It's just and seems like you
know from my experience in in managing web applications like
it's just you don't even have to be at that high of the level of
maturity to be driving automation like you wouldn't,
you know when you roll a jar file to a Java server, right,
you just drop the jar file in and if you have to unroll it,
you take it out and put the other one in or the old one in,
right? You don't, you know, go through
line by line of code and try and figure out the problem or try to
roll things that way. And to me it's kind of like that
that's this alternative way, the manual way, or writing your own.
The problem with that is like usually when you write code,
it's fit for purpose, but your purpose may change over time.
So, you know, you might have a creep away from the standard
baseline and it's not picking up certain configurations that Okta
added and you've been using in your sandbox environment, for
example. So those are some of the risks
that really jump out to me. But I also think just for
organizations that aren't already doing kind of a DevOps
approach and a CICD approach, that's the future, right?
And this is just another part of doing that.
Yeah, I I. Agree.
That's the future. And that's the future by the
way, not just for Okta, but for all of the different IT and
business applications that run your your companies.
And I'll give you an example for something that our customers
typically love is the ability to create a share responsibility
within a team. Because share responsibility is
a concept which is very much known when you develop code,
right. You would like the entire team
to be able to collaborate on the same on the stuff that we're
building and the common language that they have for that is code.
So for example one of the things that SALTO enables just by the
fact that we translate everything into a textual
representation into that NaCl file files is that you can
review other team members changes and you can approve them
and you can exact understand exactly what changes Jeff did
two weeks ago and what changes Jim did a week ago and you can
go and in Git we call the blame or praise.
We can either blame or praise Jeff for the changes that that
he did back then and creating that kind of visibility.
It's mind blowing that it's not it's it's nonexistent in those
type of applications. The fact that I can't that you
can't open, typically it's called a pull request, right?
A change request to the config and someone else can approve it
and only then it can be deployed.
Sounds like basic table stakes in critical systems under high
compliance requirements and there's these things do not
exist now. Moreover, as I mentioned,
because your companies are using so many different solutions, it
makes no sense to build a different solution for managing
each and every one of those systems.
Typically you would see an IM team, it's managing multiple
different systems, right. It's not, it's not just Octa.
In many cases you will also deal with Cell Point or with Entra or
with Splunk or with many Jams or with many other relevant systems
or with a or HR system or to push users etcetera.
And having streamlined consistent processes for
understanding that configuration, collaborating on
it, deploying on it is it's not even the future, it's the
present and CICD and DevOps in order to enable that, well these
are the principles that enable the software development world
in the last 20 years to support that kind of innovation that
we're seeing in the world today, right.
So these are like battle tested, proven ways of doing things.
So I think that we're going to see that every company is going
to start using these IDs when managing their business and IT
applications and that's why Salto is there, right.
So what is it that sets? Salto, apart from others, I
guess, in this space, right? I think one of the things that a
lot of IT people probably suffer from, and myself included, as we
get jaded, right? There's a lot of options out
there, I guess. Tell us why Salto is unique in
this field. Yeah, of course.
So the unique part in Salto is that first of all we're we're a
platform, meaning that we cater for many different applications.
It's not just Octa, it's not just Salesforce, it's not just
Zendesk, not just JIRA, it's all of them and many others.
We're adding support for a very large number of applications
this year and that we put the user experience off the admin in
the center, meaning that in some cases you would find solutions
that are relatively very technical.
They might be a good fit for a developer or for a very
sophisticated IT person, but eventually an admin that for
example with Octa lives and breathes.
I am an Octa, not necessarily code.
I think that we're basically the only solution that enables that
both a very admin friendly way of things while not compromising
at all all the important traits of source control and automation
and CICD et cetera. We make it accessible to them as
well as cross across many different applications.
We're not aware of anyone else's who's doing it today.
Well, that definitely. Puts the unique into it, don't
also doing it. How about can you share any
customer stories over examples because they think that's
another way that people can kind of start to understand how they
might leverage this and maybe some other ideas that others can
get from this. Any customer use cases or things
and feel free to share names or not, that's fine.
But maybe you can walk us through that.
Yeah, of course. I can share a few a few
different use cases and I I think that I I can share also a
few names. The first one is a very large
retailer with 10s of production tenants in the 30s and they used
to manage everything manually with spreadsheets.
So think about it, you have a production tenant, you have your
sandbox or preview that is tied to it in a 1:00 to 1:00.
They also had like a gold tenant where the that should have been
the gold standard. Now obviously over time all of
those 60 something different tenants that I just mentioned,
they drifted away, drifted apart.
So the actual relation between the configuration in any of
those environments became almost random.
So for them both rolling changes from that, let's say they would
like to roll a change from that golden image to all different
instances as well as adding a new tenant.
It was all huge projects and that's when they started working
with us and they reduced a configuration change that would
typically take them about a week to less than an hour by
automating everything with Salto and creating that kind of
visibility. Another interesting that's a a
public at a company, a Udemy I we we can share their name.
So Udemy, they strip when they got to us, the CIO, which is
very forward thinking and was thinking about their OPS all the
time and he came to us with a problem of how can he eliminate
the silos that he has across his org because Salesforce was being
managed in a certain way and that's what was being managed in
a different way. And then this was being managed
in a different way. And it each one of those suffer
from the same challenges and same problems but found
different solutions or no solutions at all.
So over there it was how can they get to a way that all of
the different business and IT applications are basically being
managed in the same way and that's how they're using US and
they're very happy customer in that sense.
And the large example, which might might sound a little bit
silly, but a European retailer, a very big European retailer.
They made a. Mistake and deleted very large
parts of their production configuration by mistake like
fat finger kind of mistake and it happened once.
Then they realized well they have to take care of proper
processes for managing their configurations both.
So first of all they will develop on a development
instance and development tenant and not directly in production,
so reduce that risk of a fat finger.
But also when things go South. So they could very easily roll
back very selectively those changes.
So that's when they onboarded the salto.
Oddly enough, they made the same mistake again after they
onboarded Salto, but then that fall back was immediate and they
undo. Now we need to remember that
it's a retailer with north of 100,000 employees, so the
implication of a bad change can be huge from a financial
perspective. Think about all of those
salaries that you pay to your employees who cannot log in into
your network or if you're serving customers and this is
somehow customer facing, that's a huge risk and that's a huge
impact. And for them it's it's a no
brainer. I saw three different examples I
think of what customers are using us for.
I think those are really. Helpful.
And you know, I'm browsing the website and kind of following
along here as you're kind of explaining this.
But I guess from a use case perspective, I think mostly
we've been talking about configuration backup.
Is that the right way to phrase it or is it CICD DevOps is a
little bit of both. Are there other use cases maybe
that we haven't talked about that you guys can help with?
No, so, so. Typically the main use case that
most of our customers come to us is around configuration
management and deployment of changes.
We view backup as like a private case of it, because eventually
when you when you backup, when you restore, you deploy from a
previous version, you can be as selective as you'd like about
it. And because we automatically
fetch the configuration every hour or every day, you get back
up as as part of the solution. Two other interesting use cases.
One of them is around compliance and showing traceability for
every change that you make. Because when you think about it,
once you move everything to a stream and process which is
backed by git and source control etcetera, you can very easily
now connect those changes to let's say a ticketing ServiceNow
or in Jira and show the approval and show everything that you
need to show to your auditor in case those systems are under
scope. And another one is around
monitoring of configuration changes.
Because there are many companies who came to us tell us, well
these are some very sensitive areas of our configuration.
We need to get alerted whenever anyone changes them.
Think for example about, I know security settings in the
NetSuite, you wouldn't like anyone to play with your
financial systems security settings.
So we can also automatically alert on those these types of
changes. All of these use cases,
eventually they boil down to the fact that we have visibility to
the entire configuration of those systems and we actually
understand that configuration in a way that enables us to
understand what changes over time to deploy changes to
understand dependencies. So what will break if we change
something and to roll back to restore etcetera.
It all boils down to death to the fact that we we can
understand all of that config it seems to.
Me, like salto wouldn't be that hard to start using.
In other words, you should if you're doing manual stair and
compare something like that, you should be able to start using
salto and once you build up the confidence level, start using it
right away. Am I missing something obvious?
What does the typical implementation look like?
No, no, you're. Not missing anything Jim, we're
actually, we have a free trial. You can just go to our website
and connect Salto to your systems and start using it.
And we saw cases where during that first month of a free trial
where the prospects already running 10s if not hundreds of
deployments during that month using SALTO.
Obviously if you'd like to go to like automation and CICD
etcetera, then you need to build some of this also in your own
systems, in your own processes. But just to get started, you
just connect it using very standard way to your systems and
you start it's that easy. What about the pricing?
Is expensive. We don't.
Think so. But the way that salt is priced
is according to the complexity of your configuration, meaning
that we connect to different systems, for example, to Octa,
to JIRA. And with Octa, we look at the
number of applications, number of groups, number of policies
that we manage and there's a price table accordingly.
And the reason that we do that is because we believe this is
very tightly tied to the value that we provide to our customers
because if that configuration is very complicated, very complex,
you get a lot of value by using salto if it is very simple, less
volume. So you said they?
Can go to the the salto dot IO slash IDAC and you know, get a
copy, play with it. Then if they say OK, there's
something I want, can they figure out their own price or
how do they contact somebody on the on the sales side of Salto
and they contact them back and figure that out, how does that
work they? Can do either.
They can either reach out or we will reach out.
In many cases also and because especially with larger companies
might need to walk out some some legal or whatever, we need to
walk out with them. But we also have a self-serve
and you can just wipe your credit card and then go from
there if that's something that you're interested at.
OK, that sounds. Pretty easy.
So one question that we want to ask is if you're the customer
and you are using salto, how do you measure your success?
Great question. So I think it is very similar to
like Dora metrics, if you're familiar with the way that dev
OPS and metrics typically work. But most of our customers, they
would like to have more deployment to production and the
scope of those deployments should be smaller.
So that's like typically the way that you would like to to
measure it. We also measure the success rate
of those deployments, meaning if they were successful or if you
needed to roll back. So the theory in dev OPS
typically is that you would like to have very rapid deployments,
meaning as many deployments as possible per day and to reduce
to with a minimal error rate. So that's typically what our
customers would see and we have customers that we're talking
about hundreds of deployments to a single system in a month
because the rate of changes is that high.
And that really that's what enables them to to become agile,
which is that's really what everyone is looking to do,
right, in order for to provide value to the business faster
that eventually all goes to their right.
All of us work in a business when the business to be
successful. For that we need to deliver
value as fast as we can and DevOps and tools like Salto is
what enables you us to do that. I have one more question for
you. And I want to know what is next
for Salto. We've talked about Okta a lot.
I'm hoping there are more identity platforms in the near
future, but what's next for Salto?
Yeah. So in Salto we're adding many
different applications all of the time and there are a few on
the identity domain that we're planning to add later this year,
nothing which is like final in terms of date etcetera.
But I think that you might you might see support from Salto for
example the Microsoft ecosystem in the Google ecosystem as well
as maybe products like sale point etcetera.
So because we've seen such an. Overwhelming demand from the
Octa community that we believe that those problems that we're
solving are extremely important in the identity ecosystem and
that's why we're trying to prioritize identity solutions as
some of the applications that we're adding later this year I
want to make. One statement.
So if there are people who are listening, who are product
managers or in an influential role, and they build identity
systems, make the APIs available for configuration management,
please. Period.
No exclamation. Point I'd like to 2nd that,
yeah, that's well said, Jim. That's what it comes down to.
Right. Yeah.
I I. I.
Agree. I agree.
Those days of closed systems are should be over.
So we were. Talking before we hit record
here and just kind of get into each other a little bit and this
has been a fascinating conversation.
So I hope people will go out and visit salto dot IO slash idac
but I want to ask a non a non identity question.
Jim, do you have anything else you want to get to before I do
that or are you good to go? No.
No, we can't. We can take it out.
This is a fantastic conversation.
I really enjoyed it. Thank you.
Yeah. We were talking about basketball
and you mentioned that you like to play and coach and I have a
couple of questions, 'cause I used to play no longer anymore.
I'm, I'm old and short and round like a basketball at this point,
but I used to play when I was younger.
So two questions for you. First is a player's question,
What's your go to scoring move, gotta score, games on the line,
how you get in that bucket? So.
As a player, I was playing until the end of high school.
I was always very aggressive and that's also what I typically
teach my kids. So I would grind my way into the
basket and like typically power moves because especially at
younger ages and if you're also non professional players tend to
be a little bit soft. So use your shoulder and you'll
get that bucket shoulders and. Butt, right?
Yeah. Jim, what's your go to scoring
move? I don't have one.
Don't. I do not.
I don't know. I'm terrible at basketball.
I I go up and I do layups and they, well, they used to be
automatic for me. Used to be able to hit 9 out of
10 layups for sure. Now it'd be like if it got one
out of 10, you're too. Small.
You can't. You can't lift the basketball up
correctly. All that weightlifting, maybe?
It's just I think I'm going to be able to jump and get to a
certain height and I can only jump like 6 inches and that's
the problem, OK. I've got some good.
Basketball stories though. All right.
I got a good basketball story. So this is my grandfather who is
was shorter than me by an inch. So he is 6/1.
I'm 62. He's 6/1.
He went to South Catholic High School in Philadelphia.
It's now called Bishop Newman and he was the center.
Get this 61. So this was you know in like the
early 1940s because as a 18 year old, he's over in Germany in
1943, so early 40s. And the man was the Center for
his high school team at six one. And he is in that high school's
sports Hall of Fame. He was a Letterman in baseball,
basketball and swimming, and he was just a superstar basketball
player. I think he was in the All Star
team for the city in 1942 or whatever.
It's pretty cool. So you.
Guys are tall. I'm not.
I'm 5-6 now and you know, when I was younger I was probably a
good solid 5, two or five, three.
But I I I mean, I used to play basketball all day long.
I mean, it was not uncommon for me to be playing games of 21
down on the playground or my backyard.
We actually had two hoops on my backyard.
So I was like legit playing all the time.
And so my scoring, I had two moves.
I mean, I could drive the lane and do those acrobatic, you
know, lay UPS, reverse lay UPS, all that good stuff.
Or the fadeaway jumper, 'cause I grew up in the era of Michael
Jordan and you know, we're talking mid 90s, early, early to
mid to late 90s. And that was just the move,
right? Unstoppable, unblockable.
Didn't matter how tall you were. I was shooting over you and that
that was my go to move was the was was really the the the the
fadeaway turn around jumper. That was my jam right there.
All right. Second question for you and
revolves around coaching. You coach Youths today, what's a
brilliant coaching move that you've made recently, maybe in a
game or a match or tournament or something like that, that you're
like, Oh yeah, that. I'm glad I did that.
Yeah. So and unfair advantage in many
cases with young kids is turning on and off full cold press and
because kids can get confused when you press them or also when
you don't press them. So in one of the games last
season, we basically turn it on and off all the time because if
you press all the time they get it and then etcetera.
And then the other team got so confused and we just kept on
stealing and lots of easy lay UPS.
So that's one thing that works well in young ages and another
thing is that we woke up on this a lot in practices we try not to
dribble at all. So just moving the ball all the
time even if it doesn't feel like there is a great purpose
because there there's no shot clock right when with kids.
So the difference because it needs to move all the time then
it creates opportunities. So just teach the kids to move
the ball all the time. So just dribbling, that's what
we're walking on. That's a that's a great.
Drill and I totally agree with the full court press because I
gotta tell you, as AI played in I guess would have been middle
school which would have been grades like 6-7, eight I think
if I remember. And full court press is a lot of
fun if you are the one doing the full court press.
It is not fun at that age when you are being full court press
and you're totally right. Like there's confusion and it's,
it seems like such a, you know an easy way to play defense.
Here's a brilliant move that my coach, coach Byrd, I think was
his name. I was probably in fourth or
fifth grade and if you think I'm short now, why was I short then?
And we're playing and I won the Mr. Hustle award for our team.
I just basically was like a gnat on these giants around me and
annoying and you know just in between their legs and just a a
real nuisance. We were not very good, I'll tell
you that right now we sucked. I don't think we won a game all
year. We were playing another team and
they put me in at center. So here I am giving up probably
a an easy 2 feet to the mother Center.
But we were so well trained on the basics and This is why I
mentioned the butt before boxing out, boxing out, boxing out,
boxing out. And so I could do that really
well. And I kept getting over the back
fouls, called on whoever was whoever is boxing out their
center fouls out, their backup center falls out, power forward
falls out. We end up in the third quarter
they had fouled out so many people that they only had three
players on the court for the last three minutes of the game.
And yes, we still lost. So that's how bad we were.
But I always, I always think back as like and I didn't really
kind of get at the times too young to kind of figure that
out. But what a brilliant move.
Take your shortest person, good fundamentals and just box them
out you you know. Use that button.
I'll use that. Well, there you go, See.
We're helping each other here. I think that's a good way to
probably end this episode, this conversation.
I want to thank you again for being part of this and kind of
sharing your wisdom around this, Gil.
We'll have links in our show notes that we can have people go
out and visit and you know, if they've got questions, they can
certainly reach out and connect with you on LinkedIn.
We'll have, you know, your LinkedIn profile as well in our
show notes. So visit salto dot IO slash
IDAC. They'll learn more.
Jim and I, we're on the web, idacpodcast.com and you can
always connect with us on Litter on on LinkedIn, if I could talk
correctly. And with that, we'll go ahead
and leave it for this week. Thank you again, Gil.
Thank you, Jim. And we'll talk with everyone in
the next one you've been. Listening to Identity at the
Center. We hope you've enjoyed the show.
Make sure to like, rate and review and we'll be back soon.
But in the meantime, hit the website at
identity@thecenter.com and find us on Twitter at IDAC Podcast.
See you next time on Identity at the Center.