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