Hi Thanks for running us through the whole process. But please help me to understand the added value of the Imesh portal? Considering GitOps is the golden standard, creating things with a UI is not the best practice. The best practice here would be to use ArgoCD or any other CI/CD tool to apply this gateway and route manifests by syncing with a git repo. All things you did via UI can be achieved by applying a simple k8s manifest, so why add cloud cloud-based service to your setup. Furthermore one would expose his microservices directly via public IP on the Loadbalancer to the internet meaning that these LBs IPs should not be accessible from the internet at all. So I'm wondering what use case would make use of this imesh cloud service offering legit ? BR Joseph
Thanks, Joseph. You have rightly pointed out that GitOps is essential. And we do 100% support GitOps. IMESH Platform supports two deployment models- GitOps-based and direct deployment. For GitOps-based, the IMESH platform translates the UI form into YAML. After that, the usual GitOps-style delivery process is initiated with software like Argo CD. For startups and lower environments- where the concept of CI/CD or GitOps is not yet practiced, IMESH API gateway would be handy for them to easily create and manage north-south traffic in the cluster from the simple UI with direct deployment option. Reasons for our low-code platform are: 1. Many developer teams think it is a context switch to learn YAML. 2. Creating network resources and policies involves a high learning curve (as one must remember all configurations). 3. Creation/editing of manifests often leads to errors & debugging issues, which is counter-productive. 4. Enhance the visibility of all the network resources in a single pane of glass. 5. The DevOps and cloud team would know who created/managed what resources. 6. Real-time view of performance of network resources with just one click.
Hi
Thanks for running us through the whole process.
But please help me to understand the added value of the Imesh portal?
Considering GitOps is the golden standard, creating things with a UI is not the best practice.
The best practice here would be to use ArgoCD or any other CI/CD tool to apply this gateway and route manifests by syncing with a git repo.
All things you did via UI can be achieved by applying a simple k8s manifest, so why add cloud cloud-based service to your setup.
Furthermore one would expose his microservices directly via public IP on the Loadbalancer to the internet meaning that these LBs IPs should not be accessible from the internet at all.
So I'm wondering what use case would make use of this imesh cloud service offering legit ?
BR
Joseph
Thanks, Joseph.
You have rightly pointed out that GitOps is essential. And we do 100% support GitOps.
IMESH Platform supports two deployment models- GitOps-based and direct deployment.
For GitOps-based, the IMESH platform translates the UI form into YAML. After that, the usual GitOps-style delivery process is initiated with software like Argo CD.
For startups and lower environments- where the concept of CI/CD or GitOps is not yet practiced, IMESH API gateway would be handy for them to easily create and manage north-south traffic in the cluster from the simple UI with direct deployment option.
Reasons for our low-code platform are:
1. Many developer teams think it is a context switch to learn YAML.
2. Creating network resources and policies involves a high learning curve (as one must remember all configurations).
3. Creation/editing of manifests often leads to errors & debugging issues, which is counter-productive.
4. Enhance the visibility of all the network resources in a single pane of glass.
5. The DevOps and cloud team would know who created/managed what resources.
6. Real-time view of performance of network resources with just one click.
Regarding public IP concerns, the IMESH platform does not need any public IP to be exposed in the client cluster. It works in reverse.