# Report Cloud Computing
- Ayten Deyab, Victor Malai, Pia Döpper
### Github repositories
Gateway: [here](https://github.com/Pia314/CC_microservices_gateway)
Invoice: [here](https://github.com/Pia314/CC_microservices_invoice)
Productorder: [here](https://github.com/Pia314/CC_microservices_productorder)
Notification: [here](https://github.com/Pia314/CC_microservices_notification)
Docker-compose: [here](https://github.com/Pia314/docker-compose)
Kubernetes: [here](https://github.com/Pia314/kubernetes)

### Generate and deploy a microservices architecture
Installing the packages of JHipster and npm caused difficulties at first, but after setting the version of npm correctly, as well as using the appropriate version in the project with ``nvm use`` we started building the microservices part.


We were able to browse the service registry to check that our apps were successfully created with JHipster.
Here in the dashboard can see the different instances of the application as well as the general health of the microservices.

Here are some more specific application metrics and information concerning the threads, CPUs/System and Memory information.


The Dashboard is automatically monitoring the different HTTPS request.

Here is an overview of the API from the services, which are really practical for web developers to directly see them without searching in the codebase for them.


In the next screenshot, you can see a different view of the health check of the application.


Generally these automatically monitoring of jHipster is really helpful concerning the SLA and as a help for the developers to comply with the SLA and detect errors/failures.

Then we browsed through the application. We could see that if the application failed or crashed, the monitoring changed the status to down.

The next step was to refactor our application into 3 independent microservices. So that the one-to-many relation between the ``ProductOrder`` and `Invoice` is set to in `invoiceId` at the `ProductOrder`.

We checked if the mongo DB is working and went through the Docker Images Part.
Here we created Profiles at the Docker site and installed the Docker Desktop version. Here we had big problems and it took us several days to figure out that the command in the tutorial to create the Docker images doesn't work and after hours of research, reading the docs and the code we then figured out that we can create the image with the following command. It was also necessary to be in a logged in Docker profile because otherwise we ran into permission errors all the time.

`` ./gradlew bootJar -Pprod jibDockerBuild -x test ``

After creating the docker images we arrived at some difficulties, because we weren't able to execute the commands with `docker-compose`but only with `docker compose` even though we had installed both versions. After finding this solution, we then managed to create all Docker images including two instances of the invoice app.



### Tutorial on Microservices Architecture with JHipster :: Deployment with Kubernetes

The next step now is to deploy our microservices in using Kubernetes and Docker. After reading the instructions on Docker and Kubernetes, we logged into both profiles and started the deployment. We initialized a cluster in GCP and copied the Docker images. The next difficulty was that we get numerous error messages when running the deployment commands. There was now the issue of having to first install Prometheus and Grafana in GCP to enable the monitoring we had selected in the JHipster console. Since there was no instruction on how to do this in our tutorial, we debugged the code and tried to figure out why our deployment was not working. In the process, we had shot up our cluster so badly that we had to recreate it in GCP before we could deploy it. After running the commands with a new cluster and a better understanding of the deployment process, everything worked. We managed to deploy the microservices on the cluster.


But nevertheless, we had an error concerning the autoscaling in the pods. We tried several ways to configure them, but they were still massive and we couldn't force the system to use more than 5 pods. One of the methods used to resolve the problem was to enable the autoscaling for the pool of pods, which did not work, unfortunately. Afterward, we have observed that there was a huge amount of resources used by the microservices. We thought that a good idea would be to delete the cluster with the deployed pods, re-create a new cluster and try to deploy everything once again. When deleting the cluster, we observed that the resources stayed allocated, so we completely deleted everything to free everything. Moreover, our Billing Account for Education was automatically canceled for no reason, so we switched on our personal trial billing account. Finally, when trying to re-create the cluster (using the usual command of gcloud), we had the error of insufficient regional quota to satisfy the request for the CPU and SSD_Total_GB resources. Unfortunately, we did not find a solution to this problem. An idea was to ask Google Cloud for a big quota, but we did not get an answer after filling up the form for upgrading the quota.