0:04

You can have the best solution in the world, but

0:06

it won't matter if you can't communicate the

0:08

value to prospective customers

0:11

and users. Translighting technological

0:13

capabilities into business value is

0:15

an important enroll within any enterprise

0:17

tech company. And being able to communicate

0:20

the value of a joint solution, well,

0:22

you really need to have a firm understanding of the technology

0:24

and a working of your partner's technology.

0:27

And with that understanding, you can discover

0:29

the value for your users and customers. I'm

0:32

Burj Sutter, and this is Code Comments. An

0:34

original podcast from Red Hat. In

0:37

today's episode, I talked to Neesha Godbole

0:39

at MuleSoft. Nisha began

0:41

her career in tech as a computer science graduate

0:44

starting out in an engineering role.

0:46

But now she finds herself focused on the business

0:48

side of MuleSoft as a partner account

0:51

manager. So

0:54

many of us are out on this kind of journey in many

0:56

cases, meaning we we maybe started school

0:58

where we actually learned a bunch of technology and then Wayne had

1:00

to go out in the real world and apply

1:01

them. Can you give me a little bit of background? You're

1:03

like, what kind of journey you've been on? Yeah,

1:06

absolutely. And and thank you for having me.

1:08

joined MuleSoft about a year and a half

1:10

ago, and I was a channel

1:12

solutions engineer. So I was working with

1:15

our partners, which is kinda how I brought

1:17

myself to to this role. That I'm in

1:18

now, which is a partner account manager. But

1:20

when was a channel solutions engineer,

1:23

I was

1:23

supporting our partners with MuleSoft technology.

1:26

So similar to a traditional

1:28

solution engineer that works in the deal cycle

1:30

that would support typically an account executive

1:33

to to help a customer pitch or prospect

1:35

understand the technology and how it might

1:37

add value to them. We do similar

1:39

role in the channel solutions engineering space

1:42

basically support our partners in in doing that

1:44

same thing, understanding the technology. So

1:46

in this case, MuleSoft, which is owned by Salesforce.

1:48

It's an integration and API management platform.

1:51

Helping our partners understand, you know, what is MuleSoft?

1:53

How can it help you? Because integration and

1:55

API management is not always the easiest thing to

1:57

understand But, you know, as a partner, for

2:00

example, Red Hat, how can you and

2:02

how can your customers best make use of

2:04

MuleSoft so that it can help enable their

2:06

business transformation needs their digital transformation

2:09

and support their business and growth.

2:11

So that was the role that I was in up until about

2:13

a month ago when I transitioned into

2:15

the role that I'm in now, which is more sales and business

2:18

facing as a partner account manager.

2:20

So in this role now, I'm supporting

2:22

our partners, but more so owning the relationship

2:25

That's now the role that I'm in. It's a bit of a

2:27

change from my previous role and, of course, my background,

2:29

but it was sort of a natural transition for

2:31

me coming from the CSC role or channel

2:33

so no duty to enroll to now take this one on

2:36

because I'm able to blend my technical experience

2:38

now with with more of a sales or business

2:39

mind. So it sounds like you have that dual

2:42

skill set of customer facing, partner

2:44

facing, as well as technological skill

2:46

set. Yeah. And you know, it's it's funny.

2:48

I I never really thought that I would find myself in

2:50

this role, but I feel like the

2:52

the arc of my journey is probably similar

2:54

to many others where it's like you learn the technology

2:57

at the most basic level, but then really

3:00

what customers and and the market cares

3:02

about is how can you actually apply that technology?

3:04

Like, why does that matter to the business at the end

3:06

of the day? And so being able to translate

3:08

the technology concepts into

3:11

business language that folks can understand and

3:13

understand the benefits I think has been

3:15

one of those kind of themes throughout my journey

3:17

and probably others as well is, okay, we have this

3:19

technology, but what purpose does it serve? Who's this

3:21

gonna help and why? And then how

3:23

is sort of the underlying reasons, how

3:25

the technology works to begin with. But

3:27

it's a business value that really is going to help

3:30

drive

3:30

ROI. Absolutely. And I like

3:32

what you said there because you definitely are spot on

3:34

when it comes to the application of

3:36

technology to a business problem. I

3:38

think a lot of people do forget about we kinda get

3:40

caught up in the technical bits and bolts and -- Mhmm.

3:42

-- just enjoy living in that technical

3:44

world, geeking out in some cases. But at

3:46

the end of day, we do have to solve a business problem.

3:49

Absolutely.

3:50

Let me ask you this. I'm interested in knowing

3:52

more about integration. You said integration. You said API

3:54

management. We know MuleSoft is very famous for that,

3:56

but I imagine some of our listeners are

3:58

not yet really tuned in to what the space

4:01

looks like. So can you kind of describe

4:03

more about what it means to

4:04

take, you know, connect a to b and what those

4:06

different types of systems might be and types of use

4:08

cases you might serve? Yeah. Absolutely. it's

4:12

interesting that, you know, when I joined MuleSoft, I

4:14

also had no idea what integration looked

4:16

like or or what really was a business case that we were

4:18

trying to solve. So it's it's been quite a learning journey

4:20

for me over the past year and a half, which I

4:22

think has has been actually one of the the best

4:24

parts about this company and

4:26

role. But so integration on

4:29

the whole is, you know, connecting

4:31

various systems. So as a business,

4:33

you have hundreds or thousands

4:35

of systems that you need to connect, that

4:37

need to talk to each other in order for you to

4:39

deliver on experiences, or

4:41

deliver on employee needs, customer

4:44

mobile apps, things that your

4:46

customers, partners, employees are going to actually

4:48

interact with on the daily. Those

4:50

need to be powered by data. And that

4:52

data is stored in various different systems. So

4:54

that could be Salesforce, that could be, you

4:56

know, on premise database, that could be

4:59

another cloud based system. There's

5:01

hundreds. Right? And of course, with the explosion

5:03

of best of breed, that's just going to become

5:05

even more of a thing. So those systems need to

5:07

be able to talk to each other. And the way that they talk

5:09

to each other is typically through APIs.

5:12

And so in order to integrate those

5:14

system, you have to develop and design

5:16

and deploy APIs and

5:18

integrations and at MuleSoft think of those

5:20

pretty synonymously. And to do that, you

5:22

know, you need a technology platform. So

5:24

MuleSoft provides that single platform that

5:26

allows you to design, build,

5:28

deploy, and then manage your APIs

5:31

and your integrations so that your systems can

5:33

talk to each together and so that you can deliver

5:35

those experiences that your partners,

5:37

customers, employees need at the end

5:39

of the day, which, of course, relates

5:41

back to a business problem, which driving more efficiency

5:43

or a new channel of revenue

5:45

or a new product. All those things are gonna require

5:47

those experiences. That's driven by the data

5:49

that's stored in those systems. So that's

5:52

the core of integration.

5:54

I call these things connectors. Right? So in other

5:56

words, in many cases integration

5:58

platform is often measured by the

6:00

connectors that it can maintain, the connectors that

6:02

it has to basically, you know,

6:04

glue one system to another system. What would you

6:06

say are the most common connectors

6:08

and use in the MuleSoft universe. What what you

6:10

know, from customers that you've seen, what are their

6:12

primary use cases? Are they trying to just take an

6:14

Oracle database a date out of it and actually

6:16

map that over to Salesforce or they're trying to

6:18

go from a message broker out to a rest

6:20

end

6:20

point? Or what would you say if some of the primary

6:23

connections are? That's a great

6:25

question. Of course, it's going to

6:27

depend on the customer. And MuleSoft

6:29

and at Salesforce, we like to think about it

6:31

in terms of industry and in industry problems

6:33

that customers are trying to solve, you know, customers

6:35

specifically in an industry and their challenges are

6:37

all related to that. A

6:39

lot of the connections, you know, we're owned by Salesforce,

6:42

are going to be to Salesforce and Salesforce

6:44

products. So for example, Sales

6:46

Cloud or Service Cloud or all the

6:48

industry clouds that we have now is manufacturing cloud,

6:51

automobile cloud all of these clouds

6:53

need to be powered by data that's in this underlying

6:55

system. So that's gonna be a common

6:57

front end experience, but then also

6:59

potentially a back end connector. So

7:01

you talk about connectors. You also have to maintain

7:03

three hundred plus connectors that are basically

7:06

out of the box connections to

7:08

these underlying systems like Salesforce,

7:10

like SAP, like, you

7:12

know, a database. We just have standard database

7:14

connectors. It could be, you know, Amazon

7:16

Red Sheft. It it could be a a whole host

7:18

of things. Workday. All

7:20

these connectors are maintained by MuleSoft

7:22

in partnership with these other companies

7:24

that help us develop them. And then the

7:26

beauty of that is that when you go to integrate

7:28

to these systems, you have basically

7:31

out of box configurable, customizable,

7:34

connection to these systems rather than

7:36

having to build something from scratch. And

7:38

I think at MuleSoft, you know, integration and

7:40

API management is always gonna be complex.

7:42

How can we make it a little bit complex by

7:44

providing some of this out of the box connectivity to

7:46

these systems that our customers and are gonna

7:48

commonly connect to. So those are just a few

7:50

examples. Those can drive all

7:52

sorts of use cases across the board. But

7:55

but those are some of the common ones that we're

7:56

seeing. Is it pretty common to

7:58

actually have kind of what I call an aggregated API

8:00

where you mentioned earlier like the digital experience

8:03

where I might have a mobile application. Mhmm. And

8:05

I'm trying to communicate to the back end

8:07

set of systems and systems of record and

8:09

back office systems. Mhmm. So I might have an aggregate

8:11

API that's basically facing that

8:13

mobile application. But back behind

8:15

there, maybe fifteen other a which might

8:17

be the database connection. It might be a message broker.

8:19

It might be these fifteen web services

8:21

with Wistles and, you know, soap or it might be

8:23

these REST endpoints with JSON. And

8:25

I'm assuming you guys are helping the user

8:28

helping the developer in this case, aggregate those

8:30

things, get them into a common format, transform

8:32

them, and, of course, send that request

8:34

response through that

8:35

channel. Absolutely. Yep. That's

8:37

exactly what MuleSoft focuses, and we

8:39

provide the tools to be able to do that.

8:41

Right? One of the things that we talk about MuleSoft

8:44

is the idea of API led connectivity.

8:46

And so that's really

8:48

central to the way that we develop and the way

8:50

that we build integration architectures. And

8:52

I think that that goes exactly to what

8:54

you're talking about is, you know, this back end

8:56

between the core systems of record and then

8:58

your front end experiences or whatever it is that you're

9:00

trying to

9:00

deliver. And just to elaborate a little bit more

9:02

about what that means is

9:03

this concept of breaking down the

9:06

layers of APIs into

9:08

what we can think of as, like, layers of a cake. So, you know,

9:10

so if we think about it in three layers. So

9:12

at the bottom, you have what we call system

9:14

APIs, and those are going to be direct connections

9:16

to those underlying systems. Be

9:18

it Salesforce, be it a database, be

9:21

it SAP, and you can expose

9:23

that data through that API in a

9:25

common format. So like you were saying, you know,

9:27

you're gonna have developers working

9:29

across the space, different developers

9:31

using different tools potentially, and they're gonna

9:33

come from different backgrounds. But how do you present

9:35

data in common format so that everyone in the

9:37

organization can actually make use of it. And

9:39

that's the idea of this API led

9:41

connectivity is where you expose your

9:43

data from the underlying system in a common

9:45

format so that other folks at different layers of

9:47

your APIs can make use of them.

9:49

And on top of those system APIs

9:51

is what's called the process API, and that's where

9:53

you're actually going to aggregate various

9:56

systems of record and put them into

9:58

business capabilities that can be made use of by

10:00

those front end experiences. So that

10:02

could be, you know, a customer API

10:04

that represents all your customer data in

10:06

a canonical data format, but it might make

10:08

use of multiple stumbs under the hood, or

10:11

maybe it's, you know, an order information,

10:13

API, or product API. All these are

10:15

going to be represented at the process layer. And then

10:17

lastly, you have the experience layer. And so

10:19

experience layer is gonna take those processor

10:21

system APIs and serve them up in a way

10:23

that's actually consumable by that end

10:25

experience. So be it Salesforce or a

10:27

mobile app. That's just how we think about it

10:29

MuleSoft. Of course, there's gonna be various variations on

10:32

that, and it's not always gonna look exactly

10:34

like a three layer cake, but that's how we think

10:36

about it really to break down those layers and make

10:38

sure that you can enable parallel

10:40

development through a a single sort of

10:42

source of truth through an API.

10:44

I do love that layer cake idea that you just described there.

10:46

That definitely helps, I think, our audience who's

10:48

listening to this from a verbal

10:50

standpoint, kind of paint that mental picture of how

10:52

to layer up things to have those different

10:54

APIs and those different layers of experience.

10:56

That is awesome.

11:01

We are talking

11:03

a lot these days about how to reduce

11:06

cognitive load. That's the key phrase you hear a

11:08

lot in this industry at the moment. How to cognitive

11:10

load on that developer so they can think about the

11:12

business outcome and less about the bits and

11:14

bytes, let's say, of specifically how to make

11:16

certain things run. And in the case

11:18

of a Kubernetes target, being able to

11:20

ignore that, oh, how did I get the Docker file

11:22

exactly tuned correctly? So I can do my

11:24

Docker build, produce that actual image where

11:26

it'd be a podman or build or some other tool.

11:28

Forget to get it through a CI, you know, a continuous

11:30

integration pipeline into a production

11:32

environment like an open shift for Kubernetes. That

11:34

is a lot of work. All by itself, just figuring

11:36

all those things out. So if you can reduce that

11:38

cognitive load, so the person can think just about the

11:40

business logic, the business outcome, and specifically

11:43

this integration style API or

11:45

to

11:45

development, I think that's a huge win. Mhmm. You

11:47

know, at MailSoft, we talk a lot about reusability.

11:50

Like, once you've written something once, why

11:52

not be able to reuse that again in the future

11:54

rather than having to start from scratch

11:56

and, you know, go through that cognitive process

11:58

again to your point. And that's the point of the

12:00

connectors that we have where it's we

12:02

know. A million customers have done this

12:04

before, why don't we leverage what they've already

12:06

done rather than try to start something from

12:08

scratch which is an issue that we see with a lot

12:10

of other integration platforms. But it's

12:12

the same for that business transformation. You

12:14

know, MuleSoft has tools by

12:16

which once you write that business transformation in that logic,

12:18

you can actually save that and then reuse it

12:21

again in the in the future connection or

12:23

future integration or API. So

12:25

that you can, you know, use it as what we call

12:27

reusable building block basically

12:29

in a future project. And the same goes for

12:31

APIs, you know, once you build that customer

12:33

API that you've agreed on with other

12:35

folks in your organization that this is going to

12:37

represent the data format for a

12:39

customer in this

12:39

context. Well, now I can use that customer

12:41

API in the future when I try to develop

12:44

another mobile app where now I'm looking to

12:46

develop a web portal It's that

12:48

same business logic that can be reused again and

12:50

again so that you're not starting from scratch and

12:52

so that you actually can accelerate future

12:54

projects instead of, you know, starting from

12:56

grounds zero each time. Is it fairly

12:58

common for people to use the open API

13:00

specification to determine what that's cheema

13:02

is that, you know, that definition of what the

13:04

object is over the wire, whether that be JSON

13:06

or something else. You know, can you describe more

13:08

about what that looks

13:08

like? You know, how do I describe my APIs

13:11

inputs and outputs. Mhmm.

13:13

Yeah. You can use open API. You

13:15

can use ramble.

13:18

You know, you can use a whole host of tools to

13:20

design your API. So there's actually

13:22

an element in in MuleSoft called the

13:24

API designer, and that's where if you're

13:26

gonna develop a new API where you

13:28

should start, right, and and it's gonna

13:30

go through iterations because when you're

13:32

designing an API or you're thinking

13:34

about a design first approach, you're

13:36

gonna make sure that the other developers,

13:38

the other, you know, business folks, your

13:40

organization agree upon that. And so there can

13:42

be, you know, multiple iterations of that

13:44

design, but most of task tools built on to

13:46

the platform that allow you to develop that and

13:48

write that code. And then look at it

13:50

with other folks in your organization to get that

13:52

approval before you actually take that

13:54

design and use it as the basis for your

13:56

implementation of the API

13:57

itself. Would

13:58

that markup language then actually generate a

14:00

skeleton for me? Is that the next step in the process?

14:02

Yep. Absolutely. Yeah. So you take

14:04

that design and using their soft tools,

14:06

using the IDE, you can actually

14:08

skeleton out your API based

14:10

on that ramble or based on that

14:13

open API specification.

14:16

Throughout this conversation, I began to

14:19

see the world that works in thinking

14:21

about those business outcomes for the technology.

14:23

As distinct from what I do at

14:25

Red Hat, But as it turns out, we have more

14:27

in common than I thought. You

14:30

know, you guys are very focused on the

14:32

business outcome and the business use

14:34

case. But at Red of course, with openshift,

14:36

we're very much focused on the more lower

14:38

level infrastructure and how to make

14:40

pods run with a nice control plane and

14:42

things of that

14:43

nature. How would you say we kind of navigate

14:45

those two worlds? And did you find there was a gap

14:47

there that you had to kind of work with us

14:49

on to navigate? You know, I think

14:51

whenever you have a technical

14:53

product or, you know, a product

14:55

design for developers, it's

14:58

sometimes hard to level up

14:59

the thought process around

15:02

what is the business outcome that we're looking

15:04

to enable. Because even with an

15:06

open shift, you know, very technical

15:08

infrastructure, platform.

15:10

At the end of the day, it's enabling

15:12

a business transformation. Right? Like those

15:14

containers, those pods, those are going

15:16

to allow you to do faster development,

15:18

have, you know, more

15:20

efficient cycles, and have more

15:22

scalable infrastructure that's gonna allow you

15:24

to develop new business capabilities

15:26

quickly and then also maintain those and

15:28

and upgrade those and and scale those as

15:30

needed. And so I think

15:32

throughout the process, you know, even in my time

15:34

at MuleSoft, that's been a

15:36

challenge. Right? Like, how do you understand a

15:38

technology at at the deepest level that

15:40

you need to, but then also be able to

15:42

communicate, well, this technology allows you

15:44

to do this at the end of the day because that's what the

15:46

customer with the buyer is thinking about

15:48

in order to enable whatever

15:50

initiatives that they have. So I do

15:52

think as we were partnering

15:54

together the Red Hat and the MuleSoft teams

15:56

on this project, it was a

15:58

matter of jointly doing that with

16:00

the solution that we also together. Right?

16:02

So the solution was MuleSoft time

16:04

fabric running on Red Hat

16:06

OpenShift, and so the ability

16:08

to basically employ your APIs into an

16:10

open shift environment from the MailSoft platforms

16:12

that you could run your mail APIs there. But

16:14

again, what does that mean for the customer why?

16:16

Would that be valuable to them? And

16:18

in order to understand that and articulate

16:20

it, you know, we did have to do some understanding

16:22

of what is open shift and and what is the

16:24

benefits that it provides the customers how do you

16:26

guys over at Red Hat talk about openshift to your

16:28

customers and and what are the benefits? So that

16:30

was a whole learning process, I think, in addition

16:32

to, you know, having to educate myself about

16:34

what is a container, you know, what's the

16:36

value of it? And why would people adopt

16:38

Kubernetes? So then how now does

16:40

OpenShift play in that

16:40

space? And and what's the value of OpenShift on

16:43

top of Kubernetes infrastructure.

16:46

Well, hopefully you can see that there are a lot

16:48

of synergies here. And or at least you

16:50

discovered that through this process of the partnership, In many

16:52

cases, when we talk about O shift, when we talk

16:54

about Kubernetes, it's something as low level as

16:56

a rolling update, or right, the latness

16:58

program, and readiness probe. And again, that's low

17:00

level infrastructure thinking. But what it

17:02

means to the business is that you can

17:04

deploy now even faster. Right?

17:06

I can deploy every five seconds if I

17:08

need to because the rolling update protects me

17:11

from my downtime window

17:13

because it basically rolls over. The user

17:15

never sees that it went down. It basically

17:17

rolls that traffic over to the next

17:19

pod that's coming to life kind of thing. So

17:21

was that the kind of area you were thinking,

17:23

or is that actually lower than where you

17:25

were thinking at the time we talked about the

17:26

partnership? No. I mean,

17:29

I think in in order to articulate the value of,

17:31

you know, containers, it's being able to

17:33

say that. Right? Like, okay. Now you have everything wrapped

17:35

up and that makes it easier to develop and easier

17:37

to have flexible deployments. Okay?

17:39

And now Kubernetes, what does that mean? What's the benefit of Kubernetes? And

17:41

now open shift on top of that. What are the

17:44

benefits of those? I think it builds on itself.

17:46

Right? And then being able to say,

17:48

okay. Well, now MuleSoft and OpenShift

17:50

together, what are the benefits

17:52

jointly that we're gonna be able to provide? So I think it

17:54

was that it was almost a mapping

17:56

exercise of understanding from my Red

17:58

Hat counterparts, you know, how do you guys

18:00

talk about your platform and what are the

18:02

benefits of it? Because I know at Red Hat, you know,

18:04

there's a few certain things that you say

18:06

articulate in order to express the value.

18:08

And that muleSoft, it's the same way. Right?

18:10

It's, you know, faster development, faster

18:12

application development. It's more

18:14

efficient or resilient operations. It's

18:17

security built into the platforms that you didn't

18:19

have to think about it. It's

18:21

future agility. Those are

18:23

just a few of the things that we talk about at MuleSoft

18:25

that you're probably hearing on the Red Hat side

18:27

and

18:27

saying, oh, well, that's actually what OpenShift

18:30

does too. So it's it's up being able to articulate those things

18:32

and pull them out

18:33

and then say, well, where do we see synergies

18:36

across these two platforms? And

18:38

now houses joint solution going to and

18:40

continue to support those or other additional

18:42

benefits that it's

18:43

providing. Well, I think what you're saying there

18:46

is that when it comes to the business

18:48

outcomes, they're actually the same

18:50

across all the technological vendors that are in

18:52

this space. They want greater agility, they

18:54

want a fast time to market. They want resiliency.

18:56

They wanna make sure they have a greater

18:58

security posture in many cases. I hear

19:00

those same business benefits or business requests.

19:03

Often every day. Right? So the business is very much focused

19:05

on how do I produce new custom

19:07

applications, custom code, custom made APIs

19:09

and integrations in your cases, and ship

19:11

it ever faster.

19:13

And that's what I hear often. And that sounds like what you're getting

19:15

at here. Yeah, absolutely.

19:18

And it was actually an

19:20

eye opening experience when we would

19:22

sit down with the Red Hat teams and they would

19:24

say almost word for word, what we

19:26

say. And so it does, you know,

19:28

bring up this this kind of greater conversation

19:30

around technology itself is these

19:32

are what technology today are is trying

19:34

to accomplish with technology organization

19:36

are trying to and they just do so via different means. Right? So

19:38

Red Hat does it through OpenShift and a

19:40

Kubernetes platform. MuleSoft does it

19:43

through one single platform for API

19:45

and

19:45

integration, development, and management. And

19:48

I think that might be the core theme behind

19:50

everything we talked about today. At the end

19:52

of the day, the business outcome

19:54

is what really matters for the big

19:56

enterprise, the small business, the person

19:58

who's just building an application for their

20:00

small, you know, nonprofit they're all

20:02

trying to achieve the same outcome, which

20:04

is delivered digital capability, digital

20:07

APIs, and applications, ever fast least

20:09

how I like to phrase it. And I think that's what you're

20:11

saying also. Absolutely.

20:13

Yep. That's exactly what I'm thinking and

20:15

and I

20:15

think, you know, what our what our MuleSoft customers

20:18

are seeing And the way that it engages

20:20

with OpenShift is, in this

20:22

environment, customers need flexibility. They

20:24

need that support and and

20:26

scalability from trusted platforms

20:28

like OpenShift, you know, owned by Red Hat, which

20:30

is, you know, in a stellar company and

20:32

and they wanna be able to trust their infrastructure.

20:35

And MuleSoft has the same benefits. Right? So

20:37

how can we give these customers,

20:39

you know, the opportunity to build these digital

20:41

experiences and do so on platforms that

20:43

they know they trust and that they

20:45

believe we'll be able to set them up for

20:47

future success.

20:48

You mentioned earlier

20:52

in the conversation the concept of a three

20:54

layer cake Mhmm. Yeah. Well, I can almost envision it

20:56

now, like between the two of us, MuleSoft and

20:58

Red Hat, there's maybe a six layer cake.

21:00

Right? The the three layers that are closer to the

21:02

end user developer that business outcome

21:04

is the three layers you guys are focused on, but we

21:06

also have our own layers that are going more

21:08

towards the back end of the data center.

21:10

Where we're talking about things like Kubernetes and those rolling

21:12

updates, resiliency you get out of having that

21:14

dynamic separation of control plane from data

21:16

plane, etcetera. Again, a technical level,

21:19

but it offers that agility, it offers that flexibility.

21:21

And then, of course, maybe into

21:23

the container world, virtual machine world,

21:25

operating system world, those are additional layers down

21:27

to the actual hardware it all runs on

21:29

if you will. Mhmm. And so I can actually see that we

21:31

actually have that multi layer of

21:34

agility, if you will, different layers of agility going

21:36

all the way up to the very end point, which

21:38

is where the user, maybe on their

21:40

mobile application, is actually able to interact

21:42

with that cool API they built with

21:43

MuleSoft. Mhmm. Absolutely. Yeah.

21:46

It's it's incredible really

21:48

to see you know, what is the plumbing or the

21:50

underlying infrastructure that's actually creating these

21:52

experiences like you were saying all the way from

21:54

the hardware at the bottom. All

21:56

the way up through, you know, the Kubernetes and containers through

21:58

the APIs that are actually processing that

22:00

data and then serving it up to that front

22:03

end experience. We don't think about that when

22:05

we look at a mobile app and and order a new

22:07

pair of shoes. But really, that's what's happening in the

22:09

back

22:09

end, which is it's really incredible.

22:11

What would you say is a sweet

22:13

spot customer for our two solutions

22:15

to engage? Right? In other words, we actually brought

22:17

the MuleSoft platform, the Red Hat platform,

22:20

And we said, okay. This is the sweet spot use

22:21

case. This is the sweet spot customer. What we

22:24

say would be that ideal environment?

22:26

Yeah. You know, I think what

22:28

I've seen at least in terms of synergies

22:30

across our customer base is

22:32

sort of these large enterprises. Right?

22:34

Like large banks or financial institutions

22:37

that because they are

22:39

trying to change and innovate

22:41

and become digital first companies,

22:43

they need these platforms. They need to be able

22:45

to accomplish these and deliver on these mobile

22:47

apps, but they're also not always the most

22:49

digital first businesses. Right? They have

22:51

mainframes and core applications

22:53

that are storing our customer data,

22:55

our transaction information. So how do

22:57

you tie those two together? You know you know, you could think

22:59

of it as old school model of of

23:01

storing data. It's not in the cloud. It's definitely on

23:03

premise and you have all these security

23:05

restrictions. But you still need to stay as a

23:07

digital company and be a technology first

23:09

company. And

23:09

so, you know, I think our two platforms provide

23:12

that sort of sweet spot of

23:14

eliminating the complexity, but still allowing you

23:16

to do those complex things

23:18

that you always need to if you

23:19

have, you know, a really disparate environment.

23:22

I think that's a wonderful summary of

23:24

what we've been talking about here today. And certainly a

23:26

wonderful value proposition when it comes to

23:28

our joint customers. Nisha,

23:31

let me say this. I love how you explain these

23:34

things. And I appreciate the fact that you did educate me here

23:36

in this session because, again, I'm I've

23:38

been doing this a long time. I'm actually an old

23:40

school integration person. Meaning, I do live in

23:42

your world or at least I used to. I

23:44

actually am a j boss person, a middleware

23:46

person. Mhmm. And therefore, I do think

23:48

in terms of what it means to use something like a

23:50

camel or MuleSoft or, you know, Java

23:52

y or what other technology might be to actually bridge multiple

23:55

systems together and deliver a new common

23:57

API, a new cool application. But

23:59

at the end of the day, I kinda

24:01

get sucked back into the fact that, okay, I'm a Linux oriented

24:03

person now. I'm a kubernetes oriented person. I

24:05

got to figure out these containers are running well. It's

24:07

my control plane healthy.

24:09

Are my live misprobe and renders probes configured

24:11

correctly and all of my yamos correct?

24:14

Because of that, you know, I'm often

24:16

not thinking as much about that higher level of

24:18

business out common business impact that you

24:20

described so wonderfully here in the

24:21

session. Oh, well, thank you. And, yeah, I could

24:24

definitely tell you have you have

24:26

some experience in the in

24:28

the space verb because you touched on, like, a

24:30

million of the things that I think, you know, we are

24:32

already thinking about. So great

24:34

conversation.

24:35

Used to spend a lot of time in this world, in this

24:37

integration area. I really get. I hope.

24:40

You can read more about Red Hat's

24:42

partnership with MuleSoft at red hat

24:44

dot com slash code comments podcast. Many

24:47

thanks to Godbalay for being

24:49

our guest, and thanks to all of you for joining

24:51

us today. This

24:53

episode was produced by Brent Saminal,

24:55

and Caroline Craighead, and our sound designer

24:57

is Christian Prohan. Our audio

24:59

team includes Li Day, Stephanie

25:02

Wondrack, Mike Esser, Johan

25:04

Philippines, Kim Wong, Nick Burns,

25:06

Aaron Williamson, Karen King,

25:08

Jared Oates, Rachel Nortel,

25:10

Devin Pope, Matias

25:13

My company, Ocean Matthews, Alex

25:15

Trimbley, and Victoria

25:18

Lockney. I'm Bur Sutter, and

25:20

this is Code Comments, an original podcast

25:22

from Reddit.