 Hello, and welcome back to the stage. We're here for our next session. I'm David Van Belen, and our next session is around using Quarkus Funky to deploy Java serverless functions to multiple clouds. This will be presented to you by my colleagues Jorge Valderas and Ever Romero. They are both senior consultants here at Red Hat. As a reminder, you can ask questions in the chat. We'll set aside some time to answer them. And this session will, again, be recorded and made available on the Red Hat Developer YouTube channel, so you can watch it again after DevNation is over. So without further ado, I'll turn it over to Eber and Jorge. Take it away, guys. Yeah. Hello. Now, we are Ever Romero and Fluxer Valderas. Today, we work a little bit with useQuarkus Funky to deploy Java serverless to multiple clouds. We do a little pass-through about Quarkus. And after that, what is Funky? We explain some of the many capabilities of that. And we do a little demo for how to use Quarkus and Funky in a hybrid cloud. If you want to get followers in the different social network. And if you want to get the current project source, you can use the George GitHub in Funky multi-cloud repository. I know the agenda is what is Quarkus. What is Quarkus Funky? And we'll hand demo. OK. Today, I start before you to spend a light of innovative technology in the revolutionary world of hybrid cloud computing Quarkus. Quarkus is not just another framework. It's an image area in the realm in the cloud computing, especially in the context hybrid environment. So let's delve into the reasons why Quarkus is without a hybrid cloud freeze. And for most, Quarkus means a parallel specific field to hybrid cloud deployments. Traditional cloud application of its server from high memory, user, and slow startup items. Which can be problematic when relying with the hybrid cloud architecture that require quickly scalability and responsibilities. Quarkus, on the other hand, both an impressive combination of the small memory footprint and blazing fast startup items. This means that it's not only optimized resource utilization but also enables rapid escalation and elasticity my kid if it's perfect fit for hybrid cloud scenarios. Another reason why Quarkus is essential for hybrid cloud is native cloud capabilities. And it's typically for the hybrid cloud environment and mix of hyper-analyzed infrastructure. In that case, we have the different elements of different moments, how to build in the past the different scenarios or different frameworks. The Quarkus way use more effectively the room time and do really quickly and respond functionality workloads. Quarkus achieved this by using of innovative compute line approach, reducing memory consumption, and optimization room time performance. Compared to the traditional frameworks, Quarkus offer superior efficiency, stability, scalability, and enable the organization to maximize resource utilization and deliver responsible application. And in the native cloud capabilities, Quarkus is built from the ground up with the cloud-native principles in mind. Simply integrates with popular cloud-native technologies like Kubernetes, containerization, and serverless computing. Quarkus provide native support for these technologies, allowing developers to easily build, deploy, and manage application across hybrid cloud environments. But leveraging Quarkus organizations and sort their application are cloud-native by design, enable them to fully utilize the benefits of hybrid cloud architectures. Now, after this brief about Quarkus, what is Quarkus function? Thank you, Heather. So let me go ahead and share my screen. OK, you should be seeing my slides, if not either David or Heather just please interrupt me. So thank you for the Quarkus overview. I'll now go over and cover what exactly is Quarkus funky. So Quarkus is a portable Java API that can be used to essentially write several of its functions using Java that can be deployed to multiple, essentially all the major cloud providers. So namely, specifically Azure, AWS, and Google Cloud, that it can also be deployed as a serverless function using Knative. So that's ideal for a Kubernetes cluster, OpenShift, or if you're targeting either in the cloud or on premises, that's where Knative comes into play. And it can also be deployed as a standalone service. Even if it's using serverless, that's like a fifth option if you wanted to do that. So we won't cover when you should use serverless. There was another great talk about serverless computing a couple hours ago by Steve Tran and John. I strongly recommend you guys check that out if you miss it, once the video is available. But what I want to cover here is when you should consider using Quarkus funky. So the idea is that you've identified that you want to use serverless, that you have a good use case, a good fit for serverless. Obviously, that's not always the case. But if you fall, you have one of those use cases where serverless is a great fit, then when should you consider using Quarkus funky? So if you're trying to target multiple cloud providers, this is definitely a great fit. Or if you're targeting hybrid, so you have some things that are maybe on the cloud or on premises, you have a combination of that. And then, or maybe you have plans to swap cloud providers in the future, or you don't want to be tied, like, to one vendor, Quarkus gives you that flexibility, or specifically Quarkus funky. And then the other big selling point I would say is if you want to minimize your learning curve. So I'm going to show you essentially how you would write a serverless function in all for all these cloud providers. And you'll see that, even though it's like serverless, the serverless function, you'll see how there's variations between all these implementations. So when should you not use Quarkus funky? So there are a few limitations, right? Because Quarkus is one way to think of it. Quarkus funky is kind of the common denominator across all these clouds. So that's how they provide this portability. So it won't give you access to everything that you would have for a specific cloud provider. So specifically, namely more like low level access to APIs that are specific to your cloud provider. It's also not a full replacement for service. I mean, you can certainly use it. But if you want to expose the full serverless API, then this Quarkus funky may not be the best way to do it. And I explain why. Quarkus funky infers your methods and they end up exposed as a rest or as a get or a post method so you don't have full control about what method gets used. Like for instance, you don't get delete or puts. And then not every like all HTTP features are available. So similarly, like low level specific features in the case of HTTP are not going to be available. So if you need any of that, you know, Quarkus funky may not be the best option. So how do you get started with Quarkus funky or Quarkus in general? So obviously if you're new to Quarkus, I recommend you to check out Quarkus.io that has great information about Quarkus, like quick start tutorials. It also has a link to this UI, the code Quarkus.io and that's great to get a project started. So you fill out this form and then you have the option to download start a project and then you choose what Java version that you're trying to use and maybe Java versus what build tool you want to use, whether it's Maven or Gradle, along with other functions like specifically what libraries, what extensions you would like to you, including your starter project. And I included just like a subset of the funky specific libraries, but in general, if you're trying to do, even if you don't use funky, if you're doing any cloud development at all, like for AWS, Azure, Google Cloud, I strongly recommend that you check out the extensions that we have available about the Quarkus offers because it really is a time saver. I've done a lot of development in my case for AWS and it was really a time saver because you don't really have to know a lot about the details. I mean, it really does help you get started and it saves a lot of the boilerplate code that you would have to write otherwise. So here's now let's get into some of the specifics. So how do you write an AWS Lambda in Java? So here's a very simple greeting Lambda that's implemented and there's an interface that you have to implement the request handler and that's a stray from the AWS SDK. That's not Quarkus specific, but then, you know, Quarkus uses the built-in, you know, Java CDI dependence injection that's built into Java. That was kind of like in the Java X namespace. Now it's in the Quarkus 3.0 that was moved to the Jakarta because that's using the Jakarta E specification. So these annotations, that's what I'm talking about, the inject and the name annotation, those are part of the Java built-in CDI. So fairly simple service here. So you have an entry point. This is your handle request method. And then from here, you would call your, you know, your application layer, your business layer. In this case, this is a simple greeting service that just returns an output back. So how do you write the similar function in Azure using Java? So you can see how this is the same, like a, you know, a gradient function that's been effectively the same. And you can see how there starts to get a little more complex. I mean, nothing wrong. I mean, that's just how they implemented functions in Azure. So that's also a little more I'm never handling here, but it gives you the idea how there's these differences that if you're actively developing to providers, then there's gonna be a learning curve for both of these. And then the third flavors, the Google Cloud Functions, again, similar function, I mean, the same function, similar code, but it's likely different. So now you have three flavors of the same code using effectively doing the same thing. And then the last example for K-natives, that's also also fairly somewhat complex compared to the others, but still for doing something simple, you know, there's about 10 lines of codes that you need to write for this. And it would be very depending on your cloud provider. So now how does this look in quite, if you were using Quarkus Funky, that's it, right? I mean, this is it, like you essentially use the adfunk annotation. And then here's the service, it's just calling the same service method and returning an output and then the same injections, so CDI injections to inject your service. So it does simplify a lot of things. And then, I mean, especially if you're targeting like the two or more of these cloud providers, and it will save a lot of time, and especially if your development and it minimizes your learning curve. So now let's get into the demo details. So what we did is we essentially wanted to showcase that, hey, you know, you have the same code base, can you deploy to these multiple cloud providers and K-natives as well. So the way we started this program was using this maven command, which is the equivalent of what you can do in the code quarters IEO. That one will give you a CIF file that you will start striking your local directory. This will just essentially generate those files in your local file system. So it kind of saves you one extra step. So it's just a matter of preference, but this was kind of the starting point for the template for our demo. Obviously we added more code to it. And then the other approach was because, you know, this, when you deploy it, it's even though it's the same Java code the dependencies are gonna be different. Like you need to include your cloud specific libraries. So your Google Cloud library for Google Cloud functions or your Azure functions or your Lambda functions. So that's why we have, or the approach we do was to essentially create a, kind of like a specialized POM file. The POM file is in maven. That's where you define your Java dependencies for those unfamiliar. You could do the same with Gradle. And then essentially using that POM file is the same code base just a slightly different dependencies because you don't wanna bake in all the, you know Azure libraries into an AWS deployment that wouldn't be a good practice. So with this specific POM files then you can generate different jar files and then you would deploy that to your specific cloud provider or to your Kubernetes cluster. So now let's actually get into the demo. I'm gonna showcase the AWS and Azure and then we'll switch back to Heather who'll do Google Cloud and Knative. So let's, well, not quite done yet. So can still see if I can see the screen or maybe not. Okay, no, no, please. They didn't share mine. Yeah, I can, I can, I guess I needed to re-share my screen as I switch to the slides. You can, you can. Is that, that's my, right? That's, sorry. No, it's just a little bit, a little bit like, can you, can you see my screen now, Heather? No, not yet, okay. Let me, let me just try it again. Oh, sorry, I was, yeah, I needed to do this entire screen. Now I got it. Okay, is it now sharing the, so are you seeing the GitHub? Yes. Okay, thank you. So yeah, so this is that link that I share on the chat. This is essentially we'll give you the instructions how you wanna, how you can build it locally, this project. And then, like I said, this is instructions that's specific to Azure and then London, each cloud provider, along with any, any prerequisites that you want to, that you may need to, like if you don't, if you're not doing AWS, it's usually the CLI. In this case, we're also using SAP for the deployment. So let me start there. I'm gonna start with the AWS deployment. So I'm gonna show that I'm gonna call the, this is the AWS CLI, so I'm calling the STS service with getColorIdentity just to confirm that I'm indeed locked in. So I did that, oh, sorry, it's typo. And yep, that's showing that I'm there. I'm already locking. So now I'm going to just follow the instructions. I'm going to do a maybe clean package. So that's building, rebuilding, I'm skipping tests. The one important theme I wanna highlight here is that I'm pointing to that from AWS, from a specific that has the dependencies that I need to deploy into AWS. So next I'm going to use, so for those not familiar, if you're doing landed wellness, you need to use SAP, which is kind of like a specialized CLI and templates for deploying serverless artifacts. And what that will do, it's essentially generates at the end of the day is a CloudFormation template that's being generated. So here I'm gonna just, I'm using the guide as I'm gonna set the default parameters. Except for this one, I have to say, yes, this is okay. And then this is gonna start my deployment. So it's essentially taking that jar that I built and then it's loading into an S3 bucket and then it knows how, by using some, it knows how to tell London to use that, upload a jar from the S3 bucket directly. So now if I switch to my console and then I go to the CloudFormation, which is the templates that you would use to deploy any artifact to AWS, I should see, so here's my, they call them stacks, right? So here's the stacks that shows how, they deploy the resources that are being created. So it starts with a role, it's going to, well, this tells me, like, and it's a Lambda and then it requires an HTTP, an API gateway in front of the Lambda to expose the HTTP. So while that's going, let me just jump into the code for a little bit. So here's our function, right? This is really, that's it. Like there's a greeting service. We did include an additional function here because you can have multiple functions in the same deployment. You may not need that, but in this case, just to show it's a demo, so that's okay. So one thing, what I was showing that when you see this method that has an input, so the funky framework will infer this and it will automatically make it a post operation because it knows that it needs an input. If it doesn't have any parameters like this function here, this hello, this is just a get, right? But you don't really have control as to say, oh, I want this to be a delete. So that's what I meant earlier about not being a full rest replacement. So the other thing I wanted to highlight here for those not familiar, and this has nothing to do with Quarkus, sorry, with funky is just in general, Quarkus gives you this capability that will actually generate this SAM template for you where just by building this jar with the libraries, it will generate this SAM template that you can use to just say, hey, go ahead and deploy this. So if you don't know how to deploy a serverless function, this is a great way to get started, right? So you can see how this is using the, it will generate the JVM. So as Heather showed, you have the JVM builds or you can also use the native build. So if you both flavors that you can use, it's just gonna be a different command line. And I did include on the read me, here's the native build. I'm not gonna show that around this here because it does take a few extra minutes to do the native build, but we can see now that our deployment is completed. So I'm going to export this through an environment variable named URL, and I'm gonna export this. And then I'm gonna use my, I included like a test command here that you can use. The first one is just doing a simple get with a Quark command and it's including the time. Now you notice this is actually the start of the call start. So it does take like six seconds, but if I just rerun it, then it's taking like, it's a lot faster, right? Because it's already kind of like warm up. So now let me just show you and the example of the post method, which is essentially the function that does take a parameter. And then I'm passing AWS and it's just gonna echo back like hello AWS. And this is already one of warm up. So it's all these response times are gonna be sub seconds. So just a quick, showing you the resources we have refreshed this style, you can see how generate a Lambda function here and also an API gateway that's front-end in the Lambda function. And that's just like an AWS specific requirement of how they expose or how you can expose Lambda functions. And that's the function deployed. So now let me quickly switch gears to the Azure demo and so let me switch to this step. I already have these parameters exported. So if you're running this one with your own account, just make sure you populate those values. So I'm gonna do AC login. I should already be logging in, but just to show that it's locked back in. And now I'm gonna use the this main clean package. So Azure, this demo is the only one that's a little more different than the other, or at least the AWS Lambda and Google Cloud are gonna be very similar. In that we're using like the CLI provided by the vendor to deploy. In this case, we're actually using an Azure plugin. I may even plug into deploy. So that's why that command was a little different. And while that's going, I wanna show you just the difference. So if I compare the palm files of AWS and Google Cloud, just to show you how really the only difference is that library, right? That Amazon Lambda or Google Cloud. Now, if I compare AWS with Azure, that is gonna be a little more different, but that's just because of, we're using that Azure plugin, right? That's really, it just needs more information, more parameters about how to deploy it. But for the most part, it's just gonna be that library that's really the main difference. And yeah, this is Azure specific parameters. So let's, this is still, okay. So now this is running. Let's see, it's not deployed here. We may need to, let me try it one more time. And then if not, we'll just skip this demo. I tried before, right before the call. So not sure why I wanna fail. But I mean, the idea is the same. Like once it gets deployed, now you have your Azure function deployed. This looks a little better. And then it's just gonna show up here as a function app. And let's check question so far. Let's do a quick refresh here. So once this is deployed, I'll use the same command just to kind of like show you the hello word. It only really takes a minute. If you have any questions in the meantime, feel free to put them, drop them in the chat and we can answer along the way. No, the token should be valid. I think it's working this time. I just, this is a step that takes the longest. Okay, we may wanna maybe switch, you wanna switch over to your demo and then we'll can come back to it if we have time at the end. So I'm saying good. Best stop. Can you see my screen now? Yes. Perfect. Yeah. We now start with a Google function. The idea is really similar. We use the same code artifact that users for AWS and Azure. The only difference is now that we add, we've got the different elements or the different configuration in the palm structure, but really the application is the same. Let me show, currently I use the same application that users for deployed out of that different elements. And how to deploy that? We need to, we need, currently I completed the need of my laboratory but currently I show how to configure that. Okay, in that case, I use the same configuration for that service. Now I need to choose the service for that. Okay. Currently I choose the project that I need to use for that. The current project is that. I configure that project in the Google Cloud. And now the idea is deployed, the current function with the current parameters. We can use the Google Cloud function deployed for our cloud function. In that case, CenturyPoint is the same quad-pointy PCP because it's focused to the Google Cloud. The function is HTTP quad-code function because it's the function that currently I want to deploy and at the rune time, the tiger. And in that case, a little authentication because I link it with my Google Cloud dedication. And in that case, it's in the target deployment that I need to create in that. Let me create that artifact. This artifact is with the same code for our different clouds. And now I deploy it with the Google Cloud query. So minutes for deploy that of different elements. Let me go with my screen. Feel free to ask any questions on the chat if all this is going on. Perfect. Now we have the application deployed in that URL. Let me add this URL for use in the consumption mode. Now I deployed in Google Cloud that application and only need to do this application. If your time take a little bit more time, in that case, it's four seconds. Well, let me consume the other context script and reduce. If I test again a URL, hello, we can see that the timing is really less because it only takes time when it started the first server element or serverless part. OK. And now for deploy, the Knative, we can use the same code that you can see in that part. But only the important thing is use, in that case, OpenShift with the Knative Cli and OpenShift Cli for different elements. How about OpenShift? In OpenShift, you need to create or you need to configure the serverless operator because we need to use that serverless operator for deploy all of that different serverless artifacts. What is the important configuration that you need to be present to deploy in the Knative service? That case is Knative service. You need to create one of that for deploy your different applications. The configuration is simple. In the newest version of that operator, you need to deploy it into the Namespace Knative service. But in the last versions, you could be changed that Namespace. OK, this is the configuration that you need for deployed serverless over OpenShift in the Knative way. Now we go to the code. Now, they just create the project from Knative. I was creating this project. The project is already. And we need to deploy that code. I need to use it. I use different Knative please, for the reason I use that. But we need to create a correction for the application. OK, it means the font part, the font deploy of UN security. Now the image is building. OK, in the well, if you have any questions, and this is just to point out that this is using the function, the font.jaml, that tells us how to deploy. So in this case, we're actually doing this in terms of time. It's actually pushing an image that's already pushed to Quayer. It's a public image, so anybody can also deploy that. But you can change that file if you want to deploy. You can tell how to build it. And I will actually build the image with your code and deploy it to the, in this case, to OpenShift. Yes, yeah, and this is a really important thing for use this kind of strategy. Because we get four important capabilities talking about the hybrid cloud capabilities. In Quarkus and Funky, it's built from the ground with cloud service principles in mind. And Polyglot support, because we can deploy the same artifact in different clouds and support multiple programming languages. In that case, you don't need to create in the different languages or different frameworks for the cloud. And you reduce your resource processing in your cloud and your cloud allocations. It's resource optimization. And you do the developer productivity. OK, OK, let me change. Is it using like a different jam, like funk jammer? Because it shouldn't be the same. Yeah, I forgot to change my way, Funky. OK, and I think we're close on time, so we may need to. Yeah, OK. OK, of course. All right, thank you so much, Jorge and Evert, for that really informative presentation. It's really great to know. We could do server lists with Quarkus on OpenShift. Now it's coming to the other public clouds as well. So we can run it on AWS on Azure and on Google Cloud as well. So as a reminder to everyone who's with us and thanks for joining us again, this is being recorded, and we will make it available to you on the Red Hat Developer YouTube channel. So thanks again and do join us for our upcoming sessions, both on this stage and on the other stage as well that are happening in parallel. Thank you, goodbye.