Cloudhub and Mule

INTRODUCTION
 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

INTRODUCTION …continued
 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.
 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.

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.

MANAGEMENT FEATURES
…continued
• 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.

 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:
Deploying to a CloudHub worker Deploying to a server you manage
Logs are handled by CloudHub You can configure the Runtime Manager
to send data to External Monitoring
Software such as Splunk or ELK
CloudHub has its own Insight Engine You can configure the Runtime Manager
to send data to External Monitoring
Software such as Splunk or ELK
You can manage Schedules through the
Runtime Manager UI
You must use the Poll Scheduler element
in your flows to schedule tasks
CloudHub has its own preconfigured
default Object Store you can reference. To
use it, simply add an Object Store
connector and set its 'config_ref' to point
to the default CloudHub Object Store.
To use Object Stores you must configure
your own database to store data

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.
 To utilize the load balancer, your application must use specific ports
that CloudHub allocates for your HTTP and HTTPS endpoints.

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.

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.

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.

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.

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. 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.

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.

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.

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.

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.
 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.

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.

ALERTS AND
NOTIFICATIONS
 Both CloudHub and On-premise deployments include the possibility
of setting up Alerts and Notifications for when certain events occur.

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.

Cloudhub and Mule

More Related Content

What's hot (20)

Similar to Cloudhub and Mule (20)

More from Shanky Gupta (20)

Recently uploaded (20)

Cloudhub and Mule