OpenJS Foundation OpenJS World 2021 - Development, 2 Jun 2021

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Application Modernization with Camel JavaScript and OpenShift - Ip Sam & Wuxin Zeng, Red Hat

Description

Application Modernization with Camel JavaScript and OpenShift - Ip Sam & Wuxin Zeng, Red Hat

Apache Camel has been used widely for messaging queue integration and notification. The light way and simple Camel coding structure make it a good choice for developers. The Camel technology is used widely during application modernization. Camel also integrates very well with OpenShift forthe CI / CD pipeline and the deployment process. In this presentation, we will go over the architecture of Camel, and how Camel can be used with JavaScript and deployed to OpenShift. We will walk through a few example of application modernization and review the performance gain using Camel Javascript with OpenShift.

Join the speaker for live Q&A on Slack: Wednesday, June 2 from 16:20 - 16:40 PDT / 01:20 - 01:40 CEST, channel - #openjs_world-development

A

Hi everyone, our talk is on application, modernization with camo, javascript and openshift. My name is washing zhang. I am an associate consultant at raha and my co-pilot of my presentation is eep sam, who is an architect of a hat.

A

So application modernization there are five parts to application: modernization for service endpoint. We migrate web services to apis for architecture, migration, modernization. We want to break down monolith into standalone microservices because they are easier to maintain and to share the code to modernize development process. We want to modernize waterfall approach to ci cd.

A

So then you can release on a daily basis like actual transformation and for deployment we'll want to modernize virtual machine on-prem to containerize images and, lastly, for infrastructure. We want to move data center to cloud.

A

Integration points before, on the left hand, side we have a big cluster of dependencies, it's hard to cut out a piece of the application to modernize, because in order to modernize an application, you also need to identify the dependencies to modernize.

A

At the same time, and now we have this graph on the right hand, side that shows, once you have an application to modernize, you can create clusters of dependencies, meaning we are breaking down the dependencies into smaller, multiple clusters, so, instead of having one giant cluster depending on each other, we have small clusters of dependencies and doing so. We can maintain low risks.

A

So camo, what is apache camel apache canal is an upstream project that we use for integration technology arahat apache camo is java, based based on enterprise integration patterns. Apache camo started its life as an implementation of the enterprise integration patterns book. It comes with 300 components. Out of the box. You can use.

A

Integration can range from simple timer to log dummy examples to complex processing, workflows, connecting several external systems.

A

Kml has built-in data transformation, intuitive routing and provides native rest support.

A

Integration patterns as developers, we know that the module applications is deconstructed into smaller pieces. The more you need um better communication patterns for managing all the inherent complexity.

A

Pmo has been shaped around enterprise integration patterns, simpsons, inception and developers have created a.

A

Dsl that often maps patterns in a one-to-one relationship. These patterns are agnostic of programming, language platform architecture and provide a universal language. Notation and fundamental messaging and integration.

A

Kml continues to evolve and adding new patterns from service oriented architecture. Microservices cloud native and serverless camo has become a journal, pattern-based integration framework suitable for multiple architecture.

A

I am not exaggerating if I state that camo dsl is the language of enterprise enterprise integration pattern, it's a language that expresses better than most of the patterns that were present in the original book of integration with other patterns that have been added by the community during all these years, and the community keeps adding patterns and new components in every release.

A

In this slide, you can see that we have a split orders pattern that splits the order from a larger order and have each item be sent to either electronics or other areas.

A

Apache camo is a powerful integration library that provides lots of integration connectors. As you can see, there are hundreds of java libraries that used camo connectors using this camo and point notations. These uris are also universal.

A

Here are more examples of camo camo components. You can google camo components and you will find a lot of them.

A

Camera routes so, like I said before, kml has multiple domain specific language for dsl. It supports xml, java, groovy, kotlin and, of course, javascript.

A

There are good reasons to use both java and xml dsl camo route expresses the enterprise integration patterns. It gets the developers into thinking in terms of pipes and filters.

A

For instance, the dsl is a technicality that will not impact the success of project. You can even mix and match. So in this slide, you see that this is a one-to-one integration between a file and a jms queue around time. It does not matter for camo whether you write it in xml or java.

A

So more examples here from a file called inbox. We split the body based on its line for each of the lines. We turn it into a custom xml and for each of the xmls we send it to an active mq called activemq called line integrations are great for connecting systems data transformations as well as creating new micro services.

A

Rest dsl camel also offers a rest styled dsl, which can be used with java or xml. The point here is for end users to define rest services using a rest style with verbs like get post, delete and etc. The rest dsl supports the xml dsl, using either spring or blueprint here, to define a state path.

A

We can set the base path in rest, say and then provide the uri template in the verbs. It also accepts data format, setting.

A

Okay, let's talk about camo javascript in this sample, we use javascript function to create and predicate in a message filter. The message filter is enterprise integration pattern. It allows you to filter the messages. Obviously, for example, if the predicate is true, the message will be routed from qa to qb this route path, routes, exchanges from an user to a special queue. We can write this in spring dsl as well.

A

Here's another example of camo javascript.

A

As you can see, the integration written in javascript is very similar to a java one here from the timer tick process. The function that prints hello, camo, k to log info to run it you just have to execute camera run and the name of the file.

A

For javascript integrations qmlk does not yet have an enhanced dsl that you can access to some global bounded objects in this sample. We're using contacts.get component of the previous log component and use exchange formatter property to do something like this.

A

Camo script, contacts jsr223 lets, you use the power and flexibility of scripting languages like ruby, groovy and python. On the java platform, kml supports a number of scripting languages which are used to create an expression or predicate via jsr 223, which is a standard part of java. 6.

A

javascript context is extremely useful when you need to invoke some logic. There are now in java code, such as javascript gui or any other languages.

A

Properties is the attribute of camel script contacts, as you can see here before camo 2.6 2.9. If you need to use the properties component from a script to look up property placeholders, it is a bit cumbersome to do so.

A

However, since camel 2.9, you can now use the properties function, and this in the example is much simpler here. In this example, function with the resolve method makes it easier to use chemical properties component from scripts.

A

You can also load scripts from external resources. You can do so by referring to external script files, for example, to lay a groovy script from the class path. You need to prefix the value with resource, as shown panel dependencies to use scripting languages in your camera routes. You'll need to add a dependency on camera script which integrates the jsr 223 scripting engine.

A

Here, if you use maven, you could just add the following to your palm.xml file, substituting the version number for the latest and greatest release, and you can see the download page for the latest versions.

A

So with the introduction of camo and how camo supports javascript, let's talk about camel k. Klok is a deep kubernetes. Integration for camel camel k runs natively in the cloud on openshift kmlk is designed for serverless and microservice tech architectures for those who are not familiar with camo k. Camo k is the sub project of apache, camel, with the target of building a lightweight runtime for running integration code directly on cloud platforms like kubernetes and raha openshift.

A

So we learned that qmo is a swiss knife of integration.

A

Kmlk is for serverless camo for kubernetes and native, and we also have camo corcus, which runs on top of quarkus and enables developers to write small, fast java applications.

A

We also have camo carafe camo spring boot and camo kafka connectors. These are all the apache camo 3 projects.

A

So apache camel k configuration in order to run kmlk um you'll need access to a kubernetes or openshift environment.

A

However, chemok works best when is run natively on k native k native is a simple pre-built component to publish and subscribe from the event mesh.

A

Let's take a look at the performance of camo k. Chemo k, runtime provides significant performance optimizations. This graph is shows the performance of camel k without utilizing k, native and serverless technologies compared to binary source to image deployment. Kmlk has lower, deploy and reach the redeploy time. If the binary runs remotely, it is even slower notice that the redeploy with camel k is almost instantaneous.

A

So how does kmlk work well developers just want to deal with the business logic and not deal with the runtimes and all they want to integrate systems and become serverless.

A

What they can do is to write camera routes in a single file. For example, here we have a camera route written in xml and how does it work with openshift and kubernetes piece? Well, at this point, with camo k, you only have an integration file.

A

This file is says from some sort of timer every second route id set a header and send it and log it.

A

So once we have a cluster prepared and the operator installed in the current name namespace, then we can say camel run with a k.

A

Kmlk comes with a command line, tool called camera with a k, so camo run and you can do camera run and then the name of the file, the cli, can automate the text on the developer's machine, such as observing code changes streaming, those to the kubernetes cluster printing, the logs from the running, pods and etc.

A

Note that you don't have to specify any dependency specification in the folder that you wrote. Your integration.guv file, because kmlk will figure that out for you and then inject it during the build. So all you'll need to do is just write. The application in this case the camel binary, will push it to the cluster and the operator will do all the tedious footwork for you at first at your first, the first time you run your application.

A

It might take up to two minutes to start since it needs to pull and build the image for the first time, but the next bill will only take a few seconds once it started. You can find the pod running this application on openshift.

A

Here is what the pod looks like on the openshift console the pile runs in the cluster. This can also be done with openshift ci tools as well once logged into the openshift cluster. The kmlk cli will then use that to run the integration on the openshift cluster in this project and deploy it from here.

B

So next, let's talk about how to deploy javascript on openshift, so the deployment for openshift is based on containerized images. So the first step is to identify and find the base image for your javascript application.

B

You could find it from the docker hub or quay.io or gcr.io right, so so the image needs to match your specific javascript version, and once you have the image you could start working on your docker file um and and then with the docker file, you could do the docker command to build the application image. Basically, this is a s2i process that will merge your code from your git repository with the base image that generate a new application image for deployment.

B

So this is the high level architecture of how the deployment work with the camo camo k application. On your on the left side on the box, you have your local machine, your dev environment. You have your ide and once your coding is completed, you do the use the camo cli command to uh execute uh the the program.

B

What it does is, it does do a live update to um to basically trigger and send an update to the cloud on the right-hand side. It will trigger a notification to the camel k operator in open shift. The the operator will get notified and then deploy the latest change to the port based on the integration definition.

B

Otherwise, the surface architecture is autonomous. It's loosely coupled right. In the modern days, people have talked more about micro services.

B

The idea is that we want to make the microservices single cup a single responsibility, single purpose, stainless right, all these specific application programs. They will be moved away from the micro services and kept in some sort of persistent volume, claim or databases right. Each microservice is independently scalable and they could also be independently automated and then on the far right-hand side. We have surface-less architecture right surface is based on single action right, and this is also temporary.

B

So when we talk about camo k native profile, um so this is an example of a workflow. On the left hand side you have some sort of um you know. Chemo definition um you see from um from the form attribute. You see that this is getting the information from the native channel and then the two attributes saying that it gets an information from k native channel and send the information to the specific http my host api path. This is a very simple camo definition.

B

You put this into a mo file right. This mo file has an integration as a kind right. The api version is using chemo.apache.org version one alpha, and this is an example of a yamgo file for deployment in openshift right.

B

So once you set up the ymo file, all you need to do is to pass this along to the chemok operator. When the chemical operator got notified, the operator will look at the file and make a decision. Is it a k, native profile right? If this is yes, this is a k native profile. Then it will generate a new emo file, set the kind to surface and then use that new file for deployment right.

B

If this is not a k native profile right in this case, this is just a deployment object right then it will generate the new deployment kind mo file based on the information and use that for deployment yeah. So this is a high level architecture of how the chemical operator would work surface and k native.

B

So now it's really important to understand how we could apply k natives to surface less surface is basically is an execution model where the code is executed by a dynamically allocated resources.

B

When you have the core available trigger notification and the resources got spin up to execute a specific piece of code right serverless remove the need of traditional deployment model right. You know the traditional ways you always need to have some sort of server component that will deploy to handle the specific deployment, but serverless talk away. That concept right. Everything is on demand right.

B

K native is an open source kubernetes based platform to help you deploy and manage serverless workflow.

B

So between. um When you talk about k native, we need to define the different component, the building blocks of k, native right for the surface application. So k native contain two pieces uh serving and eventing right serving is based on your surface object.

B

You could scale to zero when I don't need you to to use the surface right or it could scale up to as many instances as it need when, when you have a peak at the traffic right and- and this is the service model- is a request driven dev uh compute uh model. When I need it, I will ask for it and when I don't need it, I will scale to zero. Eventing is based on the event binding right when you have a specific event come in right.

B

uh Usually a lot of time is coming from a messaging queue like the kill, come in and say: hey, you know we need to do this specific operation right when that event comes in k native will spin up the resources required to do the computation for the events right. So each building block is a crop operation right with a controller and that manage the life cycle.

B

So in k native serving, for example, we have a camo script coming in where it's doing a rest call doing a post to a specific path. And then you have two y2 system, one to system two. So, basically, in in when this script comes in, you'll create a kubernetes namespace inside the namespace. You have the um the k native surface that will spin up right, there's no container if no one is using it right. So so this is all on demand right server.

B

Let's also help you reduce the operational cost right, much faster deployment to the market. uh It helps you reduce packaging deployment, complexity and then at the end. Right is a flexible, scalable, on-demand solution, and you can see this chart on the left on the right right. The left side shows a traditional I.t organization, how much they were overpaying right majority of the time on the yellow line. Right, your demand is on the red line, but you were. You need to basically have a 20 30 margin to make sure that you cover the demand.

B

When there's a peak on the day of thanksgiving right, you are not able to meet the demand right, so this is a. This is a traditional problem of predicting the usages and and computational resources that a lot of itb departments were having difficulty.

B

um Camo k, stay between um microservices and surferless right, underneath that you have corkers right quarkus. It's also an important component that is also kind of between microservices and serverless, and k-native is completely surface right um and then you have streaming am q messaging q. Those are working, you know, could be both microservices and serverless, and then, underneath that we have open shift so the event driven computation is happening between the messaging queue, k-native, camo and qualcas for microservices.

B

We want to ensure that the services are have granularity and security for distributed integration right.

B

We want to be able to set up different containers when right when we discover services available, the container got spin up right and then, at the same time, you have container that coming on on the other side of the picture, where um you need to track the api transaction management using saga right um and then you can see why this container uh application architecture could get very complicated because you have, you could have container in different size of the architecture diagram and then at the end right.

B

They all need to communicate to some sort of centralized databases on the right-hand side. um So so, when this type of distribution application comes in right. So what are the best practices to handle this right yeah? So here we talk about a saga pattern that we use um heavily for application. Modernization right. uh The cycle pattern work like this right. You have multiple surface surfaces. You have surface one surface, two service three and service four right. Each surface has its own uh compensation uh object associated with the with the surface.

B

So what happened is when you have surface one, making a call to surface two right and then, as one surface two make the call back to surface one, and then you need to make the call to surface three and then come back right each each step. The compensation um object will get notified right in that situation. uh It could um basically hand um based on the request and response.

B

uh You could make a decision right. Should it continue making call in the orchestration surface orchestration or should it go back return the return, the call back to the caller and do something else right. So this is a very useful saga pattern that that can help handle surface orchestration.

B

You can see we can uh set up a set of uh integration point between the saga and the camo right and- and the first saga is basically saying that I I'm making a population um to towards uh to the to to the south, to the uh make to make the service call, and this is a mandatory uh uh propagation right and then in the compensation model, um you can say direct cancel booking right.

B

So this is my compensation model and then two right specify where this is coming to this come to a specific sql database and it is doing a insert into the flight table with the specific value right.

B

So you you can see your saga can be set up in a way that it, you know in a camo, camo format where you can. um uh You know, specify the the the source, the destination, the condition right and and what to do to handle specific uh accept exception right. uh So the lower section of the saga is the same thing as well. We set up the header. This is http, header is a post and then you're posting the two requests to http endpoint.

B

So for the source to image deployment right, you usually get the record from the git repository and then from there. We as soon as the coca push we push to the port. uh We we merge the code with the basic image and generate an application image for deployment.

B

So the configuration injection is a common pattern where we can inject the specific configuration during the deployment. So, for example, in openshift we have the config map. Configmap is an object that whole key value pairs.

B

So when we deploy the application for application one, it pulled the information from the config map and used that information for deployment for application. One and similarly application two followed to follow the same design pattern. um Openshift operator uh contains uh an example of the red hat, open shift, surface and once surface is click on. You can go here and specify if you want to do a basic install.

B

If you want, you can specify specific version like, for example, I want to do a version 4.6 for the operator for the openshift surface. Once it's installed, you can see that the the install operator is in your screen here.

B

In conclusion, camo k is a lightweight integration framework that one natively on openshift chemok is also designed for serverless and microservices architecture.

B

The k native ad component for deploying running managing surface cloud native application in openshift, the serverless cloud computing model uh lead to an increase in developer productivity, reliability in the cloud deployment and reduce operational cost, camel k and k native provide a fast and scalable solution for application, modernization, architecture and camo integrate integra with different technology. Different languages with reliable results, sean we are coming from red hat consultant team. If you guys have any specific question, please reach out to redhead consultant.