>> Announcer: "theCUBE" presents "Kubecon
and Cloudnativecon Europe, 2022"
brought to you by Red Hat,
the Cloudnative Computing Foundation
and its ecosystem partners.
>> Welcome to Valencia, Spain
and "Kubecon + Cloudnativecon Europe, 2022."
I'm Keith Townsend, along with Paul Gillin,
senior editor enterprise architecture at siliconANGLE.
We are going to talk to some amazing folks,
especially, in today's segment.
Paul, there's a lot of companies here.
Like what what's been the consistent theme
you've heard so far in the show?
>> Well one thing that's different from this show,
it seems to me than others I've attended,
is it's all around open-source.
We're not seeing a lot of companies
bringing new proprietary technology to market.
We are seeing them try to piece together
open-source components
with some kind of perhaps as proprietary element to it,
but to create some kind of
a common management interface or control plane.
And that's quite different
from what I think we've seen in the past.
Open source business models have been difficult
to make work historically.
And these companies are all taking
their own approaches to it.
But I think the degree to which the people here of coalesced
around the importance of open-source,
is building blocks to the future of applications,
is something I've not seen quite this way before.
>> Well, for our current segment guests,
we're going to go deep into kind of these challenges,
and how enterprises are addressing
and their partners are addressing
with those challenges.
We have with us, Alan Flower,
head of Cloudnative at HCL Technologies.
We'll get into how a system integrator
is helping with this transition with Ramon Nissen,
senior product manager at Red Hat.
Welcome to the show.
You're now CUBE-alum.
>> Welcome. >> Thanks for having us.
>> So, we're going to get right off the bat,
we're going to talk about this.
What are some of the trends you're seeing
when it comes to application migration?
You've done, I'm assuming at this point, thousands of them.
What are some of the common trends?
>> Well, it's a very good question.
And clearly, at HLC we've helped thousands of clients
move tens of thousands of applications
to what we would call a cloud native environment.
I think the overwhelming trend that we're seeing,
of course, is clients realize
it's a particularly complex, sophisticated journey.
It requires a certain set of skills and capability.
Clients increasingly asking us for anything that we can do
to simplify and accelerate the journey.
'Cause what's really important to clients,
if you're on a transformation journey to cloud,
is you want to see some value very quickly.
So, I don't want to wait three to five years
to transform my application's portfolio.
If you can do something in three to five days,
that would be perfect, thank you.
>> Wow, three to five days, that sounds more akin
to when we were doing P to V or V to V migrations.
I'm sure HCL is at this point done in the millions
of those types of migrations.
What are some of the challenges
or the nuance in doing a traditional migration
from a traditional monolithic application to a cloud native?
>> Well, it's another good question.
Of course, you notice
that there's a general trend in the industry.
Clients don't really want to lift and shift anymore.
Lift and shift doesn't really bring
any transformational value to my company.
So, clients are looking for increasingly
what we could have call cloud native modernization.
I want my applications to really take advantage
of the cloud native environment.
They need to be elastic
and kind of more robust than maybe before.
Now, in particular, I think a lot of clients have realized
that this state of Nirvana, which was,
we're going to modernize everything to be a cloud native
microservices based application,
that is a tremendous journey.
But no client really has the time,
patient, or resources to fully refactor
or rearchitect all of their applications.
They're looking for more immediate kind of impact.
So, a key trend that we've seen, of course,
is clients still want to refactor and modernize applications
but they're focusing those resources
on those applications that will bring
greater impact their business.
What they now see as a better replacement
for lift and shift,
is probably what we would call replatforming.
Where they want all of the advantages
of a cloud native environment,
but they haven't necessarily got the time
to modernize the code base.
They want to refactor to Kubernetes
and replatform to Kubernetes in particular,
and they want us to take 'em there quickly.
And that's why, for example, this week at Kubecon,
eight sellers announced a new set of tools called KMP
based on Conveyor, an open-source project
supported by Red Hat.
And the key attraction of KMP,
is it lets me replatform my applications
to Kubernetes immediately, right?
Within two or three minutes,
I can bring an application from a legacy platform
directly onto Kubernetes,
and I can take it straight into production.
That's the kind of acceleration
that clients are looking for today.
>> Isn't that just a form of lift and shift though?
>> Well, now lift and shift typically, of course,
was moving virtual machines from one place to another.
You know, the focus of Kubernetes, of course,
is containerization of solutions.
And it's not just about containerizing
the solution and movement,
it's the DevOps tool chain around the solution as well.
And, of course, when I take that application into production
in a Kubernetes-based environment,
I'm expecting to operate it in a different way as well.
So, that's where we see tremendous focus
on what we would call cloud native operations.
Clients expecting to use practices
like cyber reliability engineering
to run these replatformed applications
in a different way too.
>> So, it sounds like you're saying,
I mean, replatforming has been a spectrum of options.
I think Gartner has seven different types of platforming.
Are you seeing clients taking
more mature attitude now toward replatforming?
Are they looking more carefully at the characteristics
of their legacy applications and make,
maybe more nuanced choices about what to replatform,
what to just leave alone?
>> I think clients, and I'm sure Ramon's
got some comments on this too.
But clients have a lot more insight now
in terms of what works for them.
They've realized that this promise,
of maybe a microservices based applications estate
is a good one, but I can't do that for every application.
If I'm a large enterprise
with several thousand applications in my portfolio,
I can't refactor everything to become microservices based.
So, clients see replatforming possibly it's a middle ground.
I get a lot of the advantages
from a cloud native environment.
My applications are inherently more efficient,
hopefully, a lot more performance.
>> Yeah, it's a matter of software delivery performance.
>> Yeah.
So, legacy workloads will definitely benefit
from being brought into Kubernetes
in the software delivery performance department.
So, it's a matter of somehow revamping
your legacy applications and getting the benefits
in application life cycle management,
a full tolerance, and all that stuff.
It's about leveraging what Kubernetes offers.
>> When you say bringing legacy applications into Kubernetes.
It's not that simple, right?
I mean, what's involved in doing that?
>> It isn't, it's just a matter of taking a holistic view
of your application portfolio,
and understanding the nuances of each application type
within your organization.
And trying to come up with a suitable migration strategy
for each one of these application types.
And for that, what we're trying to do,
is provide a series of standardized tools and methodologies
from a community perspective.
We created this Conveyor community.
It was kick-started by Red Hat and IBM,
but we are trying to bring as many vendors
and GSI as possible to try to set up these standards
to make these road towards Kubernetes as easy as possible.
>> So, we've done a little bit of app modernization
in the CTO advisor hybrid infrastructure.
And one of the things that we've found,
there's plenty of advantages.
If I take a monolithic application
that I've traditionally had to scale off
to game performance, I can take selective parts of that
and now I can add auto-scaling to it.
>> Exactly. >> However,
as I look at a landscape, Alan, thousands of applications.
I need to dedicate developer resources
to get that done in my traditional environment.
But my traditional environment
is busy building new, my traditional or my developers,
are building new applications and new capabilities.
I just don't have the resources to do that.
How does HCL and Red Hat team together
to kind of fast track that capability?
>> Well, I'll comment on two things in particular.
Actually, the first thing when it comes to skilling,
I think the thing that's really surprised us at HCL,
is so many of our clients around the world have said,
"We are desperately short of skills.
We cannot hire ourselves out of this problem.
We need to get our existing developer community re-skilled
around platforms like OpenShift Conveyor
and other projects too."
So, the first thing that's happened to us at HCL,
is we've been incredibly busy
undertaken, probably what we would call
developer workforce modernization,
where we have to help the client reskill
their entire technical and developer community
to give them the skills.
So, we will help the clients develop a community,
build the cloud native understanding,
help them understand how to modernize tools,
for example, or applications.
But the second thing I mention is,
and this comes back to a comment
that Ramon made around Conveyor.
It's been really encouraging
to see the open-source community,
start to invest in building the supporting frameworks
around my kind of modernization journey.
Because if I'm a developer that's reskilling
and I'm attempting to maybe modernize an application,
being able to dip into an open-source project.
I mean, a good example would be Tackled,
part of the Conveyor project.
>> Exactly.
>> You now have open-source-based tools
that will help you analyze your applications.
They will go into the source code,
and they will give the developer guidance
in terms of what would be effective treatments to undertake.
So, perhaps a development team
that are new to this modernization journey,
they would benefit from a project
like Conveyor, for example, because I need to know,
where can I safely modernize my application?
Now, for experience organizations like HCL,
that comes naturally to us.
But for people who are just starting this journey,
if I can take an open-source tool like Tackle
or the rest of Conveyor, for example,
and use that to accelerate my journey,
it takes a lot of pressure off my organization
but it also accelerates the journey too.
>> And it's not just a matter of tooling.
We we're also open-sourcing the modernization methodology
that we've been using in Red Hat Consulting for years.
So, this whole Conveyor communities,
it's all about knowledge sharing on one hand,
and building a set of tools together
based on that knowledge that we are sharing
to make it as easy as possible.
>> And what role does Red Hat play in all that?
You've carved out this position for yourself
as the true open-source company.
Does that position you for a leadership role
in helping companies make this transition?
>> I wouldn't say we should be leading the whole thing.
We kick-started it, but we want to get
other vendors on board for this thing.
One cool thing about the Conveyor community,
is that IBM is open-sourcing a lot of their IP.
So, IBM research is on board in this thing.
We have some really crazy stuff related to AI
being applied to application analysis.
We have some machine learning in place.
We have very cool stuff
that has been sitting on a corner
in IBM research for quite some years,
that now it's being open-sourced
and integrated in a unified user experience
to streamline the modernization process as much as possible.
>> So, let's talk about the elephant of the room.
HCL was leading the conversation
around Cloud Foundry, circa five plus years ago.
And as customers are thinking
about their journey to cloud native,
how should they think about that Cloud Foundry
to cloud native, or Kubernetes replatforming?
>> Well within the Cloud Foundry community,
we've been quite staunch supporters
of Kubernetes for quite some time
It's quite a stated intent of the Cloud Foundry foundation
to move across to Kubernetes platform.
Now, that is a significant engineering journey
for Cloud Foundry to take.
Now, we're in this position
where a lot of large users of Cloud Foundry,
have a certain urgency to their journey.
They want to consolidate on a single
Kubernetes-based infrastructure.
We see a lot of traction around OpenShift, for example,
from Red Hat in terms of its market leadership.
So, a lot of clients are saying,
"We would like to consolidate all of our platforms
around a single kind of Kubernetes vendor,
whether that's Red Hat or anyone else."
You know, quite frankly.
So, what HCL is doing right now,
with the tools and the solutions we've announced this week,
is we're simply accelerating that journey for clients.
If I've got a large installed-base of applications
running in my Cloud Foundry environment,
and I've also started to invest in standardize
on Kubernetes-based platforms like OpenShift,
most clients would see it as quite a sensible choice
to now try and consolidate those two environments into one.
And that's simply what we're doing at HCL,
we're making it very, very easy.
In fact, we fully automated the journey,
so I can move all of my applications
from Cloud Foundry into, for example,
OpenShift pretty much immediately.
And it just simplifies the entire journey.
>> So, as we start to wrap up the segment,
I like to know customer stories.
How are customers either surprised
or challenged when they get into,
even with the help of an HCL and Red Hat.
Where are they seeing the most difficult parts
of their migrations?
>> Well, my simple comment would be maybe complexity, right?
And the associated requirement for skilled people
to undertake this modernization work.
We spoke about this, of course
in terms of clients now are a lot more realistic.
They understand that their ambition now,
needs to be somewhat tempered by their ability
to sort of drive modernization quickly.
So, we see a lot of clients,
when they look at their very large
global portfolios of applications,
they're trying to invest their resources
in the higher priority applications.
The revenue generative applications in particular,
but they have to bring everything else with them as well.
Now, a common kind of separation point,
was we see a lot of clients who might say,
"I'm going to properly modernize and refactor,
maybe 5 to 10% of my portfolio
but the other 90% also needs
to come on the journey as well."
And that's really where replatforming
in particular kicks in.
So, the trend again, is clients saying to us,
"I've got to take the entire journey, all right?
I've got the resources and the skills
to really focus on this much of my application base.
Can someone simplify the overall journey
so I can afford to bring everything
on a cloud native journey?"
>> So, the key to success here is having a holistic view
of the application portfolio.
Segmenting the application portfolio
in different application types,
and ordering the priorities of these application types,
and come up with suitable migration strategies
for each one of them.
That's the key to success.
>> Paul: Is really necessary to move everything though?
>> Not necessarily. >> No.
>> Or not necessary.
Yeah, absolutely not everything,
but it would make sense, as we were saying before,
it will definitely move,
it make sense to move legacy applications towards Kubernetes
to leverage all the software delivery component-
>> That's big project, right?
>> It is.
>> If you're going to restructure the application
around APIs and microservices?
>> But it should be taken,
the way I've seen organizations succeeding the most
in this road towards cloud native and Kubernetes in general,
is trying to address the whole portfolio.
Maybe not move everything,
but try to have this holistic view
and not leave anything behind.
Because if you try to do this isolated initiatives
of bringing this or that applications in isolation,
you will miss part of the picture,
and you might be doomed to fail there.
>> Yeah, it's been my experience
that if you don't have a plan to migrate your applications
to a cloud native operating model,
then you're doomed to follow lift and shift examples
to the public. >> To the cloud.
>> Yeah, whether you're going to any other clouds,
if you don't make that operational transition.
Last question on operational transition.
We've talked a lot about the replatforming process itself.
What about day two?
After I've landed to the cloud,
what are some of the top considerations
for compliance observability,
Just making sure my apps stay up
and transitioning my workforce to that model?
>> I think the overarching trend or theme that I see,
is clients now are asking
for what I would call cloud native operations.
Now, in particular, there's a very solid theme
around what we would call reliability engineering.
So, think about Site Reliability Engineering, SRE,
Platform Reliability Engineering, PRE.
These are the dominant topics that clients
now want to engage HCL on in particular.
Because the point you make is a valid one.
I've modernized my application,
now I need to modernize the way
that I operate the application in production,
otherwise, I won't see those benefits.
So, that general theme of SRE is keeping us really busy.
We're busy re-skilling all of those operations teams
around the world as well, because they need to know
how to run these environments appropriately too.
>> And also being able to measure your progress
while your transitioning is important.
And that's one of the concerns
that we are addressing as well in the Conveyor community
with the tool called Polaris, to measure,
and to effectively measure
the software delivery performance of the organization
after the transition has been done.
>> And this is a really good point by the way,
'cause most most people think it's a bit of a black art.
How do I understand how I modernize my application?
How do I understand how I've improved
my kind of value chain around software creation?
And many people thought you needed to bring in
very expensive consultants
to advise you on these black arts?
>> Definitely not.
>> But in open-source projects
like Conveyor from from Red Hat,
the availability of these tools
available on an open-source model
means any engineer, any developer
can get these tools off the shelf
and get that immediate benefit.
>> Well, Alan Flower, head of Creative Labs at HCL,
and Ramon Nissen, senior product manager at Red Hat.
Thank you for joining "theCUBE."
You're now CUBE-alum, you'll have a nice profile,
like the profile pictures on there are awesome.
>> Absolutely. Thank you.
>> From Valencia, Spain, I'm Keith Townsend,
along with Paul Gillin.
And you're watching "theCUBE,"
the leader in high tech coverage.
(bright upbeat music)