The MobiledgeX platform allows for the deployment of any workload that can be containerized, as well as allowing for the deployment of virtual machine images for those that cannot be containerized. This provides you with enormous flexibility, but also raises questions as to trade offs between the various options.
Not all supported deployment methods are able to use all of the MobiledgX platform features; the following table illustrates the differences:
| Deployment Type | Autoscale | Autoprovision | Healthcheck | Loadbalancer | TLS Termination |
|---|---|---|---|---|---|
| Virtual Machine | X | X | X | X | |
| Docker Image | X | X | X | X | |
| Docker Compose | X | X | X | X | |
| Kubernetes YAML | X | X | X | X | X |
| HELM Chart | X | X | X | X |
The MobiledgeX platform is agnostic regarding language usage; as long as the workload can be expressed in containers or virtual machines it will work with the MobiledgeX platform.
Your application should be secured according to industry best practices and any internal guidelines your organization maintains. To assist in this, MobiledgeX provides features designed to help secure your application. These include Privacy Policies [LINK HERE], TLS security for inbound connections [LINK HERE], and the default denial of any inbound traffic that is not explicitly set for an application.
Additionally containerized workloads should adhere to the following criteria:
Applications can be deployed to the MobiledgeX platform in several ways:
mcctl utility.MobiledgeX provides a version field to distinguish between different application versions. The allows gradual rollouts of changes. The suggested process can be performed via any of the three options above, and at a high level consists of the following:
Application screen in the Web Console, or via the appropriate commands on the CLI/API access options.Application Instances screen, you will see an option to upgrade an application in the Actions menu. Additionally, you will see an up arrow icon next to the Application Region column. You can upgrade the application instances per instances via this screen by clicking on Upgrade on the application instance. This allows you to upgrade at your own pace.Upgrade on the Applicatoions page and the platform will upgrade all of the application instances that have been launched from that application.Note: The platform does not enforce any versioning standards; any value can be added into this field.
For virtual machine deployments it is not possible to update the ports on a deployed application. You must recreate the application in order to change the ports being opened.
Data required for the application to run properly should be loaded as part of the initialization process. If you require persistent data, it is recommended that you locate the persistent data store in a non-edge location and then pull data to the edge as required. If you adopt this strategy be sure to allow for the time required to populate your edge application with data as part of your high availability / scaling procedures.
In the event you do require persistent storage at the edge you can make use of volumes defined in the application definition [LINK HERE]. If you choose to do this, it’s highly recommended that you architect your application in such a way that it is highly available (via clustering or replication). Additionally, you should have a defined backup/recovery process that is regularly tested.
The MobiledgeX API can be used to help enable CI/CD pipelines, using tools such as GitHub Actions or Jenkins jobs.
When deploying workloads to the Edge you will likely have secrets (passwords, keys, certificates, etc) that your application will need access to.
Your application should contain logic that allows it to throttle requests; this ensures that the application will not be overwhelmed by requests to the point where it affects user experience. The threshold beyond which the application begins to throttle or shed connections should be defined as higher than the thresholds defined within the MobiledgeX Platform for the Autoscale and Autoprovision policies. This will provide a safety net for the application in the event either there is an issue with the application instance or if excess traffic is sent to the instance.
This will also help define a threshold for when the application needs to either be scaled or to have more instances provisioned.
Any logging from your container can be processed by the container engine, making it available for view in the MobiledgeX Console. It is suggested that audit information be added to the application in order to aid in troubleshooting; the MobiledgX Console will provide audit information for actions taken in the console, but has no visibility into the application logic.
MobiledgeX provides monitoring for deployed containers via the web console, the mcctl utility, and via the MobiledgeX API. The following metrics can be accessed for an Application Instance:
If you wish more granular metrics for your application you will need to create them as part of your deployment.
In order to aid debugging and provide documentation it is recommended that every application deployed contain a BOM file that provides the following information:
Build environment details:
Every action that is carried out in the MobiledgeX platform is associated with a TraceID. This is a 17 character alphanumeric that uniquely identifies the action in the MobiledgeX audit system. If you encounter an error with the MobiledgeX you will need to provide the associated TracdID(s) to support in order to expedite the investigation and remediation of the issue.
As a best practice, if components are using / displaying time information where possible they should express this data in UTC format. From there it can be converted to a display format if necessary.