Why deploy Mendix onto your own AWS infrastructure? We are posed with this question frequently as strategic partners of both Siemens Mendix and Amazon AWS. In this post, we’ll take a high-level, technology-focused approach to answering this question.
The Mendix Cloud, built on AWS, provides an excellent option for many applications. This infrastructure is tuned to run a variety of Mendix applications, from company portals to departmental approval applications. Deployment is simple, leveraging the Sprintr tool that provides one-click deployment and built-in services for database backups + restoration, logging, environment metrics and alerting. It is a full-featured solution that allows you to build, deploy and monitor your application with ease.
Alternatively, Mendix Private Cloud offerings allow organizations to deploy to the cloud of their choice, soon including the AWS GovCloud for organizations subject to FedRAMP compliance. We’ve helped many clients evaluate Private Cloud options, with Amazon’s AWS offering being the most common (followed by Azure). From our experience and discussions, we’ve identified five key drivers that can make AWS the right choice:
1. Corporate Governance
Is your organization following the AWS Well-Architected Framework? Do you want to manage your Mendix applications alongside your existing AWS infrastructure?
Deploying your Mendix application on AWS allows your organization to follow Amazon’s recommended multi-account structure and centralize governance. CloudWatch will provide monitoring of your Mendix applications alongside existing infrastructure, while still having the option to push logs and monitoring to external purpose-built tools like Splunk. You can also control deployment pipelines as well as database backup location and mechanisms, allowing you to leverage centrally controlled S3 buckets, lambda functions and access.
These are just a few examples, AWS deployment will help integrate Mendix into your existing AWS governance policies instead of needing to accommodate additional tools like Mendix Cloud and the Sprintr platform. This helps lower operational risks as well as cost.
2. Horizontal Scalability
Will your Mendix application receive “peaks and valleys” of usage?
The Mendix Cloud provides convenient “t-shirt sizing” for their cloud resource packages. This provisions a container with a specified amount of application and database RAM/CPU as well as database storage and file storage. These currently come in sizes from “XS” to “4XL”, with the underlying resources doubling between sizes. While this works for many use cases, it can be a challenge if your application experiences extreme peaks in usage.
For example, an invoicing application may receive heavy traffic and need to generate documents and analytics at the end of the month which requires a lot of CPU and application memory. The remainder of the month, however, the application may receive lower traffic and have lower compute requirements. This would require you to pay for increased resources to support the heavy load at the end of the month even though these resources will be underutilized 90%+ of the time. On the flip side, if you have an application where growth is outpacing your infrastructure, you may find yourself scrambling to upgrade to the next t-shirt size to protect user experience as you scale. This strategy is reactionary and will result in either under- or over-provisioning of resources at any given time.
When deploying to your own AWS infrastructure, you can incorporate horizontal scalability. When thresholds are met (e.g. CPU usage, memory usage), you can spin up additional servers to handle the increased user traffic, API traffic or document handling. Once the spikes in activity subside, those servers will be spun down to reduce your infrastructure costs. This flexibility will allow you to better optimize your infrastructure sizing and cost while helping eliminate reactionary scaling emergencies.
3. Control and Access to Underlying Components
The Mendix Cloud supports a variety of application use cases and, as a result, they must implement standardization as well as control mechanisms. A great example of this is the previously mentioned t-shirt sizing which provisions a standard ratio of application and database CPU, memory and storage. These ratios work for many use cases, but some applications are vastly more CPU-intensive, memory-intensive, or read-intensive which requires upgrading to the t-shirt size that accommodates your most demanding dimension. For these applications, you end up buying resources your application doesn’t need to solve for the bottleneck. By deploying your Mendix application to AWS, you can fine tune the underlying resources (e.g. EC2 instance and size) to match the application’s specific needs.
This control also extends to your database – you will have the ability to connect directly to your database or even create read-only copies of your database to support extensive reporting needs.
4. Tight Coupling of Additional AWS Services
If your Mendix application leverages other AWS Services (e.g. Lambda, AI/ML, S3), you could benefit from deploying the application and additional AWS services together. You can control which services and elements are deployed within the virtual private cloud (VPC) that runs your Mendix application. Additionally, an endpoint can be configured to allow your application to speak directly to AWS services and avoid transmitting data to the public internet for it just to re-enter on your application. This results in better speed, security, and pricing – especially at scale.
5. FedRAMP, Specialized Deployments
While the Mendix Cloud caters to a wide array of security standards, there are a few like FedRAMP in the United States which require specialized deployments. Mendix is in process to achieve FEDRAMP compliance leveraging AWS GovCloud which will make it one of few low-code platforms with this distinction. This will allow federal agencies and defense contract organizations to realize the benefits of Mendix and low-code.
The Mendix Cloud offering has 99.5% uptime guarantee on its basic package and 99.95% uptime guarantee for the premium cloud packages. If your organization has specific uptime guarantees or disaster recovery requirements that differ from what Mendix Cloud offers, you can configure AWS infrastructure to meet those needs.
While these five are excellent reasons to consider AWS deployment of Mendix, be sure to avoid the following two pitfalls:
1. Expecting Reduced Costs
As previously mentioned, Mendix Cloud provides tools for database backups + restoration, logging, environment metrics and alerting out of the box. These tools come at no additional charge and are specific to the Mendix Cloud deployment. The Mendix Cloud also comes with Mendix Support which handles infrastructure and app database upgrades and security patches. Mendix has support at the ready to assist with infrastructure issues and troubleshooting.
While deploying to your own AWS infrastructure will help you to optimize and fine-tune your infrastructure spend, further angles need to be considered. In addition to purchasing a Mendix license to deploy on AWS, you will now need to take responsibility for database backups + restoration, logging, environment metrics and alerting as well as ensuring the infrastructure is updated and running. If your organization has governance around these items, that is great as you can conform Mendix to your existing policies. If not, however, this can lead to unexpected cost as you handle these items that come out of the box with Mendix Cloud.
2. Masking Performance Issues
While performance tuning and analysis would each require a series of posts to adequately cover, we will touch on them here. When considering an AWS deployment, it’s important to recognize that the infrastructure will not fix any underlying logical bottlenecks or inefficiencies in the application design but could mask them further. For example, if application memory is running out in Mendix Cloud due to there being too many non-persistent entities created in a specific workflow, a migration to AWS infrastructure will only help you mask this issue by spinning up additional resources as memory thresholds are reached. This is not a solution so much as a band-aid and may increase AWS invoices since new servers are being spun up to accommodate the unnecessarily large app memory demands.
If you are considering a move from Mendix Cloud to AWS infrastructure to address performance concerns, we highly recommend an expert review of the application’s resource usage and root cause analysis of the bottleneck(s). By doing so, you will ensure that the migration to AWS is based on one or more of the five reasons we have outlined and not to mask a logical problem that is causing performance issues.
The Mendix Cloud is a user-friendly and comprehensive offering, yet there are scenarios where deployment to your own AWS infrastructure will make sense. This can be true whether you are an Amazon customer with well-defined governance policies or if this will be your organization’s first foray into AWS. Consider your infrastructure options through the five issues presented here and avoid these common pitfalls. Determine the key value you’re looking to gain on AWS and evaluate your Total Cost of Ownership (TCO) and Return on Investment (ROI) calculations.
We’ve seen an increase in demand for AWS private cloud hosting and have become a principal partner using our AWS and Mendix experience to develop solutions and approaches. We hope sharing this knowledge will help you and your organization determine an infrastructure approach that is right for you.
Ready to Navigate the Cloud Journey?
Navigating the intricacies of deploying Mendix on AWS can be complex, but you don’t have to do it alone. Our team of experts is here to guide you every step of the way. If you’re looking to optimize your infrastructure, assess your current setup, or simply need more insights into AWS and Mendix deployment, reach out to us today. Let’s collaborate to ensure your organization achieves the best infrastructure solution tailored to its unique needs.