Rapid application development is great, as it increases delivery speed and makes the development process easier to understand for non-technical people. But what about deployment and hosting? Do you need a specialised infrastructure or maybe it’s possible to host anywhere? In this article, we will dive into the deployment options for the Mendix low-code platform.
The possibility to develop and release software in days or weeks instead of months is a great benefit of Mendix (and low-code solutions in general). But speed and agility in delivering the solution may be as important as other factors like compatibility with existing infrastructure or isolation from external networks. By now, you probably know that Mendix apps are primarily hosted with Mendix Cloud. What if you want to benefit from low-code development and need to host outside of the Mendix Cloud? Is it possible? The answer is ‘yes’! Thanks to its architecture, Mendix can be hosted on lots of cloud platforms from Azure and Amazon Web Services (AWS) to SAP and RedHat. What’s more, you can host Mendix on-premises if you need to.
Before diving into the alternatives, let’s recap the features and properties of the Mendix Cloud and explore certain cases in which you might want to move to another platform. Just please note that this article doesn’t cover the deployment of mobile applications.
The Mendix Cloud is built on top of AWS with Cloud Foundry serving as an intermediate layer, which makes it easier to deploy applications to a cloud environment and manage them. For more information on this platform check out the Cloud Foundry Concepts web page.
Mendix Cloud is available in three geographical zones: East of North America (1 region), Europe (3 regions, 2 in the EU) and Asia-Pacific (1 region). The customer determines the data residency and the data is guaranteed to remain in the chosen region. Speaking of data, Mendix conforms to information security standards and is ISO/IEC 27001:2013 certified. You can read more about data safety on the Mendix Trust page.
One of the most appealing elements of the Mendix Cloud is its integration with the Developer Portal. This allows you to manage environments, make one-click deployments, and much more, all from a single web page.
Last but not least, the Mendix Cloud has been built exclusively for hosting Mendix solutions. This means that you can expect a good result in terms of performance for provided resources. Even if your application requires more resources, vertical and horizontal scaling can be done easily for a particular environment.
Why Host Elsewhere?
The Mendix Cloud seems to be the right solution. So why bother with other hosting environments? One of the most common reasons, but not tied to technical capabilities, is the client’s strategic decision to adopt a particular cloud provider as a core provider. On the other hand, from the experiences of the low-code team at Objectivity, we can tell that there are also cases in which other platforms may give you additional benefits.
For instance, if you anticipate that your application’s user traffic will change significantly within short periods of time, you might want to look into other solutions. You can easily scale your environment, as mentioned before, but it won’t spawn new instances to mitigate increased traffic nor release surplus resources dynamically.
It may happen that the client’s security policy will not allow its data to be processed outside of a dedicated (possibly on-prem) infrastructure. In this case, you can still deploy a Mendix app – either by deploying the application to your server or on a private cloud.
Beyond the Mendix Cloud
Before moving to different deployment options, take note of two facts. Firstly, you will be responsible for managing the infrastructure after moving from the Mendix Cloud. Secondly, the Enterprise plan licence requires that Mendix be run on a non-Mendix Cloud or on-prem.
Running an application outside the Mendix Cloud will require relaying information about the licence in the form of a Subscription Secret of a Licence ID/Key pair. These pieces of information can be obtained by contacting Mendix Support. Detailed information on how to licence your application for a particular deployment option can be found on the Licensing Apps documentation page.
Public or Private Cloud?
Mendix gives you the possibility to host your application in both public and private cloud environments. You can deploy to any cloud provided that it supports running Docker images, or you may want to recreate a setup similar to these for an on-premises deployment (see section below) with a virtual machine. Generally, there are several options for hosting on a cloud environment, all listed in the cloud providers overview. As mentioned, you can host on any cloud, but some providers have signed a formal partnership with Mendix, so you can expect better support in case you have any issues.
Mendix partnered with:
- Microsoft Azure
- SAP Cloud Platform
- IBM Cloud
You can also use Mendix for Private Cloud, a solution which connects one-click deployment with your Kubernetes cluster. Created primarily for deploying on cloud, it’s an interesting solution which can automate much of the deployment for you. This solution requires that you install the Mendix Gateway Agent and Mendix Operator to establish a secure connection and manage cluster resources, respectively. If you’re already a Mendix user, you may find Mendix Academy’s tutorial on simulating deployment to private cloud with Minikube quite useful. It demonstrates how to register a cluster and obtain required installation scripts. The process is also described in the documentation.
Deployment with Cloud Foundry is highly automated. Before the first use, you will need to configure the hosting environment, e.g. prepare the database and (optionally) the file storage – but after having done so, deployment will be reduced to a simple, one-click procedure.
Notable examples of platforms that enable Cloud Foundry-based deployment are Pivotal Web Services, the SAP Cloud Platform, and the IBM Cloud.
There are several ways to deploy to a Cloud Foundry based platform. From within the Mendix Studio Pro, Developer Portal, or with Cloud Foundry CLI. Using Mendix Studio Pro, once the environment for your application is configured, you can one-click deploy it by providing an endpoint and credentials. With Cloud Foundry CLI, you issue a command with a link to the cf-mendix-buildpack (GitHub) and to your deployment package. The Developer Portal is the recommended deployment method when using Cloud Foundry provided by IBM or SAP.
Probably the most versatile deployment option is to create a Docker image of the Mendix application. This can be done with mendix-docker-buildpack (GitHub), an open-source tool created by Mendix.
To use it, you need to clone the repository and then run the “docker build” command. This requires a handful of arguments (described in readme), such as another version of the Cloud Foundry buildpack. This is because the mendix-docker-buildpack uses the cf-mendix-buildpack under the hood to create Docker images.
You can then use the images on any infrastructure which supports running Docker images. For example, you can upload them to a container registry, like the Azure Container Registry (ACR) or the Amazon ECR, and use them from there in your custom CI/CD pipelines. You can then run them in one of the cloud services, like the Azure Kubernetes Service, Amazon EKS, or Amazon ECS. The names of the services will vary, depending on the cloud provider.
Note that running the images will require additional information, which should be relayed as environmental variables. For a full list of variables, please consult the readme of the mendix-docker-buildpack.
Lastly, you can deploy a Mendix application to your own infrastructure, provided that it meets Mendix’s requirements. This can be done either by using a traditional web server or a setup capable of running Docker images (see the section above for details on how to create an image of a Mendix application).
Before deciding to deploy on-premises, you might want to review example architectures. Mendix describes how to deploy to both Windows (link) and a Unix-like server (link). In case of the latter, only a handful of distributions and versions are officially supported: Debian 8 (Jessie) or 9 (Stretch), Red Hat Enterprise 7 or CentOS 7.
As the configuration is lengthy and the documentation covers all the steps comprehensively, we will not cover all of them here and just mention the milestones for deploying to on-premises servers. Some of the common prerequisites for both systems are:
- Deployment package for your application
- Java Runtime Environment
- A database for your application
- Web server – Microsoft IIS and ARR for Windows or nginx (example) for GNU/Linux
Moreover, you will need to install additional Mendix tools like the Mendix Service Console and the Mendix Server Distribution for Windows or m2ee-tools for a Unix-like system. The software for Windows is available at the Mendix App Store, while m2ee-tools are on GitHub.
After preparing prerequisites you will need to deploy and configure your application (using the Mendix Service Console or m2ee-tools) and configure your web server. Finally, you will need to license your app either by using the Mendix Service Console on Windows or with the m2ee-tools command on a Unix-like system.
There are two more options we didn’t explore yet. One of them is an Azure Marketplace item which is a Mendix tool. Its deployment process is similar to that of an on-prem web server, with the exception that the Mendix tool will lead you through the process of creating an environment on Azure. The whole deployment is thoroughly described in the documentation.
The second is the Mendix Cloud Dedicated VPC. This is in fact an instance of the Mendix Cloud running on your AWS user account. The instance is fully managed by Mendix. The user of the Developer portal will experience the same environment as when working with a standard Mendix Cloud.
You need to bear in mind the fact that deploying outside of the Mendix Cloud might require additional work from you and your team. So please remember to notify stakeholders that the decision to deploy outside of the Mendix Cloud may affect the time required to deliver a project.
In case of hosting on a non-Mendix cloud, remember that the burden of keeping everything up and running will be on your shoulders. So, make sure you have the resources you need to keep your server up-to-date, secure, and highly available, and that you can monitor your application.
Packaging your app as a Docker image requires the use of the previously mentioned docker-mendix-buildpack, which is an open source tool available on GitHub under the Apache 2.0 licence. When referencing this repository in your automated pipeline, remember that it will change over time and some of these changes may affect the build pipeline. It’s a good idea to fork the project or download it and then reference your copy.
Mendix is very versatile in terms of deployment options. As it is a cloud-native platform, applications built with it can be hosted on almost any cloud platform on the market, in many configurations, from a virtual machine to a Kubernetes cluster. Even if you’re reluctant to move to the cloud, you can still host on your on-premises infrastructure. Last but not least, the Mendix Cloud itself is a solid hosting environment fully managed for you by Mendix engineers. So, why not give it a try and build your next project with low-code?
About the Author
Formerly a physicist and R&D engineer, now part of the Low-Code Practice at Objectivity. He’s pragmatic, focused on good user experience, and passionate about helping other people automate their mundane tasks.
For more information, download Objectivity’s latest white paper on low-code: “Gain more by doing less”.