Transparent Cutover From Legacy Platform to MuleSoft CloudHub — Using wildcard/multi-domain certificate on DLB
Introduction -
Organizations often opt for the MuleSoft Anypoint platform to replace their legacy middleware/API platform as part of their digital transformation journey. As MuleSoft provides a one-stop solution for API management and implementation (and recently for integration and automation at scale via composer and RPA), organizations are quickly capitalizing on MuleSoft’s platform to setup an API economy across their enterprises. However, a key concern for many organizations is how to start such a digital transformation while also being transparent with existing end-users to avoid disruption.
Though this article focuses specifically on MuleSoft CloudHub and dedicated load balancers, other MuleSoft deployment models including Runtime Fabric (RTF) and On-Premises could also be used. This article is based on practical experience; however, it is strongly encouraged to communicate with your organization’s network, security team, and enterprise architects before implementation.
For this article, the assumption is that end-users are using TCP 443 (https) or 80 (http) ports to connect to legacy platforms. This article does not discuss port forwarding which is required if the existing consumers are using a port other than 443 or 80 to connect to the legacy platform. In that situation, additional consideration may be needed, such as corporate F5 configuration to forward the existing port to 443 or 80.
Transparent Cutover From Legacy to MuleSoft Platform
During the process of creating point-to-point integration, organizations often find themselves having too many subdomains to maintain.
Consider the situation of the following fictitious organization with the existing domain name example.com. There are many applications in the organization that are accessed by different end-users from different subdomains. Suppose for accessing the HR application there is a subdomain, hr.example.com. Similarly, for the finance and sales applications there are subdomains finance.example.com and sales.example.com, respectively.
When this organization decides to replace all legacy integration/service platforms with MuleSoft, end-users also need to change the SSL endpoints to invoke the applications. So whether services are HR-, finance-, or sales- related, all consumers consume the MuleSoft applications (API) only. However, organizations often desire to keep existing end-users transparent to the platform change while allowing them to continue using the same SSL endpoints. For example, a consumer would still be able to use the existing subdomain, finance.example.com, to access finance applications under the new MuleSoft API platform.
To do so, the organization’s Domain Name System (DNS) entry will route the request to MuleSoft instead the legacy platform at an on-premises data center. This will keep the requestor transparent to the change while allowing them to continue using the same SSL endpoints. The following diagram depicts the desired solution.
Previously, many organizations set up point-to-point integration with external customers, vendors, or partners and avoided immediate change that could disrupt business. In the next section, we will discuss how to implement a solution on MuleSoft CloudHub with dedicated load balancers to replace legacy integration platforms. This allows stakeholders — external customers, vendors and partners — to remain transparent to the change without causing disruption.
Dedicated Load Balancer Configuration With Wildcard Certificate
The first step of a transparent cutover is to use the organization’s vanity domain for MuleSoft CloudHub VPC. To achieve this, a dedicated load balancer must be used (note: not a shared load balancer). A dedicated load balancer (DLB), supports the use of the same existing domain (i.e., example.com) of an organization for MuleSoft CloudHub VPC. DLB also supports SSL configuration to provide custom certificates for end-consumers to complete the handshaking. DLB setup is not discussed in this article; however, MuleSoft has detailed documentation found at this link: https://docs.mulesoft.com/runtime-manager/lb-create-arm
By default, the DLB endpoint will be:
<DLB name>.lb.anypointdns.net
For example, if the DLB is created with the name “example-app”, then the default host-name to access the MuleSoft applications running behind the DLB is “example-app.lb.anypointdns.net”.
To assign the organization vanity domain on MuleSoft DLB, it is required to add a CNAME record that will overcast the default DLB domain with the vanity domain. So if a CNAME record is created on DNS as “mule-app.example.com”, and it is assigned to “example-app.lb.anypointdns.net”, then an external consumer can send traffic to MuleSoft applications running on CloudHub VPC on “mule-app.example.com” through DLB. Please note, a CNAME alias with vanity domain is not possible with SLB.
There can be many subdomains in legacy architecture that need to be mapped on MuleSoft (through CNAME record) to keep the existing legacy-platform consumers transparent to the platform transformation. For example, recall the subdomain names of the fictitious organization — hr.example.com, finance.example.com, sales.example.com — described earlier.
In addition, applications have deployed on different environments on different servers like dev, qa, uat and prod, so the number of subdomains can increase (for example, hr-dev.example.com or finance-uat.example.com). This can cause an operational overhead for a large organization as adding each subdomains from all environments as individual SSL endpoints requires the management of many security certificates on the DLB. Moreover, an organization can incur significant costs if CA certified certificates are preferred. MuleSoft DLB supports wildcard certificates to utilize one single certificate for all subdomains.
For example, wildcard certificates for “example domain” can be created as “*.example.com”.
Any subdomain like “hr.example.com” and “finance.example.com” will match the same wildcard certificate and traffic from both sub-domains will be routed to VPC by DLB. Note: if organizations are using both wildcard certificates and non-wildcard certificates (meaning subdomain specific, like “hr.example.com”), then DLB will match the host header from top to bottom of the certificate list. Ingress traffic will be routed to the SSL endpoint that matches the request host header. If the certificates are defined on DLB in order below,:
- *.example.com
- hr.example.com
then the request from “hr.example.com” will be correlated to “*.example.com” and down-the-line traffic routing will happen, following the mapping rules defined under wildcard certificate. As a result, the traffic intended for the HR MuleSoft application will route to some wrong MuleSoft application or it will give a 504 Gateway Timeout since DLB will not be able to find the target application for HR. To avoid this, keep the subdomain specific certificate first and then add the generic certificates. With respect to domains, the more generic certificates should be ordered towards the bottom of the list. For example, the correct order of certificates for the scenario above is:
- hr.example.com
- *.example.com
Once the certificate is added, the order cannot be changed. The only option is to remove the certificate from the list and then add it again. Newly added certificates go on the top of the list.
When the wild card certificate is used for sub-domain consolidation, URL mapping rules need to be common for all subdomains. If that is not possible then every subdomain needs its own individual certificate. One drawback of the generic wild card certificates is that if any one domain gets compromised, it may further compromise additional subdomains. SAN (Subject Alternative Name) certificates are a more secure option if a certificate that can cover multiple subdomains, but is not universal to any subdomain, is desired.
The next required step is to set up the mapping rules to invoke the correct MuleSoft application in the correct MuleSoft environment. In MuleSoft Sandbox VPC, there can be multiple environments and every environment can have its own copy of the MuleSoft application running. For example, an HR application can be deployed on a Dev environment as well as a QA environment (as shown in Figure 1). There must be a mapping rule that will resolve the HR application on the Dev environment or QA environment, as per the request. Also, there should be well planned nomenclature standards to name the MuleSoft applications to easily construct mapping rules.
For example, consider the MuleSoft HR application deployed on MuleSoft Sandbox VPC on both Dev and QA environments. The MuleSoft application is deployed to the MuleSoft Dev environment with the name “hr-dev-app”, and on the QA environment as “hr-qa-app”. Then, a domain mapping rule is used on the DLB certificate (as shown below) to route the incoming traffic to correct destination.
With the above mapping rule, if the request is comes on
https://hr-dev.example.com/hr , it will invoke “hr-dev-app” on the MuleSoft Dev environment.
If the same request is comes on
https://hr-qa.example.com/hr , it invoke the “hr-qa-app” on the MuleSoft QA environment.
If for some reason the subdomain name can not be part of application name , then URL mapping shown below can be used instead:
With the above mapping rule, if the request comes on
https://hr-dev.example.com/hr/dev , it will invoke “hr-dev-app” on the MuleSoft Dev environment.
If the same request is comes on
https://hr-qa.example.com/hr/qa , it will invoke the “hr-qa-app” on the MuleSoft QA environment.
Conclusion
Organizations choose the MuleSoft Anypoint Platform to replace the legacy middleware or API gateways as their digital transformation initiatives. This purposeful transformation helps organizations find answers to many business disruptions in their industry verticals and allows them to stay ahead of their competition. However, replacing legacy platforms becomes challenging if it can not be transparent for the end-users. With MuleSoft’s rich support for out-of-the-box development, components, and connectors, applications can be developed in MuleSoft as functional replications of the services running on legacy platforms. However, when end-users are cutover from their legacy platform to MuleSoft, they need to change HTTP/s endpoint URLs and certificates based on the configuration of the new platform. Using a wildcard certificate or a multi-domain SAN certificate on MuleSoft DLB allows existing consumers of legacy services to continue with same host headers (and certificates) to connect to MuleSoft, instead. This will make the consumers transparent to the platform cutover; however, please note there can be additional setups to consider to keep the cutover transparent to the existing consumers of the legacy platform.
The MuleSoft architect or engineer is not solely responsible for making this platform transformation transparent to existing consumers or end-users. This type of transformation requires close collaboration with the organization's network team, security team, and many other stakeholders. Proper planning and analysis is required before implementation to optimize the cost and effort required.
The intention of this article is to share how to migrate from legacy to MuleSoft platforms while being transparent to end users to avoid any disruption. This article does not claim to provide any ready-made solutions.
Hopefully, this article will help in planning the replacement of your legacy platform to a MuleSoft platform!
