Here is the list of features that will be released at end of this year.
Complex applications would have front-end microservice and backend microservices. Backend microservices may be distributed across multiple clusters. This feature enables connectivity among the microservices in different clusters by automating the ISTIO configuration. Also, it automates the configuration of the ingress proxy to expose the frontend microservice to external users and route the traffic from the external users to the frontend microservice. As a test case, we will use EMCO to deploy Google's Online Boutique which consists of a 10-tier microservices application. This application is a web-based e-commerce app where users can browse items, add them to the cart, and purchase them. Google uses this application to demonstrate the use of technologies like Kubernetes/GKE and Istio. The feature will ensure that EMCO can deploy these microservices properly and can set up a communication channel between these microservices seamlessly through integration with Istio. The work involves creating helm charts for GMS, deploying GMS, automatically creating data traffic controller intents for the GMS, and interacting with Istio control plane to deploy the intents, inject envoy into each microservice POD, and set up the network communication between the deployed microservices as well as the network communication from external users to the frontend microservice.
Helm provides a hook mechanism to allow the users to specify additional action/logic at certain points in an application's life cycle. Helm supports pre-install, post-install, pre-delete, post-delete, pre-update, and post-update hooks. Add support of these hooks in EMCO. For example, if the user specifies some resources at the pre-install hook in the Helm chart, EMCO will deploy those resources in their appropriate order before deploying the application.
Azure Arc, Google Anthos, AWS GitOps all implement a GitOps way of deploying applications to K8s clusters. That is, when the CI/CD or users write an application in a git repository, the sync agent in a cluster will be notified of the new application and will read the git repository, and will send the app to its local K8s API server. For geo-distributed applications, intelligent and on-demand deployment, as well as automatic setup of network connections between these apps, is needed. EMCO can act as an intelligent entity that adds intelligent deployment decision to the app in the git repository. Selected clusters' sync agents can be notified at the right time to read the app for deployment. In this release, we will support the integration of EMCO with Azure Arc. That is, after EMCO makes the intelligent decision, EMCO will interact with the Azure Arc to program the selected edge cluster's sync agent to pull the application to its local cluster.
Current EMCO's status notification is a poll model. That is, the user needs to explicitly call the EMCO status API to get the status of an app. Some users don't like to poll for the status on a periodic basis. EMCO needs to provide a mechanism for the users to automatically get notified whenever the status of an app changes. EMCO will provide a "status notification" registration API in which a user or a microservice can register interest for one or more apps' status change notifications. This new API will allow the user/microservice to specify appContext and notification criteria (e.g. any change, change for a set of resources across a set of clusters). EMCO will notify those entities when there is a status change
There are cases where one application can not run until another application has been deployed. EMCO will support this inter-dependency between applications. A new API will be added for the app to specify its dependencies. This API will also allow "optional" specification of delay after the depended app is "Ready"/"Deployed". EMCO will make sure an app is deployed after its dependent apps are properly deployed or are in a "ready" state.
Referential integrity for EMCO data resource means the following rules must be satisfied:
- When a data resource is created or updated, any resources referenced by this data resource must already exist.
- A data resource can not be deleted if it is still referenced by another resource
EMCO framework allows the dynamic addition of new controllers to the EMCO control plane (for example, you can add a new GPU capacity-based placement controller). EMCO will support referential integrity associated with any new controller. That is, when a new controller is dynamically added, EMCO will automatically build the cross-reference relationship associated with the new data resources created by this new controller and enforce the referential integrity associated with the new data resources.
EMCO supports multiple clusters to be grouped as a Logical Cloud. This release will add support for Logical Cloud labels (which will support K8s namespace labels), JSON-based logical cloud API validation, and logical cloud status query API.
These features have been created and tracked in GitLab: https://gitlab.com/project-emco/core/emco-base/-/issues
- All Enhancements (and higher impact) for 21.12: https://gitlab.com/groups/project-emco/core/-/issues?scope=all&state=opened&milestone_title=21.12&label_name[]=Enhancement