Narrator: You're listening to the humans of DevOps podcast, a
podcast focused on advancing the humans of DevOps through skills,
knowledge, ideas and learning, or the SKIL framework.
Rami: I don't think there's a skill. A DevOps is usually a
DevOps engineer is a DevOps engineer and I'm dealing with
AWS lambda. I have have an expertise. I live in the DevOps
group, but I have expertise. It's very similar here.
Eveline Oehrlich: Hello, my name is Eveline Oehrlich . Welcome to
the humans of DevOps podcast today, excited to be with a very
special guest Rami Tamir on the topic, breaking down silos,
which I think is a very fantastic topic to talk through,
we'll travel through a variety of topics. So Rami thanks for
being here. I am going to do a little bit of reading to our
audience about your background, but I will turn it also to you
later on, because there is maybe some holes you want to fill in.
So first of all Rami is the co founder and CEO for Salto, Salto
was founded in 2019. In 2021, I believe Salto was listed as one
of the top 10 Hottest DevOps companies, the word Salto, I can
say that because I speak a little Italian means jump, .
Right. That's a great name for a company. So congratulations.
Let's talk a little bit more about Rami what he has done so
he has 25 plus years of experience in management of
multidisciplinary software development, as an entrepreneur
he has a ton of proven track records on different technology
companies. He was co founder of Pentacom, which was acquired by
Cisco quantum run it or the kernel based virtual Yeah,
camera net based virtual machines acquired by Red Hat and
Ravello systems acquired by Oracle. There is a trend there
in naming and we'll quiz you on that and you are also an angel
investment investors in the early stage startup companies in
tech industries and serves on many boards for them, you BSWECS
so kind of similar to me, except I don't have the W E. I have the
CSCIS in electrical engineering from Technion and an MBA from
Northwestern University in Tel Aviv University. Welcome, Rami.
Anything I missed on your background? That you want to
share?
Rami: First of all, thanks for having me. No, I think it's,
it's pretty extensive. So yeah, we can move on from there.
Eveline Oehrlich: Excellent. So Salto automates configuration of
popular enterprise SaaS applications. So we're talking
Salesforce, NetSuite, Marketo, and many others. And for me, as
a DevOps person, sharing with our audiences uses, and
leverages a variety of DevOps principles, really to manage
configurations. So a lot of codeless, low code work to help
Biz Ops to be faster, better, more proactive, etc, etc. So
give us your definition and what it is really that Salto actually
solves?
Rami: It's pretty simple, actually. When you look at what
companies are doing today to manage their pre called business
operation, we can elaborate on that later. It's done using a
cluster of cloud applications, the likes of Salesforce and
NetSuite and JIRA, Zendesk, etc, etc. Typical company will run
10s, and hundreds of those. And essentially, when you get those
platform, you sign up to this platform, you get data skin, you
get a database, and you have to start, morphing adapts to a
business. And that work is done using no code. way of doing
things, it doesn't have code it they're coding for, to some
extent, but mostly it's a no code thing. So when you look at
the day to day of people doing that, when when you start a
company, and I've done that a few times, as you mentioned,
it's simple. You basically bring on a contractor and you do some
work and it's nice, you have maybe one admin, things are
good. When the business starts to pick up, it becomes really
complex, because these are mission critical applications.
Because if your sales were stopped if your NetSuite stops
if any of those platforms stop, you have a problem. The business
slowed down and When you look at the way, no code platforms are
being developed, it's essentially an ad hoc process
done differently from company to another very error prone very
manual relies on tribal knowledge, meaning they're not,
you know, this guy know that that person knows something
else. And when when it becomes complex, when the business picks
up, and it doesn't take a lot of time, things start to break. In
the basic things, I'll give you three examples, what is
implemented, in order to understand what is implemented
in Salesforce, you have to go through a click and point point
and click marathon to understand what is that? How do you design
review. So I have a change I want to make. What is the
language that I stick to my peer in order to show them what I'm
doing, like the day to day thing in the development process? How
do I revert to change? How do I kind of share the knowledge with
some someone else, et cetera, et cetera. And all of all of these
are things that were sold in the last two to three decades very
well in the software delivery and software development world.
So what we're trying to do as a company is very simple. Trying
to see if we can coordinate to see if you can call, we try to
copy concepts from the DevOps software delivery world in
there. And the first step of doing that is create a common
language. Because as I said before, there is no language to
speak, you know, between the two peers working on the same
project. So what we what we did is we created an open source
project, it's called Saudi, you can find it on GitHub, that,
essentially in a very basic level, connects to those
platforms, using their API, their open API's, and extract
the schema or the metadata configuration of the
configuration. And then we form it formatted in what we call
knuckle, which stands for if you want not another configuration
language, or the chemical sign for salts, also a lot of geeky
references. But this is a glorified JSON. That allows you
to start doing things in a code kind of way, this is what we
call it. This is why we call it companies code. Once you have
textual representation or coder presentation on those platforms,
you can start doing software like things. I mean, you can put
it in Git, you can create versions, you can revert
changes, you can share the knowledge with someone else, you
can start explore the other side of the of the house, if you
will. And that's what we essentially do, obviously, we go
way beyond that. But that's the basic basic, saying, having said
all that, we do not expect admins of this platform to write
code. This is not what we're doing. We think no code is a
great thing, is a great thing. It's an amazing thing. What
we're trying to do is once you've done your feature, using
your platform, Salesforce, whatever platform, you can
extract that configuration, we call it discovery of fetch, and
you have only to change it codified. And once you have your
changes codified, you can start doing all the process that we
used to this is kind of a very high level description of what
we do.
Eveline Oehrlich: So that makes me think of a term when I was at
Forrester Research, we did a lot of let's say, listening in, of
course, to what Gartner had to say and they they face this
term, citizen developer, right, and ServiceNow picked up on that
quite a bit. So what I heard is, this really enables citizen
developers or business technologists that was our term
at Forrester to do things themselves without inhibiting or
bringing in a developer and a large team to actually make
whatever they need to do in terms of business processes, in
terms of connections, integrations, logics, etc, etc.
Right? Is that correct?
Rami: There's two sides to what you say here, I'll break it
down. So the local platforms allow any citizen developer to
do that work. The problem is, what happens when these changes
start to accumulate. And you want to have something that is
efficient, that doesn't have a technical debt that makes sense
that connect between the other stimulus system to another
because essentially, all of this system tried to create one
solution. And there will we come in, we'd like to solve these
people create solutions. And when you create a solution,
you're essentially an engineer. You're not a software developer,
per se, because you're not using software tools or code. But you
are an engineer, we try to call them business engineers, because
these are people who are getting very, very complex tasks, very
complex task similar to software developer development. They're
handling mission critical application, but at the end of
the day, they don't have enough tools, processes methodology to
solve those problems. If you look at what was done again, in
the software delivery software development world in the last
three decades is infrastructure and processes and know how to
solve very complex problem is a large team with the
understanding that you will make mistake mistakes, and you have
to solve them. What is the process of evolutionary getting
to a better state, they don't have that in either side, this
is what we're trying to solve. We call them business engineers,
because we feel they are the perfect line between engineers
and people who knows the business or know the business.
So I think that's a good term. And we're trying to give them
the right tools, methodologies, and way to work in a in a, in a
sane way. Because doing it manually. It's, it's a recipe
for failure.
Eveline Oehrlich: So what is it that business engineers do, it
is actually Biz Ops, right? That's the term which I am
actually an INO ops, or an IT ops. So what I do in IT ops is
what these folks do in business. Right? Help me and our listeners
to compare and contrast Biz Ops, and DevOps.
Rami: Yeah, DevOps is a kind of term that has a long span,
meaning it's, it's it started from the, you know, the
amalgamation of development and operations. But today, it's
almost like it's a style, it's a movement, it's, it's a way of
doing things, it's an understanding that there's there
is a way of actually creating those processes, infrastructure
and everything. Biz Ops is today's just the term, there's
not a lot behind it, this is business applications. And there
are different within Biz Ops, you get a lot of force few items
like revenue operations that are taken further, etc. But by and
large, these are siloed solutions. So a business
operation, person or business engineer, should be able to
develop a solution on its on its platform and its solution. And
to bring it to production. Using a growing team, with the
understanding that people will break things, you need to be
able to test it. And we will need to automate all the way to
take out the human factor the human error factor all the way,
all the way to production. And they're doing it on business
applications, and mostly doing it using no code. This is sort
of the realm of what what we're talking about, I'm talking
about. But we believe in soldering, what we're trying to
push is the differences or they know that the cutting between
business a business operation, and DevOps will start to blur.
Because the way we look at things, once you describe it in
code, and you want to automate it, and you can use your circle,
ci or you can use it to have actions to actually move things
around. So you rely on the traditional DevOps people to do
that. You want to do testing, you can start using their tools
as well. So it will start to blur and you will start to see,
you know, we already starting service some customers, places
where your TerraForm is actually worked with your Sato
representation. And once you have it in code, there's a lot
of tools and architectures and processes to actually bring
everything together.
Narrator: Are you looking to get DevOps certified? Demonstrate
your DevOps knowledge and advance your career with a
certification from DevOps Institute? get certified in
DevOps leader, SRE or dev SEC ops, just to name a few. Learn
anywhere, anytime. The choice is yours. Choose get certified
through our vast partner network self study programs, or our new
skillup elearning videos. The exams are developed in
collaboration with industry thought leaders, and subject
matter experts in the DevOps space. Learn more at DevOps
institute.com/certifications.
Eveline Oehrlich: Great, that that made perfect sense to me. I
think I liked that the conversation where it's going
now, this might be a little bit of a silly question, but I will
asked it anyway. Is, in your mind, low code, no code a threat
to the developer?
Rami: No, it's just it's, I think about it is like, it's
like Python is not a threat to JavaScript. It's just another
way of creating solutions. And the problem with the no code is
essentially in the name, you don't have the code. And the
code is an artifact that beyond implementing things gives you
structure. Your way to follow up on changes give you a way to
it's a language that people can share. In a way if you're
looking for analogies, like sheet music, if you have an
orchestra and you want to make sure that people are talking
about the same thing, give them sheet music. If you have two
people, you know, jamming together you don't have to have
that But if you want to have a very effective way, you have to
have a language. So with code, it's easy. If you're using
Python, everybody can look at Python go to get, look at what's
happening, changes, Revert things can make themselves
acquainted with what's going on. And you know, you increase the
level of knowledge, knowledge, longer learned tribal knowledge.
When you go to the no code, part of the world, it's very much
different because you have no language. And this, what we're
trying to solve the basic thing that we're trying to solve it,
let's give them a language that they can start sharing, let's
give them sheet music. And they can start, you know, playing
together as no larger teams.
Eveline Oehrlich: Yeah, makes sense. So as for DevOps
Institute, skills and reskilling and upskilling, of course, is
essential. There's a lot of folks right now, who are as we
know, either call it the great reshuffle or call it the great
resignation, I rather call it the great shuffle because I
think people are starting to change positions for whatever
reasons. So if I wanted to be a from a DevOps engineer, if I
wanted to become a biz ops, or business engineer, what kind of
skills does this individual need? What would you recommend
that person to go look at?
Rami: It's, so I don't think there's a skill, a DevOps skill,
usually a DevOps engineer will be I'm a DevOps engineer, and
I'm dealing with AWS, lambda, or I have have an expertise,
categorized in our I live in the DevOps group. But I have
expertise, it's very similar here. Because my expertise could
be I'm a Salesforce engineer. So I know how to handle Salesforce,
the processes and tools I'm using is the key into DevOps. So
once I'm done doing my stuff, I kind of I fetch them, as I
described before, I create a PR pull request, and from there on,
the automation will take care of it. But my expertise is geared
towards more mature system or what I'm trying to do this way.
I'm a Business engineer. So the DevOps part of things is about
how the organization or create the processes, tools and
infrastructure, my expertise relies on the on what I'm doing
Eveline Oehrlich: A little bit of a side question makes me
the day to day.
think of, you know, companies like SAP and the none. Well,
they're, as we know, they're shifting to the cloud, as well,
but does Salto also address those type of business
applications, which are non SAS.
Rami: We have, we have customer requesting there. We're still a
startup, it's hard for us. To expand beyond. I'll tell you
this. We are we are addressing right now cloud and the fast
moving applications, meaning the cloud ones, and the ones that
have API, we will at some point go to on prem as well, if the
market will require that what we have is a very long list of
customer requirements. It's pretty support the explicit for
that and we just go, you know, the number of drivers, but
there's no limitation. Obviously, we can go on prem,
it's just a matter of what do we prioritize right now in what you
know, what's the good one?
Eveline Oehrlich: Yeah, yeah, that was a little bit of my
industry analysts brain showing through. So I apologize. That
was my curiosity. And so to go back to the cause of our
podcast, lots and lots and lots of silos exist, right? And
that's, I think, thats one of the biggest challenges. Now I
listen to a presentation at an event where a gentleman was
saying that organizations should not eliminate silos, they should
actually continue their silos. Maybe it's a bit of a
nomenclature, right? I think maybe he meant to say, there
should be experts, but I thought he said silos. So I wanted to
ask you, what are your thoughts on silos in organizations. What
do you see within your customers? I read, for example,
the company case study you guys had on your website on Monday? I
think it's monday.com. Right, fairly successful. No longer a
startup. So they obviously, have hired a lot of generalists, and
they have a really great success story. So for those who are
listening in, go look at that case study, but give us your
thoughts on silos.
Rami: Yeah, so that is usually the negative term. I'm trying to
think of an example where silos actually looked at this as a
positive term. If you know, you should have expertise expertise
does not mean silo. If you have silos, it means that you have
overhead because you have to recreate everything within each
silo. It means that you have to have a very strict way of
handing over things from silo to silo because essentially this,
this is one organization and you have to have NetSuite and needs
to work with Salesforce needs to work with JIRA. So you have to
create that you have different cadence between the silos, which
means that if one silo decides to release one every six months
and another silos decided to release every week, you have a
problem, because there's no way of doing that. Silos create a
situation in which you have different quality requirements
between this. There's no way of maintaining silos for long term,
unless you really, really strict and you're really, really big
company willing to spend a lot of money for no reason. If you
take a look at what happened, it again, we're trying to mimic in
a way the it turning into DevOps, it used to be so used to
have in the past, and I used to I live there, you had r&d
organization, you had it, you finished development, you tested
it, you moved it to it. And every six months, if you're
really good, or every year, you could have another release. That
was sort of a silo and we had a very strict policy on how things
move. And it was a pain from you know, we moved from release one
every year. Now in Saudi we're doing a few weeks. And it's not,
because we're smarter, it's not because we no better people,
it's because we broke the silos, we have better tools
infrastructure in order to do that. So I think the goal for
each organization should be to break as many silos you can kind
of have one organization for automation, one organization for
testing, if you need that one organization for that, take care
of gate or whatever, and have the experts deal with what
they're experts about. If I have an expert on Salesforce, they
don't need to understand, get only those 10 Release
Management, they need to focus on Salesforce. If you have the
right infrastructure for that, once they're done, they move it
on, someone else would take care of that, or the automatic
process will take care of that. I don't see any value in silos
to be honest. And I'm trying to think of example, while I'm
talking I don't have a good example of subtle, positive
silence.
Eveline Oehrlich: Yeah, I was. I was with my colleague, and we
were looking at each other. Absolutely disagreeing with a
gentleman because I absolutely agree with you. There is just a
lot of I call it a WOT, a waste of time in organizations who
have built these very, very entrenched silo teams. And
there's also this NIH right, not invented here, or that finger
pointing with, again, with DevOps, where we have blameless
and kind of a safety culture. That's starting to go away, we
see an increase in collaboration and all of that is wonderful.
All right. Wow. Why is the clock always running so fast when you
have a good conversation? And when you have a bad one it is
like it just doesn't move? All right, we have two more
questions and then I'll let you go back to your day job, of
course. So if you think about 2023, and here, anything goes,
can you pick your favorite? What question are you asking yourself
about 2023?
Rami: Yeah, there's, you know, beyond the macroeconomic
climate, it's hard. It's, I can tell you that I can shed a light
on the, you know, the startup view on that, because we are
startup that grows. And when you're growing, you trying to
adjust you always trying to adjust you look, if you get
customer feedback, let's assume you lose a customer trying to
understand why if you adjust, that's what you're doing, you
kind of read the market and adjust that. But you know how to
do this is what startups are good at. We can move really
fast. The problem with the climate right now that they've
cast a long shadow, and everything. So you lost a
customer, you're not really sure if you lost them because of the
product, or you lost it because they lost the budget. It's not
it's not always clear. So it slows things down. Everything
becomes slower in your ability to react is it's more
problematic when you have to run few options like brand
predictions in parallel in order to understand things. And that
usually kind of slows things down this. I think this is the
biggest thing I'm trying to understand right now. Trying to
sort of crystal ball. When this you know, the derivative will
become positive again so we can plan our budgets and everything
towards that. I think this is the biggest thing for me to 23
How do I how do we position ourselves correctly to still
evolve? While understanding you know the effect of this
microclimate? I think this is the biggest thing on my mind.
Eveline Oehrlich: Yeah, I think you're speaking out of the heart
of many leaders in and across the globe and in different
verticals, software companies, NAND software, etc, etc.
Fantastic. All right, I have one more question unrelated to
Salto. What's your favorite thing to do on the weekend?
Rami: Well, I like riding motorcycles. Strangely enough.
Yeah.
Eveline Oehrlich: We should meet up somewhere. I used to actually
do motocross many, many years ago. I don't do that today
anymore. It's a little too dangerous. But what do you ride?
What machine do you have?
Rami: So I am doing track days. I have an affiliate obviously
for now. And I have an off road one. I broke, I broke many
bones. I have like, the amount of scars I have it. It's, it's
amazing. So I like that. And, um, because of what you said,
because of the risk. I'm starting to think about maybe
bicycle, it's something I need to get back to as well. Because
the you know, the tools is, is fun. So you need to figure out a
way to break loose bones. So that's my focus right now.
Eveline Oehrlich: Excellent. Well, this has been a great
conversation. I really much appreciate it. Our listeners are
appreciating it. For those of you who want to know more Salto
can be found much more information. Rami, thank you for
bringing wisdom to us. Great, great conversation. Next time
maybe we do a little motorcycle podcast on how to hurt ourselves
less or maybe should the conversation to the biking. I
appreciate it.
Rami: That'll be amazing. That's much more interesting.
Motorcycles are more interesting. Yeah. So if you can
Eveline Oehrlich: That sounds great. Let's think about that.
do that, that'd be great.
Super, thank you so much. Have a great day and thank you again
for everybody listening in today, Eveline Oehrlich, Humans
of DevOps podcast at the DevOps Institute with Rami Tamir. from
Salto. Thank you. Bye. Thank you.
Narrator: Thanks for listening to this episode of the humans of
DevOps podcast. Don't forget to join our global community to get
access to even more great resources like this. Until next
time, remember, you are part of something bigger than yourself.
You belong