FinOps in Action

Ben de Mora: we have to be really careful

when we're applying governance because not enough governance results in chaos. Right.

But

too much governance

results in chaos that's invisible that we have to go find elsewhere. music is very, very important.

You have to do something That That doesn't involve looking at a screen your entire life, right? You've gotta walk away from it and do something with your hands and make

something beautiful.

Alon Arvatz: Hello

everyone and

welcome to.

another episode of finops in Action

Today,

I'm particularly excited about this episode because our guest today has a very, very diverse background.

He was actually a security engineer.

He did integrity testing. He was into data center engineering. He built data private cloud environment.

He let him create consultancy services. He supported finops practitioners from the vendor side. He was a finops instructor and up until recently, he led finops at GitLab. I'm happy to welcome Ben De Mora.

Ben, how you doing?

Ben de Mora: Uh, it's good. It's a good Monday morning. Good morning.

Alon Arvatz: it is.

It is And I would like to hear from you, what is the one thing you got wrong when you started your finops career? career?

Ben de Mora: into it. Yeah. Um, what did I get wrong when I started this? I believed, I believed that tooling would save us all. I believed that technology was the answer,

right, and that all you had to do was get the right kind of dashboard and suddenly. Magic would happen. Everybody would do what they needed to

do, to do and, and fix all the problems.

It was just a technology problem. Um, and I tried really, really hard, um, for a while to, uh, to, to use that approach. Um, didn't work, didn't understand why it didn't work, and had to sort of sit back and think about it and go, so what's actually causing the problem? Uh, what's causing the problem is not technology, it's people using technology, right?

So that's what I got wrong. A lot of effort was, uh, was

burned on, on believing that technology would be the solution. It's important, but it's not the answer.

Alon Arvatz: and did that change how you perceived the role of finops or the skills you need as a ops practitioner?

Ben de Mora: Yeah, I mean, when I started doing it. For me it was, this is, this is another engineering

challenge, right? This is, this is, this is another technical challenge. I'll solve this. This is fine. Um, you know, I, I, 20 odd

years of doing this other stuff, it's fine. I, I can figure this out. but actually it's, That's like 5% of the total picture, right? if that, um, and actually most of it is around. Business, it's around people. It's around enablement and an education, uh, and support and, and

the right kind of, of the right kind, right kind of conversations to be happening.

Alon Arvatz: That's awesome.

But I know from our previous conversations, uh, Ben, that you also believe that technology can prevent some of the mistakes that people can make.

Ben de Mora: yeah, I mean, You, you can't fix what you can't see. Right.

And you can't understand it if it's too complex. So even if you can see it, if it hasn't been simplified so that somebody can what I call like my ten second test, right? You look at it, 10 seconds should be able to make sense if it, if it takes you half a day to figure it out. Ain't gonna work, nobody's gonna use that. Right? So the data in its like raw, naked form is, is not workable from, from the providers, from the, in the data file. So you need to get to the point whereby, okay, you've got clear insights and clear data, which prompt action, right. Which, which trigger people realizing and understanding. But no, you're right. Um, I mean. You can't drive a car if you dunno how to drive, but you can't drive a car if you don't have a car. You know what I mean?

So you need the, you need the, the technical solution as well as the knowledge of how to operate it and work with it.

Alon Arvatz: And I would actually love to

double click on something you mentioned, and I find it very fascinating, like this ten second rule. This is basically a product management or user experience,

uh,

principle

that you as a Enos person feel like you need to implement.

Uh, do you see.

Like Enos person is a type of, uh, product, uh, manager or someone that needs to have like user experience skills?

Ben de Mora: definitely. In fact, quite a few people that I know of, or one person in particular based in the uk uh, in the UK I'm thinking of now, they refer to themselves as print finops product owners or finops product managers. Finops is a product concept, right? Um. I mean, think about it. We have, we have customers, we have users as finops practitioners. Our customers are our business. Right? Um, and our user experience of finops, if you like, is the enablement we give them, the simplification we give them. So yes, finops as a, as a thing, as a product delivered to the business that needs to improve its efficiency. Um, and if we think about it in that way, then it's very important that we get the, the whole blend, right? We get not just the visibility, but also the, the, the full loop back, right? The complete en enablement piece

so that we can use the visibility to improve the actions and the initial decision conditions. So, Yeah.

Alon Arvatz: And

did you have the chance to actually do things like a user testing, for example, like building a dashboard, going in front of a few engineers, show them the dashboard, see if the ten second rule works, and then based on that, you know, build at the next dashboard or improve its current dashboard.

Ben de Mora: Yeah, ab, absolutely. So that, that's, that's a really important thing, right? Never, ever, ever create visibility and then just send it off into the wild to see what happens, right? Like throw it over the fence, you know what I mean? Um, no, it's gotta be a collaborative thing, right? First principle of finops is everybody teams need to collaborate. And the finops team is not, is is the most important collaborator there, right? Um, so when we are building our visibility, we're doing our views and developing our understanding, not just of like where the waste is and what the spend is, but like what led to it? What were the processes that took us there? Um, when we're doing that kind of, that kind of work, we have to do it in really close collaboration with the, with the end user, the people who are gonna be consuming that insight. Um, and then like the, the next level up beyond that. once they've seen what you can do to build with them and for them, how long does it take them to build their next views?

How long does it take? Once they understand how to, okay, I, I see this and I want some more knowledge about that area, how do I then get to a point where I can explode that out and see what's, what's under that rock? Um, so that's the next question. It's like, okay, great. So we understand the first, first point. How do we get deeper and how quickly can they get to an answer there? Yeah. Because every answer gives you, gives you 10 more questions.

So that's not scalable in an organization where you have a, a small finops team, they're usually small and overworked.

Um, right. We all

know that. Um,

well, you've got a small finops team.

Okay. If they're the ones making all the dashboards,

that's just not scalable. Right. So how quickly can other

people do that kind of thing?

Alon Arvatz: Oh, that's really fascinating

and I'm telling you, it's the first time I hear about finops as a product manager or someone needs to do product management. And I'm going to completely geek out on that because I come from a product management background

and ask you,

You

know, when you think about product management, one of the uh, key things you wanna do is basically track the usage.

Of your users. Now, that is something that really requires some, some advanced tooling to monitor how

and

how much people use

your solution. But I wonder if you were able to find the solution to actually track the usage

of the dashboards or the data you, uh, surface to your,

uh, organization.

Ben de Mora: Yeah, so there's, there's three ways I've done that in the past. One of them is just login count and duration, right? Uh, how often did my engineering team leads or engineers go log into any solution? How long were they logged in for? Right? That's often you can get that kind of insight from a lot of third party solutions. Um, and then the, the second way is anecdotally just ask them. Have you, you know, have you, have you created any good views? Have you got any good ideas? Have you, have you shared any good insights that you've created with other teams?

'cause it might be useful. And looking for that organic of expansion of, of visibility and understanding as a second way. And the third way is, how's the business doing? Right? How are we actually getting on? 'cause if we are not looking at the data, we're not operating on our insights and we're not building on that. Chances are we're still wasting money. Right? So you, the three diagnostic sort of pieces I look at, are they are, are they logging in? Are they sharing stuff and creating stuff, right? And like rate of new insights being, create rate of new visibility, insights being created or whatever. then thirdly, like, we actually improving? 'cause if we, we aren't improving,

either, no one's looking or what we're looking

at isn't helping us.

Alon Arvatz: Yeah.

Ben de Mora: or, or a mix of the two.

Alon Arvatz: absolutely.

Listen, uh, Ben, we're almost 10 minutes into the session and I already learned so much. Um, and I wanna ask another follow up question.

Obviously

user

experience is very important for adoption.

I think you mentioned it, but do you feel like it's also important for scale in organizations that have multiple business units or engineering groups?

Ben de Mora: Yeah, absolutely. Right. Um, so one of the, there's, there's a really

cool, um, piece of, piece of stuff on the finops Foundation website about champions programs.

Um,

that is the most effective scale out approach, right? Um, being able to create like a, a, a broader community and this esprit de corps of. People who know about this stuff are enabled, who are empowered, maybe they've got the, got some fur further training and education as well who have the right links and connections in to Also, sort of help the finops team reach out to a wider audience, but also aggregate understandings and feedback from the wider business. If you've got a finops team of

three people and you've got two and a half thousand engineers. That has, that's a

lot of one-to-ones, right? Um, not many people

can cope with that number of one-to-ones, so you

need to sort of stage it out and

scale it out.

Um, but Yeah.

one of the biggest mistakes I've seen businesses make in terms of scalability is continuing to believe that all the finops stuff is done by the finops team, like all two of them, or three of them, or whatever it

is. Um, and straight away you create a bottleneck and you, you can't scale from that.

So

really, um, there's a

term that, um, that Carlo Wesco, Wesco, Philip, Phil Ell and myself sort of started talking about, um, when I was, when I was aptio. Talking about federated finops, Have you heard that phrase? Federated finops is like, yeah. If you think about a federated model, you have to, you have to create a central point of overall sort of oversight and connection, but you really need to create pockets of finops practice that are all

connected in and interlinked as you scale out, right? Um,

so yeah, a hundred thousand people business is not gonna manage to do finops with three people.

Alon Arvatz: Absolutely. And

basically these, uh, champions, they are your ambassadors. They're the one who help you inject the principles,

the idea

into the organization.

Do you have some tips on how to identify a potential champion?

Ben de Mora: Yeah. Um, uh, well, first of all, first of all, make sure they're not all the same background.

champion group are like all fp and a folk or all engineers, then those are really the only conversations that are probably gonna happen, right? So look in weird places, look for marketing.

Marketing teams make great champions 'cause they're used to communicating out, right? Um, your education teams, uh, your finance, but also your procurement. Look in your business for people who have an interest in this space. who like talking to people. Yeah. Um, your champions are gonna have to have a lot of conversations.

So if that stresses people out, it's probably not for them. But, um, yeah, it's really important to find people wherever you want the, the conversations to happen. So I guess you kind of, if you're building a Champions network and champions program, go on a bit of a road show, meet people, talk to people, and also there's actually, there's a page. On the Foundation website talks about how to

create a champions program. Uh, and it works and it's good. I've used it, um, quite a bit actually.

Alon Arvatz: Absolutely, and I can tell you that from engineer's perspective, I think you need to identify the people that that really care about efficiency. Like those who cannot sleep at night when they know their code or infra infrastructure are running inefficient, like they feel it's bad engineering. I need to do something about it.

I can tell you that my co-founder, Gaal

is one of those people.

yeah,

Ben de Mora: is one of those people. She is, she's, she's an amazing software developer, and it is,

like, if it is if it's bad code, it's a problem. You know what I mean?

Alon Arvatz: exactly. So I think, you know, I would also say that it's very hard to find engineers that really care about.

Saving money purely.

You know, I think that looking for these people will make it very, very hard for you to find

the relevant person. But if you focus on the person that actually wants to do

good engineering and he cares about it, and he can very quickly understand why inefficient infrastructure and architecture

is better engineering,

I think this is the person you want in your program.

Ben de Mora: Yeah, definitely. The, the other thing that is really emotive and really effective in getting people to be engaged is introducing different metrics.

So for example, uh, sustainability data, right? So CO2 E, uh, water consumption, power consumption, whatever data you can get to it to put side by side right. Is really, really effective. Yeah. Um, as alongside the engineering excellence piece, which is very, very effective. Right. As well, but. You are gonna co, you're gonna cover a lot of different bases if you provide things like efficiency, like scalability, like cloud native capabilities, uh, alongside things like sustainability and other things as well.

So, there's no one answer that engages. It's, it's a lot of things. Um, one of the most important things, we've not actually touched on this yet, but one of the most important things that gets engineers engaged is executive sponsorship. Leadership sponsorship because, um, if you think about it, right, uh, one of the, one of the, one of the top issues that we see being reported in the state of finops is getting engineers to take action on finops specifically, right? Engineers are taking action all of the time. I've never met an engineering team that isn't 110% capacity planned, right? They're all up to their eyeballs in it, but what they get prioritized on is what matters and. the business leadership isn't bought into getting finops actions to happen, instead they're saying, I want my new release next week and I want whatever else done instead this week. if the priority is build, build, build instead of let's clean ourselves up and make sure that we've got a good efficient environment, then that's what, that's what will happen. Right. And actually, if you are pushing a different narrative to the one that the executive is driving, you will lose. As a finops person because you're not an executive probably. Right. So, um, Yeah,

it's really important. I mean, 49% of, uh, of finops practices say that they need executive

buy-in. That translates to actions happening, um, as a like last year's state of finops. So,

um, yeah, without

that doesn't matter how

happy your engineers are to do the work 'cause they've got prioritize prioritizations elsewhere.

Alon Arvatz: absolutely. Absolutely. And we actually came here very with a very nice formula. On what motivates engineers, and we mentioned seeing inefficiency as bad engineering. We mentioned mentioned sustainability and we mentioned executive buy-in. That's actually a very interesting formula and I actually wanna take you back a bit to the sustainability piece

and I want to get an honest answer from you.

did

did you, did you see positive results?

Uh, when embedding the sustainability metrics, meaning it actually got engineers more motivated or engineers celebrating their sustainability impact,

Ben de Mora: massive? Yeah. The, the difference in feedback that you get. When you show someone actual, well, not actual, but um, relative data, when you show

somebody any data that shows

that they're making a positive impact on the planet, they care, they really care.

And that a lot more focus is put into, into doing things. Um, there is a caveat is that sometimes the sustainability improvement me metrics and the cost improvement metrics don't. together, they don't actually support each other, right? For example, um, different regions are priced differently, right?

Do you know where the ch do you know which ones the cheapest regions are? They're the most polluting regions.

Alon Arvatz: Oh

Ben de Mora: So if you go

to, um, if you go deploy your cloud environment in a cheap, cheap region and you save however much money,

you're actually, you might be quadrupling or more your carbon emissions.

Alon Arvatz: wow.

Ben de Mora: So

sometimes they don't actually tally

against each other, and then it becomes a balancing act.

Then it becomes a conscious, conscious balancing act of what, where you wanna put your focus, but then

you can't make that choice if you don't have

the clear data to be able to make that choice. Right. You are, you're you're doing it

blindly.

Alon Arvatz: that's fascinating. Wow. I've never seen thought

about it.

Ben de Mora: Another question. Uh, how much carbon emissions does a savings plan reduce reduce for you?

Alon Arvatz: Zero.

Ben de Mora: Right? And actually almost is almost, counterproductive because if you commit to a certain level of usage, right, you're paying for that usage, whether you use it or not, which means if you don't use it, if you un, if you over commit. Um, the cloud provider's probably just gonna leave that resource online if, I mean, I don't know how they operate. Right. But they, they might leave that resource online if, 'cause it's paid for,

at which point, you know, it's, it's harmful. So there's a

lot of trade offs and balancing acts to make

in that, in that conversation around sustainability versus cost.

Alon Arvatz: Yeah.

But you're saying something very interesting. Commitment is counters. Sustainability

Ben de Mora: It might be right. It could be potentially.

Alon Arvatz: if you don't use it, uh, to the full extent.

Could be.

Wow. That's amazing.

And Ben, listen, before running out of time, there is one big topic that I know.

You care much about and you have a lot of experience with, and I definitely wanna touch,

and

that's governance.

Ben de Mora: So we we're talking a lot at the moment about, uh, about the exit point of the, of the production line, aren't we?

Right? We're talking about like, you know, do the wheels stay on the car when it comes at the factory, right. The exit point. Um, actually, I mean, let's, why don't we just use that analogy? Yeah. If you do a really, really bad design for a car the first place, if you, your schematics are just terrible. Then how good's the car ever gonna be when it comes out the other end. Even if everything in that factory line goes according to design. If the design sucks, the car's gonna be terrible. Right? Um, so ultimately it comes down to what con what starting conditions are you creating your cloud engineering, for your overall cloud-based services that you're designing and building? 'cause if you are, if you don't have a clear definition of what good looks like. If you don't have a clear set of policies that define appropriate usage of your resources and, and, and good engineering policy and principles in terms of, not just in terms of engineering security, we all care about security.

We all care about resiliency and capacity and all these other things, but efficiency is often, uh, what we call the, the redheaded step chart. It's often the one that, you know, gets ignored kind of thing. Um, If we bake in that as well into the policies, the initial starting points, then that informs all of the architectural decisions all the way down the line. And then hopefully you don't see anywhere near as much waste. You see some, uh, some, some improved efficiencies, right? Um, but what's a, what is a policy without teeth? What is a policy without governance, without the ability to ensure that it's actually being followed? It's a Christmas list. Right. It's a, it's an, I would like the, you know, it's a wishlist, right?

So, policy is worthless without an associated piece of governance. That governance might be some straightforward guidelines of this is how you do this thing, right? Or it could be some hardcore guardrails, right? Your, your CICD pipeline is coded so that if you try to build something that is either over a certain size or doesn't have a labeling or whatever, it just doesn't build. Right. So, um, varying levels of, of, of, sort, of draconian measures to be taken to ensure the policies are followed, but ultimately a policy must be governed. And then at the end of that, we must have compliance to validate that the policy governance worked and delivered what we wanted because, policies are made often in an ivory tower.

They're often, often made in a vacuum with hope. Right. may, policies are statements of hope. They really are. Right. Um, what we need to see is like when the policy was put into action and followed, did we get what we wanted? And I'll say one other thing. I I, I'll say, I'll talk too much about this stuff, but one other thing about policies that they are static pieces of documentation a rapidly evolving fluid landscape. Right,

which means that a policy that was written in 2018 about cloud is probably really bad now, right?

It's probably not a good policy now.

Right? So what I like to do when I create a policy is put two dates on it. I put a review date on it. Like when do I need to validate that this is actually still worth doing and I put a sell by date on a used by date on it, right?

When does this go? When does this, when has this gone stale? do I think this is probably no, not gonna be any good for now. That could be a combination of the expected evolution of the cloud services, the policy relates to, it could be the maturity of my business as it, as it as it moves through, right?

Because obviously might have a situation, we start off, we've done a DC exit, we've got loads of VMs, everything's static, all C, all EC2 or whatever, right? But actually. That might not be where we wanna stay. And we are moving towards a highly sort of cloud native serverless, Kubernetes, all that kind of thing. So policies that talk about EC2 are not gonna do a lot of good if everything is now in in Lambda,

right? So what's the sell by date of my policies and when do I need to, like that's no longer a thing, orbin that now kind of thing.

So anyway,

like I said, talk too

much about that stuff, but like, these are really important things because if we don't get that right or if that doesn't exist. How do we expect our engineers to do good things if we've not told them what good looks like from a

value and from efficiency perspective? They're guessing. So it's important to do that.

Alon Arvatz: Absolutely.

And. I think that when people, uh, talk about governance, uh, sometimes they go very fast to, okay, what guardrails I can put in place that will enforce

the policies that we have. But you talk about inform.

You talk about guidelines

and,

and you talk about principles

that basically people need to operate accordingly.

So sounds from you like governance is not about like putting the right tool in place to enforce things, but actually creating certain policies or statement of hopes

and then find a way

to track and make sure it really happens. Is that accurate?

Ben de Mora: Yeah. So, um, it's a really good point actually. Um, the more control you apply, the more people will find a way around right? We, we know that's gonna be the case. If somebody, if somebody's like, well I can't do X, Y, Z because my guardrails don't let me. I'll just do it over here in a different account and I'll put the book company credit card on it.

'cause I need this to work and

I'm just gonna go do this. Right?

So. Um, we have to be really careful

when we're applying governance because not enough governance results in chaos. Right.

But

too much governance

results in chaos that's invisible that we have to go find elsewhere. Right. So the, the happy medium. Yeah.

And depending on what we're trying to govern and who we're trying to govern, as well as the other, other important thing, the culture and the organization and the attitude towards this kind of thing. So what we're trying to govern and who we're trying to govern. We need to dial it up and dial it down.

Like how much, how much wiggle room do we create and how much capacity, how much freedom do we do we allow in the interpretation of this policy that we are creating here? Um,

and that is a, that's a continually, continually fine tuned thing, right?

Um, and this is why, this is why

compliance is really important, because if your governance is being side stacked, or your governance is creating problems. it just isn't effective, you've gotta fix it. Um, a lot of people consider this to be a set it And forget it thing. We do it once. We did all the work, took ages, we wrote some, wrote some really boring documentation, and now we're done with that thing. We'll move on.

Right? But it's a continually living thing, um, to keep, keep evolving,

Alon Arvatz: And do you always make sure

that you have an exception process? Yeah.

Ben de Mora: Absolutely. Yeah. There always needs to be a, a, you know, break glass thing where,

um,

there's gonna be edge

cases that just, that there just is, right? And when there is an edge case, there's gonna be an easy way to go, right? Actually, here's a justification where this policy, in this specific instance, it's actually not helping us.

So we need to do X, Y, z. That might also, the other thing with exceptions is also have sell by dates and review, review dates on them. an exception might be there due to the fact that this rapidly evolving landscape we work in hasn't quite caught up to the demand of that specific, specific thing we want to do. Right? But it will, it may well do, right? So maybe we have an exception now, but in six months we have to review the exception and say, do we still need this exception? Or is there now a thing that allows us to do what we were trying to do,

which is in policy? Or do

we need new policy? Because the exception has actually proven that policy's not good.

Alon Arvatz: and Ben to make things,

uh, very practical. Can you share with us, uh, a few policies, high level, a few policies, that you implemented and you felt make a big impact?

Ben de Mora: Definitely. Right. Um, versioning management, storage, versioning, manage. Is one good one. Okay. So, um, at a business that shall not be named, I saw, uh, one, one single GCP bucket. Just one bucket, right. With, uh, a couple terabytes of storage

being that stuff being stored in it. that was costing a third of a million dollars a month

Alon Arvatz: Wow.

Ben de Mora: old.

Yeah,

right. 4 million a

year in old versions being retained

on that. Not, not, not the data, not the data itself. Just the older versions.

330 grand a month,

Alon Arvatz: Wow.

Ben de Mora: right? Um, because somebody had gone, I'll have, I'll have versioning on this. This data's important. I'll, I'll keep every version of it forever. Right. So I mean, you know, version and

control.

I want to keep the last 30 days or I want to keep the last 50 revisions or whatever. Right?

But if you've done, if you have,

the problem with

cloud is that unlike the data center where you hit a point where your with storage filer has run outta disc and you have to go buy a new filer, that's a very, that's a present thing that you will see in cloud.

That doesn't happen. It just keeps going. Right. So, um, if you don't have any kind of, of data management storage, lifecycle management storage is a, is like a silent killer in cloud because it just keeps on adding, it keeps on adding, especially when you've got versioning or if you've got excessive transit between la between, between storage categories, whatever. Um, I saw another situation where somebody was archiving de glacier on a daily basis and the money they were saving on the storage. out of S3 to Glacier was being destroyed by the transit costs of moving to Glacier every day all the time. Right. So it's about, I mean, great intent. Yeah. But thinking about what you are doing with your storage.

So setting up policies that say. once a month in one go. Right. Or things like, um, we are only gonna keep this many versions for this period of time, or this number of versions,

whichever comes first. that kind of thing. Yeah.

Um, as an example, there's, there's

loads of those, right? And

you did

say high level.

They weren't high level, they were

specific. But storage, storage, life cycling is important. That's your high level one. Um, but other things like, um, non-production workloads. Yeah, if you go from 24 by seven to 12 by five in your uptime, is an almost 64% reduction. 63.78, I think percent reduction usage, right?

It's nearly two thirds for, for just turning it off when you

go home. right. Like we we're all taught as children. Turn the lights off when you leave the room.

that with us when we

go to cloud. And if your engineers are at the pub on a weekend where they should be and or whatever, and, um, they're, they're out socializing and their,

their dev environments are up running and costing money. Why, what are we getting for that money? So,

um,

of simple

policies, and again, exceptions, sometimes you don't want to turn off the environment, outside hours because,

I mean, have you ever tried to turn off a sap, a SAP database

and turn it back on again? It takes a lot of effort,

Alon Arvatz: Yeah.

Ben de Mora: right? Sorry, sap.

Alon Arvatz: Yeah,

Ben de Mora: Love you. Really.

Alon Arvatz: they'll do

well. I'm sure they'll do well.

Ben de Mora: they will. Yeah.

Alon Arvatz: Um, cool, Ben, that's extremely helpful and honestly mind blowing, like I'm still, uh. Picking up the, the pieces, uh, uh, from my mind being blown away. It's really very practical, very relevant stuff. And then

I wanna leave, you know, some time to actually learn a bit more about you,

Ben de Mora: uhoh,

Alon Arvatz: personal level

and to today, Uh, you live in, uh, Scotland, right?

Ben de Mora: Yeah, just outside Glasgow. Um,

yeah, it's, it is beautiful. I've been here

about 15 years. Um,

it's a lovely country. Um, shame about the weather. I'm looking out the window Right.

now.

Uh, and it's not that great. But no, it is a beautiful place. Um. And Yeah.

visit

Alon Arvatz: Yeah, It's absolutely beautiful. And I share with you that I did my past high school trip to Scotland. It was incredible.

Ben de Mora: Cool.

Alon Arvatz: How, how did you end up in Scotland because you're not originally from there.

Ben de Mora: Can you tell No, um, uh, no, I'm, I'm, I'm from, uh, Bristol, originally down, down in the southwest of England. Um, I was working for Oracle at the time, so I was at Sun Microsystems, which was wonderful. Uh, and Sun got bought by Oracle, uh, which was quite a traumatic experience, but uh, as it will be when you get bought as a company, right. Um, but yeah, Oracle bought sun and at the time I was based out of an amazing place in Berley called Mont Park, which was wonderful. It's now a housing estate, Belway Homes or something. but yeah, Gilmore Park and there.

was a big data center there and they moved the data center. Oracle moved the data center from that place up to a place in Scotland called Lin Lithgo. Right. Um, and they also, they were, they were closing down that site and um, I was kind of looking at this and thinking. Well, that's gonna be a problem. Uh, so I looked, I looked at the data center up in Scotland and I got a couple work trips up here. Got to know some of the people here, uh, folks up. Rob Wainwright, who, uh, is at Aptio now, who's wonderful. Um, and I was like, no, I wanna come work here. This is awesome. I love this country. This is great. I'm gonna move here. I'm gonna work

here. So I got a job at the Oracle data Center up in Scotland, and, uh, moved my family up here and it was great.

Um, but that

was, that was, a while

ago, but, uh, yeah, that was fun.

That was, that was, that began

five years of me being a data center engineer and principal, data center engineer and all that other stuff.

Alon Arvatz: Cool. And

you

grew up in England. In in England, but nonetheless,

you're not

big into soccer or football. Right.

Ben de Mora: No, I'm a rugby person. Um, yeah, I, I very much Harle, Quinn's rugby team. Great rugby team. Um, they may not win, but they definitely won't bore you on the pitch. Um, sorry, sorry. Quinn's. Um, yeah, no, Rugby, rugby for me is, is more of a, is is my sport. I used to play, I was a,

I was a right side, was a, a tight head flaker. Um, if you, if so, yeah, that was, that was me.

Alon Arvatz: Yeah, that's a painful sport. Very painful.

Ben de Mora: It is, it is. It's brutal. Yeah. It is fun. It's, it's very strategic though.

It's very strategic. Um, it's not just violence on the pick pitch. Uh, it is, it is a good sport to play

Alon Arvatz: Yeah. And then a few words about the guitars behind you that almost distracted me the entire conversation.

Ben de Mora: Um, yeah, I, I, I'm a musician. I've been a musician since I was

about 11. Uh, my dad, um, was a musician as well. He played, uh, lots of different instruments.

Um, I, I have his,

uh, yeah, I used to have pretty in all in my, where he used live. Used to have his banjo on my wall. I inherited when he passed away. But, um, yeah, music, music is very, very important.

You have to do something That That doesn't involve looking at a screen your entire life, right? You've gotta walk away from it and do something with your hands and make

something beautiful. Um, and I also think that that kind of works of art too, right? Like they're, they're, they're very beautiful

things as well as sounding amazing and

being great to play.

So it's a good thing to do to just, uh, clear your mind, stop not think about technology or finops. I know that's heresy, right? Don't think about finops for a few

minutes. Do something else. Um, go for a walk, ride a motorcycle, um, play guitar, whatever, right?

Alon Arvatz: That's a great advice. And then is there any book you would recommend us to read?

Ben de Mora: Yeah. So, um, there's a couple of

authors, um, Brian

Cox and Jeff Forshaw. Um, they're scientists and they write some really fascinating books, but what I like about them is that they're very accessible. They're very pedestrian, very easy to read. You do not need to be a physicist to read them. Um, and there's some great books that they, that they put out.

Um,

so the one that I'm reading at the moment called Why Does E Equal Mc Squared and Why Should We Care? Um, fascinating. Really, really interesting stuff. So,

if, um, if the way the world works is interesting to you, worth having a read.

Alon Arvatz: Absolutely. By the way physics was what I wanted to study in university, but then I decided to study something, uh, practical and I went for a law in accounting. And three years into my studies I dropped out to find my first startup. So, uh, phys, but physics has always been my passion.

Ben de Mora: believe it or not, So, when I went to university to go and do the open day thing and have a look around and, and

like, you know, choose a degree and all that kind of thing, I went with a view of doing a physics

Alon Arvatz: Oh wow.

Ben de Mora: I was gonna do a physics degree, right? And I was really interested and then I went. To the computing faculty and I went into the, um, the robotics and all that kind of stuff and I saw, I saw like robots driving around the ground, following lines on the floor and like robotic arms and stuff.

And I was like, this looks like fun. I'm gonna do this. Uh, and, and that's the degree I did instead was competing for real time systems. Uh, lots of embedded systems, design and lots of assembly, language code and c programming and all that kind of stuff. So because they

play, they let me play with robots.

So I did that instead of physics, and, and now here I am.

Right? And not doing physics

Alon Arvatz: in

ops.

Ben de Mora: In finops. Yeah, no physics, no physics

in finops. It's all virtual, it's

Alon Arvatz: Yeah, exactly. Cool. Ben, thank you very much. If people want to reach out to you and ask questions, what is the best way to do that?

Ben de Mora: Uh, LinkedIn. Um, so hit me up on LinkedIn. Um, I, it's on my phone. It shouldn't be what it is and uh, it's terrible. Um, but yeah, send me a message and, um, yeah, I'm happy to chat about stuff. Um, and

yeah, if you, if you do, you know, there you go. If you do read that book, um, then gimme a shout 'cause it's always good chat. chat.

Alon Arvatz: For sure. Ben, thank you so much for joining us today.

Ben de Mora: Uh, thanks for having me and this was fun. Cheers.

Alon Arvatz: It was a lot of fun. and I would like to thank also our audience for listening in through the entire show. Uh, I'm sure you Enjoyed it just as much as I did. For me it was Mind blowing. so I'm sure for many of you as well, Ben, thank you again for joining us. This has been another exciting mind blowing episode of of in Action.

See you next time.