>> From around the globe, it's The Cube,
with digital coverage of Red Hat Summit 2020,
brought to you by Red Hat.
>> Hi, and welcome back, I'm Stu Minneman,
this is The Cube's coverage of the Red Hat 2020,
bringing you guests from Red Hat
and their partner ecosystem, practitioners,
where they are around the globe,
bringing to them this digital event,
and while we wish we could all be together in person,
we'll just be together apart for 2020.
Happy to welcome to the program, a longtime Red Hatter,
but first time, on The Cube, Rich Sharples,
who's the senior director of product management
inside Red Hat, Rich, thank you so much for joining us.
>> Yeah, thanks for the invitation, great to be here.
>> All right, so the topic we're going to talk about today
is something you've got a long background
of the middleware space.
But in, Quarkus so,
I personally was not familiar with Quarkus.
Obviously we know, god, I believe someone told me once that
there's like, 2 million open source projects out there,
so I believe I can be forgiven for not having
every one of them memorized there,
but of course anybody in our community
is going to know Java.
What a huge impact that has had on the industry.
Linux and Java are two of the, you know,
major movers of how we, you know,
build an, you know, deal with application today,
so give us a little bit of a framework
as to what Quarkus is, you know, why it was created.
>> Yeah, so it's no secret
that as organizations and developers
move to this kind of new styled cloud native development,
developing applications running in containers
or in a kind of serverless environment
that Java is not necessarily the best fit.
Java does many incredible things,
it's an amazing field of engineering.
But many of the coolest things it does,
assumes that it's going to be a long running application,
it can do this cool dynamic class loading
and dynamic optimization as the application runs.
Those things are pretty impressive,
but they're also fairly, very heavyweight.
And in our kind of ephemeral environments,
whether containers or functions of service,
you don't have long running applications.
And you can't make use of those things,
so in a Java environment you pay
for those radical features
that you don't necessarily get any benefit from them.
So, you know, where we're really trying to lay focus
is ensure developers to continue to use Quarkus,
it's still the, you know,
the dominant language for enterprise development.
You still get the benefits of these new architectures,
so ensuring that Java continues
to be you know, performant and efficient
in these new you know, constrained environments.
>> Okay, excellent, so we're not calling it
cloud native Java though, right Rich?
But we are bringing,
if I heard right, Java for things like containers
Kubernetes, I even heard functions as a service
so, we're talking to server lists
of you know, open shift server lists something
that's being talked about this week.
So help us understand you know,
if Java was long in the tooth.
You know, what stays the same,
what's different,
how have people been managing
and you know building applications in this environment,
because obviously you know,
we've been dealing with containers
for a number of years now,
so what have they been doing so far
and, you know, why is Quarkus different
from some of the alternatives that are out there.
>> Really, the goal is to introduce those
that stayed the same.
It's not a different language, it's not a fork.
It is Java, you're writing Java applications,
essentially in the same way you used to write them.
And you may be using Microsoft still functions
so slight difference in terms of design,
but it's, you know, we want to ensure
that you can bring your favorite frameworks
and wipers with you as well.
When you're accessing databases or message brokers.
We want to ensure you can still use those technologies
so we're trying to bring the whole ecosystem with us,
with Quarkus, so those things can run well,
in a you know, container or service environment as well.
And that's super important
because the real benefit here
is any organizations face the choice of
I want to develop cloud native,
I want to develop functions,
but I've got this huge investment
in Java in terms of skills
and you know, tools and tool trains
and I don't want to go learn a new language,
just because I need to you know, take advantage
of things new environments
so we're essentially giving developers
their cake and allowing them to eat it.
We are trying to provide the best of both worlds.
Stick with the language you already know
and you know, have lots of experience with,
and still be able to get the benefits
of running in our containerized environment.
>> Okay. what are some of the challenges here,
so you know from an infrastructure standpoint.
My background is, you know,
virtualization broke a lot of pieces
and containerization does the same thing.
As you mentioned, things you know, spin up really fast
and they don't stay on nearly as long.
You know, god, you mentioned functions as a service,
often we're measuring things in milliseconds,
so everything genomes,
understand what's up how do I manage it,
how do I monitor it all of those pieces so, you know,
I understand you're saying
we take the skill set and what we know.
But, you know, there's got to be some on ramp here
and some considerations
>> Yes, so, yeah, absolutely so,
Red has taken on the ramp
and ensuring that this ecosystem moves with us.
We do a lot of hard work within Quarkus,
so developers don't have to.
We do some very, very clever stuff
that very few organizations, would be able to do
because they don't have the depth of knowledge
of the Java virtual machine that we do.
We're able to take a lot of things
that you'd normally start off once only,
like loading classes and you know,
building kind of memory data around,
all the kind of reading configurations
all of the things applications do once and only once.
Why do it another time?
Why not build that into the component time,
you're going to do it once
but take it out of your runtime environment completely,
so there are many ways
where we're having to kind of rethink
the way you know, applications run.
We have to do a reset
on what job was built for this environment
of long running applications where,
if the application took 10 minutes to load up
all the stage area and classes and config,
it didn't really matter,
because it's not going to run for 36 months.
You got to do a resale on those design decisions
and think very very differently
and given with our deep experience
with containers and you know,
working on things like native, serverless
and on deep, deep roots in Java, we were able to do that
and really think differently.
So, Quarkus takes a lot of that kind of
work away from developers
they don't have to think too much about it.
And by and large,
what they can do is focus on their applications
and their micro services
and read all of that wiring and optimization for them.
And hopefully deliver some you know,
real significant improvements
both in development productivity,
but also the kind of runtime resource utilization as well
to really lower costs.
>> Okay, and Rich, what's is great
that's been really the nirvana
when you talk about developers is
they don't want to have to think about
some of that underlying you know, gobbledygook.
That was why you know,
the term serverless is so polarizing
is because from a developer standpoint
I don't think about this
but everybody screams, but there are servers
and there is networking and there's you know,
things underneath that I need to think about.
So, what is the underlying assumption here.
We talked about you know, containers,
Kubernetes, functions as a service,
what integration is done there?
Does this live across?
Is it kind of like, you know,
does it sit just just on RHEL and therefore
everywhere the RHEL lives it's there?
Or, help me understand kind of
what that underlying you know, substrate is.
>> Yeah, right now our focus is RHEL x86,
'cause that's kind of the dominant platform in a cloud.
It is just Java, some have that natural kind of portability
and you know, as other architectures become important,
we can certainly look at those as well.
The reason why the underlying machine architecture
is important, is because one of the options
you have with Quarkus
is actually the ability to compile everything down
to a binary executable, right?
That may give you some additional footprint reduction
and performance enhancements.
And also if we compile down to native,
we do need to think about the underlying operating system
and the architecture.
But by and large, as a developer
you really don't have to care.
Just like to you don't have to care with Java today.
You also have the option with Quarkus,
to run on conventional JVM,
open JDK is our preference
and if you can run on open JDK,
then you can pretty much run anywhere.
Under you know, different reasons
for compiling down a native,
this is running on a traditional JDK,
different optimizations,
different trade-offs that you'd like to make.
>> All right, so Rich,
an open source project here,
can you tell us a little bit about you know,
who's contributed to this, you know,
what general adoption is this,
and, you know, where are we
with the solution today.
Is it today ready for production environments?
>> Yeah, it's getting close to production ready,
yeah, we'll be making this Germany available
and during Summit
and many of the components we use are tried and tested,
again we're not reinventing everything from the ground up.
We leverage things like REHL VM,
we leverage open JDK,
we leverage all our frameworks and library,
the developer that are familiar with,
we just have to optimize them for Quarkus,
so, yeah, much of this is not brand new technology.
The existing technology
that has that kind of maturity and tolling support.
So yeah, we're confident it's production ready.
One of the early stages of the development of Quarkus,
was to use some of Red Hats own products as goody picks.
Actually, you know, optimize those products
for containerized environments
by rebuilding them on top of Quarkus
and that gave us obviously a lot of insight
into the general readiness, yeah,
the whole kind of eating around and dog food principle.
In terms of the organizations in investing Quarkus,
you know, we have this kind of have old addedge,
we often use at Red Hat,
which is you know, if you want to,
if you want to move quickly, go alone.
If you want to go far, then go with others.
We're at a stage, where we've been developing
Quarkus very, very rapidly
and that's mostly been a Red Hat effort.
We've certainly got some help from the mothership IBM
and I expect that to be an increase overtime
and we're now in a point
where we have a Germany available product coming up
and we're ready to really kind of expand the ecosystem.
So, we're looking for you,
whether you're a framework provider,
you've written a framework for Java
and you want to have that Quarkus provider,
ensure that runs really well
and partly the kind of growing ecosystem around Quarkus,
we're looking for that,
we're for, you know, cloud providers
to you know, take this technology
and see how it runs in other environments
and give us feedback.
So, yeah, definitely looking to expand that
ecosystem of contributors,
so we can really turn this into
kind of the facto technology for the cloud.
>> So, Richard, stop back for us for a second,
you've got a long history with Java.
You know, why in 2020 is you know,
Java still, I believe it's like number two
on the language list there.
Why is it so important today
and why is moving forward to all of these cloud solutions
so important for that ecosystem.
>> Yeah, I think it comes down to you know,
organizations are faced with a tough choice.
That they stick with the language that they know and love,
which is Java, the language, the relevant applications
for the last decade
and not be able to take the best advantage
of cloud and native or serverless environment.
Whereas if they go and learn a new language,
Datalog or No.js
and you know, kind of hunt around
and trying to see if that has the same
kind of ecosystem and support.
So, we want give organizations a better choice,
which is you can stick with a language
you already know and love
and you have skills and the resources,
yeah, you can still take advantage of these new environments
and that's you know, I'm mean, fundaments the problem
we're trying to solve for your customers.
That twice open source projects are,
they live or die, depending on,
they really do scratch an itch,
you know, fulfill a need with real developments.
I'm going to think we've certainly from the adoption
and interest we've seen with Quarkus,
we really do think we've found a very real problem to solve.
>> Yeah, Rich, before we wrap up,
I just want to give you the opportunity,
you know, how is your teams doing,
I think you know, Red Hat's making a real concerted effort
to make you know, an appropriate tone
for the event this week.
Trying to make sure it's not you know,
some of the usual glam that we normally expect to see,
full on the community all together,
but, you know, the community is so important
and you know, the network of people
that, you know, built not only you know,
technologies but also careers
and you know, relationships,
so, give us a insight as to how your teams doing,
everybody in these challenging times.
>> I think this is another good example
of where open source really does show it's resilience.
Open source projects are simply very, very distributed.
No open source projects rely on an office being open,
so your word distributed team
all used to work using distributed tools
across the world, different time zones.
It's kind of natural for us,
so we're kind of plugging on, you know,
just as we have them in the task,
you have a few more dogs in the background
and crying babies
and you know, we're all humans, we all tolerate that.
We have great support from our leaderships,
that's Red Hat and IMB.
They're very clear that they've got people
and families before revenue and that's good to know.
Everybody's you know continuing as they can
to you know, ensure that we have
you know, great technology out there
'cause like I said there's real demand here
that needs to filled and we're going to continue doing that.
So, yeah, everybody's kind of holding up pretty well,
so, let's just see how long this thing goes
but again, I do think it is a valuable
kind of lesson on the resilience
of distributed teams and open source in particular.
So, yeah.
>> All right, well thank you for that Rich.
Just to bring it on home,
as you said, the general availability of Quarkus
you know, is in front of us here,
really expecting the ecosystem in costumers move.
Give us a little bit of what we should be looking at
going forward, what are some
of the kind of maturity steps
and what should we expect to see,
through the remainder of 2020.
>> Yeah, it's going to be a pretty exciting year,
I mean, given the changes we were all going through
we are going to try and come meet developers, where they are,
which is you know, on their laptops
and in front of their computers,
so, we're going to do, we're playing through a bunch of
you know, kind of very quick webinars,
you know, quick bye what it takes,
you know, interesting features,
we're going to do some virtual hackathons as well,
so you can actually get people with time
and talk with some experts.
We have platform for doing that.
So, we're pretty excited,
we, you know, again with the incident,
we can reach a lot of developers very easily.
Actually far more than we could at a live even like Summit,
so, we're going to make the best of it
and try to get at to as many developers
as we can with Quarkus
and you know, hopefully they'll repay us
by investing a little bit of time into it
and giving us some feedback and you know,
trying some applications and you know, see how it goes.
>> All right and you know,
final, final question for your Rich,
you know, Quarkus, I have to imagine
that the Quark, the subatomic particle,
you know, came into the naming there.
Is there some connection with that?
I guess why the name to the project?
>> Yeah, I mean that's pretty much it,
you know, the Quarkus you know, kind of.
(mumbles)
Arguably the smallest fundamental particle.
>> And can we find something smaller?
>> Well, there potentially is something smaller
but that's kind of in the realm
of quantum mechanics and physics,
which I'm not an expert on,
so, but yeah, it's meant to mean small
and the us bit, the US bit.
I'd like to think there was
a really good big meaning around that.
The meaning is that we understand,
that trying to do any kind of brand leadership
or trademark protection
on a well know server like Quark, is it possible?
So, we had to add something to Quark
and Quarkus kind of sounded cool.
>> All right, Rich Sharples,
pleasure to catch up with you,
congrats on the progress for Quarkus,
definitely looking forward
to watching it's progression in the future.
>> Thanks, great talking to you.
>> All right, I'm Stu Minneman.
Lot's more coverage here at Red Hat Summit 2020.
Thank you as always for watching The Cube.
(gentle music)