 Hello everyone, my name is Deepukesh Ashidharan. Today we are going to see how we can build low-code microservices on the cloud with a service mesh using J-Hipster and Istio. So first, let's see what Istio is. Istio is a service mesh for distributed application architectures, especially the ones that you might run in Kubernetes. Istio plays extremely nice with Kubernetes, so nice that you might think that it's part of the Kubernetes platform itself. Istio isn't the only service measure. We also have platforms like Lingardy and Console, which are also quite popular. So what exactly does a service mesh like Istio do? A service mesh provides features to help with common distributed microservice challenges, like service discovery, routing, load balancing, and so on. Istio specifically provides the following features. Secure service to service communication over TLS, of course, with the support for identity-based authentication and authorization, service discovery so that your microservices can discover each other. Automatic load balancing for the services. Traffic control features like routing, circuit breaking, retries, failovers, and fault injection. A pluggable policy layer that can enforce stuff like access control, rate limiting, AB testing, traffic splits, coders, and so on. It also provides automatic metrics, logs, and traces for all traffic within the cluster from ingress to egress and between ports. Let's take a quick look at Istio internals. The Istio architecture can be classified into two distinct planes. First one is the data plane. It's made of NY Proxies deployed as sidecast to our application containers. NY is a high-performance lightweight distributed proxy. It controls all the incoming and outgoing traffic to the container it is attached to. Second is the control plane. It consists of IstioD daemon and takes care of managing and configuring the NY Proxies to route all traffic. It also enforces policies and collects telemetry. It has components like pilot for traffic management, Citadel to manage security, and Gali to manage configurations. We can also use tools like Grafana, Prometheus, Kiali, and Zipkin for monitoring and observability as they work well with the telemetry provided by Istio. You can use this or your existing monitoring stack as well. We'll see more about these later. So Istio takes care of common challenges in the microservice architecture. But you may wonder, what does this have to do with low code? What about the application itself? How can we quickly build microservices, right? Enter J-Hipster. So first, I'm gonna brag about how popular J-Hipster is since I co-read the project. J-Hipster is the most popular rapid application development platform in the Java world. That's another way to say it's an awesome low-code platform, as in you don't have to write most of the code yourself. See, we do have cool stats and lots of numbers. If that doesn't convince you that J-Hipster is the best low-code platform, then the following are mobile. So J-Hipster can help you create simple monolith web applications, complete microservice architectures. It can generate your domain model or entities. It can generate CI CD pipelines and deployment configurations for the cloud or containers. There's more. But to cover everything that J-Hipster can do will be impossible to do within the time I have. Another important thing to note is that unlike many of the other low-code platforms, J-Hipster doesn't create a black box application with a spaghetti code. It creates production quality code that is better than or as good as what you might write. If you don't believe me, check out this on our quality rating for J-Hipster applications. J-Hipster is built by developers for developers. Hence developer experience is a priority for us while making sure we create code that adores to best practices in any given technology. And moreover, it's completely open source and free. Okay, enough talk. Let's build a microservice architecture for a e-commerce application. Let's take a quick look at the microservice application architecture that we are gonna build today. We have the Istio control plane taking care of policy, load balancing and so on. We also have the Istio ingress gateway that will route all external traffic to our applications. We have four microservices. First is a gateway application created by J-Hipster that acts as our GUI and authentication layer. The remaining are services that provides APIs to be consumed by the gateway. Each of our containers will have an envoy proxy as a sidecar that is auto-injected. We hook up Grafana, Prometheus, Zipkin and Kiali to the telemetry provided by Istio so that we have monitoring and observability for our cluster. Each microservice also has its own database. The gateway and product and invoice have a Postgres database while the notification microservice has a MongoDB database. It's not an overly complex architecture but it's also not that simple, right? So before we start, we need to create a Kubernetes cluster. I'm using the Google communities engine today and I have already created a cluster to save some time. As it takes around 10, 15 minutes and we only have 30 minutes for the talk. These are the commands that can be used to create the cluster from the Google Cloud CLI. The num nodes and machine type argument is important as we need a bigger cluster than the default that is created by GKE. So my cluster looks like this. It has four nodes. Next step is to install Istio on our cluster. I'm using the latest version of Istio, of course. But first we need to install Istio CTL CLI on our local machine. So you can use these commands to do that. I have already done this. Then we need to use the CLI to install Istio to the GKE cluster itself. So Istio provides a few helm profiles out of the box. So for demo purposes, I'll obviously use the demo profile. You can choose the production or dev profile based on your needs as well. The command should install Istio and set up everything required on our cluster. Again, I have done this already to save some time. Once installation is complete, we would need to get the ingress gateways external IP as we would need this later in the demo later. Let's also install the Grafana, Prometheus, Keali and Zipkin add-ons provided by Istio so that we have monitoring and observability. Again, I have done these as well to save some time. Let's see if all of our Istio components are ready and running. So I have K dash running here. As you can see, we have all of our components like Grafana, Istio, egress and ingress gateway, Istio D, Keali, Prometheus and Zipkin running on the Istio system namespace on our GKE cluster. Now that we have all the components running and our Kubernetes cluster is ready to work with Istio, we can move on to the application itself. But first, let's see the J-Hipster magic in action. Make sure to install J-Hipster by using the npm install-g generator-jhipster command. I'm using the main branch for the demo as there is a bug fix that is required for the latest version of Istio. It should be released soon in the next patch release of J-Hipster. If you are trying this out before the release, you can check the PR link below and apply the patch as it's a simple fix. Basically you have to apply the patch to your Istio virtual services and Istio gateway configuration. So next step is to download the sample JDL file. So JDL is the J-Hipster domain language. You can find the JDL file in this GitHub link as well. You can also refer to the JDL docs on J-Hipster website to learn more about that. I don't think I have enough time to go all over JDL and everything. So we'll just take a quick look at the JDL instead. So JDL is pretty straightforward. Here is how an application definition looks like. This is a gateway and notification microservice, for example. You can refer the JDL docs for all the parameters that is available for application, but basically these are the important ones that is required to configure an application. As you can see, the first one is the gateway microservice and the second one is the notification microservice. They're slightly different as you can see. Entity definitions are straightforward as well and can be defined in the same JDL file. Here are some of the entities in this demo. They're quite JPA-like if you're familiar with the JPA Hibernate. You can define enums, entities, relationships and additional entity related options like pagination, your service type, and so on. Finally, we can also define deployments in the JDL. Isn't that neat defining an entire microservice tag in one file? Of course, you can split it into multiple files as well if you like. So let's go ahead and download our JDL. I'm gonna create a new folder. Okay, I'm gonna run JHitster download. So this is a sample file that is available in the JHitster JDL samples repo. So I'm gonna download that. So it has been downloaded. I'm gonna open VS Code here. Okay, so this is the JDL. We have our store application, which is the gateway. We have a product microservice, invoice microservice, notification and all our entities. Some entities like customer is the only entity for the store gateway since it is related to the user which is used for authentication. And all the other entities are distributed across different microservices accordingly. And finally, we have the deployment definition itself. So once you have downloaded the sample, you need to update the ingress domain and the Docker repository name fields as those don't have a value here and you would have to provide your own values for this. You would need a DNS for ingress domain. I normally use nip.io for demo as it's free and handy wildcard DNS, but we want that it's not a good idea to use nip.io for non-demo purposes as it could pause our security rules. So make sure to use a proper DNS in a real application. But for demo, I think it's fine. So I'll use the external IP of the Istio ingress gateway here with the nip.io wildcard DNS and my own Docker repository. So I'm gonna provide my own Docker repository here, which is this and let me get the external IP of the ingress gateway. So our ingress gateway have this as the external IP. So I'm gonna copy that and I'm gonna provide that. So nip.io would automatically route all requests coming to that IP to our local host and that's it. So our JDL is kind of ready. So now we can begin to see the J Hipster magic in action. We just need to run the J Hipster JDL command. So I'll be running J Hipster JDL with the application name hyphen hyphen fork. So the fork argument is optional. It's just to make sure make everything, all the applications be generated in parallel because by default JDL will try to generate everything one by one. So that's gonna take a bit more time. So I'm gonna use the fork option. It's gonna take a minute to complete as it will create all our applications, run npm install on the gateway application and generate Kubernetes and Istio manifest for all the applications. It even prints useful commands at the end to continue with our deployment. That's neat, right? Normally at this point I would go through the applications and walk you through a generated code, but I don't think I can fit that into the demo today, but feel free to download the JDL that I used here and run J Hipster JDL command to see the generated code. We should look quite familiar if you're a Java developer. So as you can see, it created few folders here. We have the invoice microservice here under the invoice folder. As you can see it has created everything required for that. We have notification microservice, product microservice and the store gateway. We also have a folder where the Kubernetes configurations would be generated. It hasn't been done yet as the application is still being generated. As you can see, yeah, it has completed and as you can see, it has printed out for the commands required to deploy our application and the Kubernetes folder has been filled with all the manifest that we require. So each of the application folders has its deployment manifest, it has its service, it has the database configuration for that particular application, its secrets are defined here and Istio specifically, it has the destination rule defined and for the gateway itself, we also have an Istio gateway definition here with its virtual service and everything required for routing and for the microservices itself, similarly, they will have their deployment configuration for the application itself, destination rule from Istio, their database configurations, service, virtual service and secrets. So our applications are kind of ready. Let us build and deploy everything using Gradle and Jib. Jib is a utility for faster Docker builds for Java applications. It's all set up by J-Hipster so you don't have to worry about it. So let's go into each app folder and run the build command. So I'm going to CD store and I'm going to run Gradle W, bootjar-p prod, so we want to build it in the production profile using Jib and I'm going to push it to an image in my Docker repo and then I'm going to CD into product, Gradle W command for the same but make sure to use the correct image name for that. And I'm also going to go into invoice and run the same command there. And finally, I'm also going to run it for notifications. So CD notifications, Gradle W. So that should build and push all of our applications to Docker. As you can see, the store has already been built and pushed. The, I think invoice is pushed as well. So all our applications are built and pushed. I'm going to just close these. Close these terminals. So the next step would be to apply this, apply the Kubernetes manifest to our cluster. So that because our apps are built and pushed to Docker, right? So let's deploy them to our GKE cluster. So J-Hipster also generates a batch script. As you can see here, it generates a handy batch script that you can just run to apply the file. So what it does is it creates a namespace. It labels that namespace with Istio injection so that whenever you deploy something to that namespace, Istio sidecars will automatically be injected to those. And then it applies each of the configurations in each of the application folders. And finally, it applies whatever is in the Istio folder. So that, which is nothing but gateways and virtual services for Grafana, Kiali and Zipkin so that we can access them in our application. So I'm going to run that Kubernetes and then apply kubectl, apply.sh. hyphenf is one of the options because you can also use the same script with customize if you like to use customize to make customizations or with scuffold, if you like that. So because J-Hipster also by default generates settings required for scuffold and customization as well. So you can use that if you prefer that. There is also, you can also generate helm-based configurations with J-Hipster or K-Native-based configurations with J-Hipster. So the deployments has been pushed. So let's go back to parts and watch our name, J-Hipster namespace. Okay. I mean, I'm using K-Dash to watch for the ports and everything but you could also just use a kubectl. So as you can see our services are starting up. They are still not ready as you can see most of the applications, they need to pass two ready checks. They are still, only one has completed. Notification is ready. We still need to wait for, okay invoice is ready. We still need to wait for store and the product. So that's probably gonna take a minute. Okay, our store is ready. So I think we can already start looking into the applications. So when you deploy using the script, it also prints out all the URLs that would be required. So, okay, now all the ports are ready now. Except product, I think, but I think that's fine. We can just go ahead and start looking through our application. So let's open our store. So this is our GUI or the gateway application. So let's sign in using the default credentials which is admin, admin. Of course, Chrome would complain about that, but that's fine for a demo close. So let's take a look at our entity. So as you can see, this is the default J-Hipster application. It's a gateway. You have all your administration stuff that you could expect from J-Hipster like user management, your metrics, health monitoring, your configurations from Spring Boot and your log management and stuff. And of course, your settings, password and stuff like that. So let's take a look at the entity. So the customer entity is served by the gateway itself and we also have the product entity which comes from the product microservice. So let's try to create, we need to create a product category first. So let's try to create a product category. Okay, save. As you can see, we have created a category and we can also just create a product using that. Now you can upload images if you like, but I'm just gonna skip that and we have created a category. As you can see, look at the ID here. So this is a incremental number because it's a JPA-based entity. But if you go to notification and if you create an entity here, 1051 was the entity we created. If you create a notification, you can see the ID is quite different as it's a UUID because we are running MongoDB database here. So that's our application invoice. Yes, we have our invoice entity, shipment entity from the invoice microservice, of course. So that's the entire microservice application running on Istio. Now let's, so now we have a fully working microservice application with four services and their databases all talking to each other. But a complex microservice stack won't be complete without some monitoring and tracing. So let's see what we have for that. So we can, so let's open the second link which is, let's look at Zipkin first. So this is a distributed tracing from Zipkin. If you run the query, you'll see all the network calls that were happening. So you can trace all network calls in your infrastructure. So let's take, look at stuff for invoice, for example. So if you see this, we can clearly see what calls are being happening, what services are being called and more metadata. So if you have issues and if you require tracing, you can use Zipkin to do that. And next would be Grafana. So the Grafana dashboard is pre-configured with Istio. So let's take a look at some dashboards, service dashboard, for example. Let's take a look at one of our, what can we look at? Product maybe? Yeah. So if you look at the service dashboard, you can see data for data from the Prometheus provider that is pre-configured because this is all based on pre-configured metrics from Istio through Prometheus. You can also configure your own. There are also other handy dashboards like performance dashboard and what else? Control plane dashboard, the mesh dashboard itself and your workload dashboard. So yeah, we have all this. And finally, we also have Kiali. So Kiali is specifically, so Kiali is used to visualize and troubleshoot the mesh service mesh itself. So there's a lot more that can be done with done or on observability with Istio, but that would need a separate session on its own. So that's why I'm just quickly running through this. So with Kiali, you can look at the service graph, for example, so last 10 minutes, for example. So this is all the connections that is being made in our application. You can see we have the gateway, which is talking to Zipkin, which is talking to invoice, which is talking to product, it's talking to store, it's talking to Grafana, notification, Kiali and everything. So this is all our network stuff. And you can also see the applications that we have, the configurations and the Istio specific stuff that is running on it. You can see the workloads, if you can see if there are any issues, there'll be alerts if there are issues and way more. So I hope this demo gave you a taste of what is possible with Istio and J-Histar. And this is all, and remember, I did all this in way less than 30 minutes. So imagine what you can do when you have more time. So if you do try out this demo, make sure to delete the clusters afterwards so that you don't end up with a huge bill. You can simply delete the cluster from Google Cloud console or using the CLI. So finally, we have the questions. Is a service mesh worth it? A service mesh provides building blocks to build distributed microservices in a more Kubernetes native way and takes the complexity and responsibility of maintaining those blocks away from you. This means you do not have to worry about maintaining the code or deployments for service discovery tracing and so on. We are moving towards a future where the only code we want to write is business lodging and tools and services fill the other aspects of the architecture. And this is evident from the rise of local platforms and tools like GitHub Copilot and so on. A service mesh also helps in this regard. This lets you worry only about the application that you are developing rather than the infrastructure and with J-Histar, that future is truly here and you just need to worry about writing your business logic. While a service mesh is nice, it's not a silver bullet. Keep in mind that Istio is a complex software and debugging and developing locally may not be as easy as it sounds. Also, another thing to keep in mind is that is the resource requirements. The same microservices without Istio can be deployed to a two node cluster. Whereas with Istio, you need at least three or four node cluster with more CPU and memory. The Kubernetes manifest that I use from the Istio demo profile isn't exactly tuned with the request limits and everything. But if you tune those, probably you can reduce the overall requirements somewhat. But I don't think you can still get it as low as that is needed for a non-istio option. So in a real world use case, the advantages of not having to maintain the complex parts of your intro versus having to pay for more resources to run something like Istio might be a decision that has to be taken based on your priorities and goals. That's it, folks. Thank you for attending the talk. If you can learn more about J-Histar at these URLs and if you have any follow up questions, you can reach out to me via Twitter. Thank you. Bye.