Mendix for Private Cloud

What is Mendix for Private Cloud?

Mendix for Private Cloud provides Mendix’s ‘LowOps’ one-click deployment experience for your own Kubernetes-based (virtual) private cloud. This allows Mendix development teams to manage the application lifecycle while still having control of the application data in a private cloud environment.

Mendix for Private Cloud is based on the Kubernetes native operator pattern. It is responsible for provisioning, building, deploying, and scaling Mendix applications in a Kubernetes-based private cloud environment.

Is Mendix for Private Cloud a Good Fit for Me?

Mendix for Private Cloud allows you to run your app and store Mendix app data in a specific region or on a private network. This means you can comply with commercial or regulatory requirements for the location and security of your data. Mendix for Private Cloud does this by allowing you to deploy and manage your Mendix apps in a Kubernetes-based private cloud, which you set up and control.

Common Use Cases

Data Sensitivity and Security Requirements

The application deals with highly sensitive data or is subject to stringent security regulations.

Industry-Specific Compliance

Certain industries, such as healthcare, finance, or government, have strict regulatory compliance requirements.

Legacy Systems Integration

When integrating with existing legacy systems that are not easily migrated to a public cloud.

Geographical Data Control

Some organizations may have legal or contractual obligations to keep data within specific geographical regions.

What Features Does Mendix for Private Cloud Offer?

Mendix controls deployment to a private cloud using the Mendix Operator. This tells your app how to use the services you have set up in your Kubernetes-based cluster.

You install the necessary Mendix for Private Cloud components using the Operator Configuration tool, which also configures or reconfigures the services your app uses.

The Mendix Operator is a separate licensed piece of software in addition to the license(s) you require for your Mendix app. See Licensing Mendix for Private Cloud in the Mendix documentation for more information.

How is the Data in Mendix for Private Cloud Managed?

Data security is very important to you and to Mendix. Mendix for Private Cloud uses the following techniques to keep your data secure.

Cluster Secrets

Mendix does not have access to secrets in the cluster. They are managed by the customer.

Data Security at Rest

Your data is secured where it is stored.

• You can encrypt all the data in your Kubernetes-based containers
• You can encrypt your persistent data using features built into the file and database storage options
• If you are using Connected Mode, Mendix securely maintains only the data that facilitates collaboration and the development of your application on its servers but does not hold any data used by the application itself

If you need to encrypt data within your app, you can do this by, for example, using a Mendix encryption module.

Data Security in Flight

Your data is also secured as it moves from one place to another.

• You can set up secure network communication between your cluster and the end-users
• Communication with data storage stays within your network
• Communication with the database can be encrypted
• You can encrypt communication within your cluster between the internet connection and your app

What Connectivity Options Does Mendix for Private Cloud Provide?

By default, you can control your deployments on Mendix for Private Cloud by securely connecting your Kubernetes-based cluster to the Mendix Portal. This is known as Connected Mode and gives the most complete Mendix experience.

You can also transfer all the resources you need to a cluster that is not connected to the internet (air-gapped). In this Standalone Mode, Mendix will help you by generating the commands you need to set up your environments and perform your deployments.

What Does Mendix for Private Cloud Architecture Look Like?

Mendix for Private Cloud allows you to host Mendix apps on your Kubernetes-based private cloud. To do so, you need to add the Mendix Operator and, optionally, the Mendix Gateway Agent. The Mendix Operator automates the operation of Mendix app environments, and the Mendix Gateway Agent supports secure communication between your cloud and the Mendix Platform.

Mendix for Private Cloud is based on the Kubernetes native operator pattern, making the Mendix Operator responsible for the provisioning, building, deploying, and scaling of Mendix applications and minimizing the intervention of a human operator.  To perform all these activities, the Mendix Operator leverages your infrastructure, such as database servers, file storage, image registry, and networking, but you control how they will be used by setting the proper configuration of the Mendix Operator.

On the Mendix platform, a bidirectional secured connection is established between the Mendix Gateway Agent and the Interactor running on the Mendix Portal to allow developers to interact with the Kubernetes-based private cloud using the Mendix Portal.

This connection is generated by the Mendix Gateway Agent, so there is no need to open incoming ports and expose your Kubernetes-based private cloud over the internet. This maximizes your cloud security while keeping the ease of use of the Mendix platform.

How Are My Apps and Data Secured in Mendix for Private Cloud?

Access to perform actions directly on your Private Cloud cluster is completely under your control through the credentials required to access your Kubernetes-based cluster.

Access to manage Mendix for Private Cloud clusters, namespaces, environments, and deployment within the Mendix Portal is controlled by applying roles to users of the Portal.

There are three standard roles:

• Cluster Manager – who has access to manage Mendix for Private Cloud’s use of an entire cluster
• Cluster Administrator – who can create, delete, and manage individual app environments within the cluster
• Developer – who can manage an existing app environment to which they have access

You can also give users custom roles within Mendix for Private Cloud.

Access to the app itself is controlled by the standard Mendix Developer Portal roles described in Platform Security.

How Are the Responsibilities Divided in Mendix for Private Cloud?

Because Mendix for Private Cloud is running on your own Kubernetes-based private cloud, you need to set up resources in this cloud to support your app.

Mendix provides you with the following:

• Mendix for Private Cloud setup
• The Mendix Operator to control how your app uses the services in the cluster

And, in addition, for connected mode:

• Online platform services in the Mendix Portal
• The Mendix Gateway Agent to connect the Mendix Operator to the Mendix Portal

Support for setting up your resources is not included in your Mendix license, but we can help you on a consultancy basis.

A Kubernetes-Based Cluster

Kubernetes is the environment in which the apps need to run.

Data Storage

You need to provide a database server and file storage where your Mendix app will store its persistent data.

Networking

Since Mendix apps are web-based, you need to configure the network to allow access to the application. Mendix for Private Cloud will leverage the existing network configuration.

Monitoring and Logging

You can connect your own monitoring and logging solution to Mendix for Private Cloud.

Registry

Kubernetes is a container-based runtime platform, so you need to provide an image-storage registry to store application images, which the Mendix Operator will deploy to the Kubernetes-based environments.

FAQ

• What Does the Mendix Operator Do?

  Mendix for Private Cloud is based on the Kubernetes native operator pattern.

  The Mendix Operator encapsulates the institutional knowledge needed to manage all the operational aspects of Mendix app environments inside a Kubernetes-based private cloud. These would otherwise typically be carried out by SREs or DevOps engineers, who would spend a great deal of time manually re-running sequences of commands.

  Technically, the Mendix Operator is an application-specific controller that extends the Kubernetes APIs to create, configure, and manage Mendix apps on behalf of the Kubernetes user.

  It builds upon the basic Kubernetes resource and controller concepts but includes Mendix-specific knowledge to automate common tasks such as:

  • Provisioning app environments: Allocating the required resources to run a Mendix app, such as database, file storage, or networking.
  • Automating build and deployment: Creating an OCI (Open Container Initiative) image as the result of combining an MDA (Mendix Deployment Archive) and a base image supplied by Mendix. This OCI app image is pushed to the image registry available to be used later in deployment.
  • App metering and logging: Exposing app metrics in Prometheus format ready to be gathered from the app pod by any Prometheus-compatible tool. App logs are channeled to the standard output so any log aggregator can collect them directly.
  • Horizontal scaling: Scaling the Mendix app up and down based on the specified number of replicas, implementing data consistency and traffic switching.

  The Mendix Operator leverages the peripheral infrastructure services available to your Kubernetes-based private cloud to fulfill the above tasks when needed. It supports different ways of interacting with your infrastructure to achieve the right balance of automation and control for your organization.

• How Do I Plan My App Environments?

  The Mendix Operator is installed in a namespace of a Kubernetes-based private cloud cluster.

  Each namespace can have a single Mendix Operator, but this can operate multiple app environments. You can also install Mendix Operators in different namespaces of the same Kubernetes-based private cloud cluster.

  Mendix for Private Cloud uses Kubernetes namespaces to distribute the app environments to achieve the level of security and release management that you need.

  A single Mendix Operator controls all the app environments in the same namespace or across multiple app namespaces.

  You can see the relationship between Mendix app environments and the Kubernetes namespaces in the images below.

  A single Mendix Operator controls all the app environments across multiple namespaces.

  A Mendix Operator controls all the app environments in the same namespace.

  There is no single correct way to distribute the Mendix app environments across your Kubernetes-based private cloud. What you do depends on your security model and how you do release management.  For examples of how to implement different app environment schemas, please see Environment Planning for Private Cloud Clusters.

• How Are Air-Gapped Scenarios Supported?

  Mendix for Private Cloud standalone supports air-gapped scenarios where data within the Kubernetes-based private cloud cannot leave the private network for security or compliance reasons.

  Because there is no internet connection, the Mendix Portal cannot be accessed. This means that some Mendix platform capabilities, such as local source version control and CI/CD, must be moved into the private network. These can be implemented alongside the Mendix Operator to fill the gap left when the Mendix platform activities are removed.

  Mendix consultancy services can help you define these if you need advice.

• How Does the Mendix Portal Support Development Roles?

  The Mendix Portal is set up so that different users have their own roles in setting up the deployment of Mendix apps to a Kubernetes-based private cloud. The roles are split into cluster management and app environment management, and each user is given a role that gives them access to the page that allows them to perform the required operations.

  Cluster Manager Page

  This page is for users with a role that requires them to manage and control the Kubernetes-based private cloud used to host Mendix apps.

  It supports cluster-wide activities, such as:

  • Installation and upgrade of Mendix for Private Cloud components (Mendix Gateway Agent and Mendix Operator)
  • Management of the access given to fellow developers
  • Provision of links to metering and logging to make them available in the Mendix Portal

  App Environment Management

  This page is for app developers to manage the app environments hosted in a Kubernetes-based private cloud to which they have access.

  The user experience parallels that of other Mendix deployment models, such Mendix Cloud or SAP BTP. The user has access only to the features approved by the cluster manager.

• What is the App Operations Experience?

  The operation experience is defined by the metering and logging tools available in your Kubernetes-based private cloud.

  The cluster manager sets the access points for the tools hosted on your site. This allows developers to navigate to them from the Mendix Portal, simplifying the operation of your apps.

• What is the Difference Between the Mendix Operator and Helm?

  Helm is a package manager that shares reusable recipes for installing things in Kubernetes. The Mendix Operator, on the other hand, implements a Kubernetes design pattern that encapsulates Mendix knowledge for running Mendix applications.

  These different technologies share common terms, such as “installation,” “management,” and “lifecycle,” but their approach and scope are different.

  The key difference is in the level of automation. Here, the Mendix Operator goes further. It aims to capture the deep knowledge of the human operator who manages Mendix apps, monitoring how the system behaves and reacting accordingly to improve it in case of issues.

  To do this, the Mendix Operator automates repeatable tasks specific to Mendix that Kubernetes doesn’t provide natively,

  Using Helm would require a higher level of expertise in both Mendix and Kubernetes to perform the same activities, meaning more time spent on manual inspections and the re-running of commands. The inefficiencies caused by this error-prone and manual approach will worsen incrementally as your app landscape grows.

• How Does the Mendix Operator Differ from the Mendix Docker Buildpack?

  Mendix for Private Cloud is a solution that uses Mendix’s experience working with multiple containerized technologies and supporting customers in different cloud environments.

  On that journey, Mendix has delivered other solutions, one of these being the Mendix (Mx) Docker Buildpack, which has been adopted by many customers.

  So, what are the differences between the Mx Docker Buildpack and the Mendix Operator?

  The major difference is the purpose. Whereas the Mx Docker Buildpack is a Dockerfile that only creates Docker app images and can be used as part of an automated or manual release process, the Mendix Operator is a component that, installed in Kubernetes, can operate multiple app runtime environments across their lifecycle.

  This includes the creation of the app image, as performed by the Mx Docker buildpack, but also includes app deployment, environment provisioning, and horizontal scaling.

  The app images produced by the Mx Docker Buildpack can run any OCI-compatible orchestrator platform, while the Mendix Operator is based on the Kubernetes Operator pattern and extends the automation capabilities of a Kubernetes-based cluster. See Supported Providers for more information on which providers are supported by the Mendix Operator.

  The following diagram details the level of automation provided by both solutions and which stage of the app environment lifecycle they support:

  See the Private Cloud documentation for more information on Mendix for Private Cloud.

  The Docker Buildpack documentation explains more about the Mx Docker Buildpack.