Let's create a new folder for this microservice stack. Let's call this folder e-commerce-app-istio. Make sure you are outside our existing e-commerce-app folder. Navigate into the folder and copy the JDL we created earlier for our application:

> mkdir e-commerce-app-istio && cd e-commerce-app-istio
> cp ../e-commerce-app/app.jdl app.jdl

Now, we need to make some small changes here. First, we need to set serviceDiscoveryType to no in all the application definitions. This removes the JHipster Registry and Eureka-related code from our applications. We won't be needing these as we will use Istio for that. Our new architecture is as follows:

As you can see, we have replaced JHipster Registry with Istio, and JHipster Console with Istio's monitoring setup. Our applications have the Envoy proxy attached to them as sidecars (meaning it runs in the same pod as our application container). There is a new Ingress Gateway in front of our store gateway. This Ingress is the only entry point into our application and you can see that routing is now handled by the Ingress Gateway and our application gateway is just another microservice.

Next, we can define the deployment option in the JDL. Earlier, we used the Docker Compose and Kubernetes sub-generators, but the same can be defined using the JDL as well. 

Similar to other JDL options, it's a simple syntax (you can learn about all the supported options here: https://www.jhipster.tech/jdl/deployments):

deployment {
  <deployment option name> <deployment option value>
}

For our new application stack, let's define the following deployment option at the end of the JDL file:

/**
 * Deployments
 */

deployment {
  deploymentType kubernetes
  appsFolders [store, invoice, notification]
  dockerRepositoryName "deepu105"
  serviceDiscoveryType no
  istio true
  kubernetesServiceType Ingress
  kubernetesNamespace jhipster
  ingressDomain "<IngresIp>.nip.io"
}

We have defined a Kubernetes deployment that is similar to what we generated earlier. The only difference is we have set serviceDiscoveryType to no, set the kubernetesServiceType as Ingress, and enabled Istio. We also need to set an ingressDomain, but we cannot do that yet – let's see why.

When we set the Kubernetes service type as Ingress, it would need a valid DNS name to be provided as an Ingress domain. If you already have a registered DNS, you can use that here and map it later to our actual Ingress Gateway that would be created by Istio; otherwise, we can do this only after creating our cluster and deploying Istio to it.