Cloud hub and mule
- 2. Anypoint Runtime Manager allows you to deploy your Mule applications through the: • Anypoint Runtime Manager’s Cloud console to CloudHub, or the • Anypoint Runtime Manager’s Cloud console to another server running an instance of Mule runtime (on-prem or on the cloud) • On-premises edition of the Anypoint Runtime Manager to another server that runs a Mule runtime
- 3. Although the basics of building a Mule application are the same, the different deployment modalities offer distinct management features. The key reason is that each modality uses a different Mule Agent when communicating with servers. • When deploying to CloudHub, the old Mule Agent is used. This legacy agent was originally created for Mule Management Console (MMC). • When deploying to a server that you manage, whether through the cloud console or the on-premises Runtime Manager console, the new Mule Agent is used.
- 4. • Building applications for CloudHub or an on-premises server is easy. However, there are some differences as you move from an on-prem deployment to CloudHub. CloudHub provides more out-of-the-box functionality, such as load balancing, but has some limitations which you may need to adapt your application to. This document illustrates the differences between both deployment environments, covers a few best practices when developing an application for CloudHub.
- 5. Management Features • CloudHub is a complete Platform as a Service that covers all of your server needs out of the box, including logging, analytics, alerts, scheduling, etc. Hosting your apps on your own servers allows for greater flexibility and tighter security (in case you deploy to your own secured on-premises environment) but requires that you sort out several considerations by your own means. • When deploying to your own servers, you have the flexibility to group them into Server Groups or Clusters and configure various parameters to handle them. • The available modalities offer different management features as each communicates to deployment servers via different versions of the Mule Agent.
- 6. • When deploying to a CloudHub worker, the old agent is used. (this is the same agent used by MMC) • When deploying to a server you manage – regardless of if you do this through a cloud or on-premise console – the new Mule Agent is used.
- 7. • Although the long term plan is to converge the features of these deployment mechanisms so that they all offer the whole set of capabilities, currently they differ as follows:
- 8. Ports and Hosts • CloudHub provides infrastructure for DNS and load balancing for your applications. This means you must configure your applications in a specific way to utilize this information. CloudHub provides two hosts for you: • myapplication.cloudhub.io - Routes information to the CloudHub load balancer • mule-worker-myapplication.cloudhub.io - Routes information directly to your CloudHub application, bypassing the load balancer. If you have multiple workers, then this DNS round-robins between them.
- 9. Disk Persistence • CloudHub does not guarantee that writing to disk survives hardware failures. Instead, you must use an external storage mechanism to store information. For small amounts of data, you can use the Object Store. For applications that have large data storage requirements, we recommend use of a cloud service such as Amazon S3. For temporary storage, the File connector is still available and can be used with the /tmp directory.
- 10. High Availability • Mule runtime offers high availability capabilities through creating Clusters and Server Groups. Clustered Mule instances have distributed shared memory. This shared memory is used to provide persistent VM queues, transactions, and cluster-wide data storage. • CloudHub provides high availability through CloudHub Fabric. CloudHub Fabric provides a combination of load balancing, persistent message queues, and horizontal scaleout. In addition, the platform also actively monitors services and workers for problems. For example, in the case of hardware failure, CloudHub auto-migrates the application to a different worker using CloudHub zero downtime updates, minimizing down time.
- 11. Logging • While on-premise applications can use custom log4j properties files, CloudHub provides a logging service for allowing logs to be searched, downloaded, or log levels to be customized. See Developing a CloudHub application for more details.
- 12. Object Store • CloudHub provides an implementation of the user object store. This makes its usage a lot simpler, as you can simply reference the already configured CloudHub object store. It places limits on the usage of this to avoid abuse. These are detailed on the Object Store page.
- 13. Shared Resource Support • When deploying on-premises, it’s possible to create 'Domain' mule projects that don’t hold any flows, but do hold a set of global configuration elements to share among other apps deployed to the same server. Read more. This is not currently supported for deploying through the Runtime Manager, both for deployments to CloudHub and for deployments to other servers in the cloud and on-premises. • Since each application deployed to CloudHub runs on a separate virtual server, there is no need to use domains. • Currently, you can’t deploy domains through the Runtime Manager console, even to local servers where they could be needed in some scenarios. In those cases, you can still deploy your domains manually directly on your local server through the command line.
- 14. JDK Versions • The version of JDK that CloudHub implements for all apps built with Mule runtime 3.5.1 or greater is JDK 1.7. Mule runtime 3.7.0 also supports JDK 1.8. • Apps built with runtime 3.5.0 or older are deployed with JDK 1.6.
- 15. Managing Properties in CloudHub vs. On-Premises Mule Runtimes • Just like with on-premises Mule runtime deployments, applications that you deploy to CloudHub can still bundle their own property placeholder or secure property placeholder files inside the deployable archive file. CloudHub then loads these properties into the application when the application starts.
- 16. On Mule ESB • With an on-premises Mule runtime, there are several ways you can override property values bundled inside the application. • You can configure an external location to add property placeholder or secure property placeholder files to override properties. • You can set Java system environment variables at deployment time to override properties. • To use the second option, with an on-premises server you could deploy your application with the following command: • mule -M-Dsecret.key=toSecretPassword -M-Denv=prod -M-Ddb.password=secretPassword -app myApp.zip • In this case all the values typed into the command would only be stored in memory, they are never stored in any file.
- 17. On CloudHub • With CloudHub, these techniques to override properties work differently. • The first approach mentioned above (configure a properties file in an external location) is difficult to translate to CloudHub: when an application is deployed into CloudHub it is harder to write override properties files into the file system. • The second approach mentioned above (set Java system environment variables at deployment time) is much easier to translate to CloudHub: the Properties tab on the Runtime Manager does allow you to specify Java system environment variables which will function in the same way as adding environment variables when you deploy to an on-premises server. • If you have any property names set in a 'mule-app.properties' file inside your application or in bundled property placeholder files, then when your application is deployed, any entries in the CloudHub Properties tab with the same name will override the matching value bundled with the application.
- 18. • It is possible to change the behavior of the application to not allow CloudHub properties to override properties bundled with the deployable archive. You do this by changing options in the Property Placeholder element in the Mule application. See Spring documentation on Property Placeholder options for more information on non-default property placeholder options. • Note that you can flag application properties as secure so that their values are not visible to users at runtime or passed between the server and the console. See Secure Application Properties for more information.
- 19. Scheduling • CloudHub lets you define Schedules thrugh the Runtime Manager UI that run your flows automatically. • Outside CloudHub, you can achieve the same by including the Poll Scheduler element in the flows of your application.
- 20. Alerts and Notifications • Both CloudHub and On-premise deployments include the possibility of setting up Alerts and Notifications for when certain events occur.
- 21. Other Components • There are also a few components which CloudHub has limited support for currently: • Distributed locks: currently, CloudHub cannot coordinate invocations of FTP and File endpoints across multiple workers. • Idempotent routers works with in memory stores and according to the limitations of the CloudHub Object Store if you configure it to use it. If those options do not fit your needs, you can use another Object Store.