How to choose your deployment environment

  • March 04, 2021

MuleSoft has a lot to offer when it comes to deployment models. Making a wise decision when choosing your deployment model is very important. The best deployment environment will be based on the customer’s current infrastructure, organization and budget, among other factors.

Before diving into the different deployment options, let’s discuss some basic concepts.

Runtime Engine. Mule is the runtime engine for the Anypoint Platform and the industry’s only runtime that can be used for a broad range of use cases, from legacy, software-as-a-service (SaaS) and business-to-business (B2B) integrations to API implementation and management.

Control Plane. This option includes Anypoint Exchange, Anypoint Design Center and Anypoint Management Center.

Runtime Plane. This option includes Mule Runtime Engine, Anypoint Connectors and Runtime Services.

Choosing a deployment model that caters to customer requirements is important, so you must consider several different parameters before selecting a deployment model. These include:

  • Cost involved
  • Existing network/IT infrastructure
  • Willingness to move to cloud
  • Security and regulations associated with data/metadata
  • Current architecture
  • Number of APIs/API network

Deployment environments

There are three primary deployment categories:

  • Fully cloud hosted (CloudHub)
  • Fully customer hosted (on-premises)
  • Hybrid

Fully cloud hosted

Also known as fully integration platform as a service (iPaaS) or fully MuleSoft-hosted or CloudHub.

Runtime Plane: MuleSoft Hosted (CloudHub)

Control Plane: MuleSoft Hosted (CloudHub)

When to opt for CloudHub:

  • If you’re ok with your data/metadata leaving your on-premises environment
  • If you don’t have a separate infrastructure (network) management team
  • If your organization is a startup and new to cloud service management
  • If you don’t have any legal/government regulations involved with your data
  • If you don’t have the time or workforce to set up the entire cloud infrastructure
  • If you have a smaller number of applications and don’t want to invest in a separate cloud infrastructure

Depending on the criticality of your data or the certificates you wish to use (that is, if you wish to host your application on a private or public network), you can opt for shared (SLB) or dedicated (DLB) load balancers.

Pros of CloudHub deployments:

  • High availability
  • Load balancing — SLB, DLB
  • CloudHub logging
  • CloudHub monitoring
  • Scheduling
  • Security updates
  • Troubleshooting
  • Shared resources support
  • Distributed locks
  • Automated patches/updates will be applied

Cons of CloudHub deployment:

  • Domain project aren’t supported
  • Workers could be expensive
  • VPC/VPN charges are extra (apart from CH license and worker charger)

Fully customer hosted (on-premises)

Also known as fully integration as a service (IaaS) or fully client hosted.

1. Fully on-premises

Runtime Plane: On-Premise

Control Plane: On-Premise

Even when you opt for fully on-premises you can have a MuleSoft Runtime Fabric (RTF) in case you want to build your application network (microservices) or simply your Mule Runtime Architecture.

When you want to opt for fully on-premises you can have either:

  1. RTF: When you want to use microservices with customer-hosted runtime
  2. Only basic Mule Runtimes: When you have no plans to build an application network

When to opt for fully on-premises:

  • When your data/metadata shouldn’t leave your organization or your premises
  • When you’re an established organization and don’t plan a cloud migration
  • When you’re planning to use your existing on-premises infrastructure
  • When you don’t have cost-related obligations and you’re perfectly fine managing your on-premises infrastructure

Benefits of fully on-premises:

  • Provides greater security because your data doesn’t leave your premises
  • Gives you complete control over your Mule instances, network and security policies
  • Provides the ability to create a common domain project to reference different Mule application configurations

2. Fully IaaS

Runtime Plane: Customer hosted on (GCP, Azure, AWS, etc)

Control Plane: Customer Hosted

When you opt for IaaS, which is completely customer-hosted, you can follow either:

  • RTF: When you want to use microservices with customer-hosted runtime
  • PCF: When you want to use a microservices architecture and Pivotal Cloud Foundry (PCF)
  • Only basic Mule Runtimes: When you have no plans to build an application network

When to opt for fully IaaS:

  • When you’re fine with your data leaving your organization
  • When you’re a startup and you’re planning on cloud migration
  • When you have a limited number of applications
  • When you have some regulations on data
  • When you don’t have a MuleSoft hosted customer plane
  • When you have cost-related obligations and don’t want to switch completely to cloud

Benefits of fully on-premises:

  • Provides greater security because your data doesn’t leave your premises
  • Gives you complete control over your Mule instances, network and security policies
  • Provides the ability to create a common domain project to reference configurations of different Mule applications

Hybrid (MuleSoft and customer hosted)

1. iPaaS and IaaS

Runtime Plane: Customer-Hosted (GCP, Azure, AWS, etc.)

Control Plane: MuleSoft Hosted

When you want to opt for IaaS which is completely customer hosted you can either follow:

  • RTF: When you want to use microservices with customer-hosted runtime
  • PCF: When you want to use a microservices architecture and PCF
  • Only basic Mule Runtimes: When you have no plans to build an application network or you have a MuleSoft-hosted customer plane and a customer-hosted runtime plane on an IaaS platform (AWS, Azure and GCP)

When to opt for hybrid (iPaaS and IaaS):

  • When you’re ok with data/metadata leaving the organization
  • When you’re planning on cloud migration
  • When you think a hybrid solution will save you cost and time to set up the infrastructure
  • When you’re planning to retain your existing infrastructure and slowly move toward cloud-based infrastructure
  • When you have more applications to be deployed and you think going fully cloud-based will be expensive
  • When you have a MuleSoft-hosted control plane
  • When you’re looking for cost-savings by trying to move from on-premises and the pain involved in maintaining on-premises systems

2. iPaaS and on-premises

Runtime Plane: Customer Hosted on (GCP, Azure, AWS, etc)

Control Plane: Customer Hosted

When you opt for iPaaS, which is completely hosted on-premise, you can follow either:

  • RTF: When you wish to use microservices with customer-hosted runtime
  • Only basic Mule Runtimes: When you have no plans to build an application network or your on-premises infrastructure has a MuleSoft-hosted customer plane and a customer-hosted runtime plane

When to opt for hybrid (iPaaS and on-premises):

  • When there are no data regulations
  • When you’re ok with metadata leaving your organization
  • When you’re looking for cost-savings by trying to move from on-premises and the pain involved in maintaining on-premises systems
  • When you’re planning to retain your existing infrastructure and slowly move toward a cloud-based infrastructure

Pros of a hybrid model:

  • Uses shared resources with a domain project
  • Reduces latency
  • Re-use existing load balancers for vanity domains

Cons of a hybrid model:

  • Scalability is difficult if you want to add new servers
  • Still need to maintain some part of the infrastructure
  • Manual updates/patches required

— By Akshata Sawant