Abstract

People often ask me for my advice on enterprise mobile development. This short blog post is a summary of our experience initially in FeedHenry, 2010-2014, and subsequently in Red Hat Mobile from October 2014 onwards. It is advice based on the best approach to take when planning to develop a larger numnber of enterpise mobility solutions, typically for internal employees, where minimising overall cost and increasing the speed of development is paramount. In our experience that’s usually what concerns the business.

Client-Side (Mobile Apps)

The Red Hat Mobile Application Platform (RHMAP) itself allows a wide range of supported client-side approaches. You can program native iOS (Objective-C or Swift) or Android (Java) and you can use other toolkits like Xamarin. However, we find that it makes most sense to use Apache Cordova to build cross-platform apps that can run across both these major types of device, and on Windows Phones too if necessary.

Of course, that’s only a small part of the decision. A much bigger part is then what type of JavaScript framework is best to ease the development. This is the part where our advice changes most rapidly, though perhaps some sanity is starting to be found in the secosystem, and we may have the same answer for longer than 12 months. Our current faviourite is Angular.js for the client-side.

The RHMAP supports any 3rd party client-side SDKs required, whether for use in native development, or with 3rd party Apache Cordova modules.

The RHMAP does also support pure web clients with a JavaScript SDK. So some solytions include both a mobile app for the end-users and a web-console for some admin users (e.g. to manage a middleware DB via the brwoser interface).

We find that developers without mobile experience, whether native or cross-platform, do need a long period to upskill. Typically it takes 12 months or longer to become fully productive in the mobile client-side if one has only previously done per web development. The UI and UX learning curve is a steep one, and whilst the platform does make some thinsg easier, the main learning curve still exists.

The RHMAP platform doesn’t dictate an IDE. There is a build-in editor in the web UI, but that’s more useful for demos and small changes than real development. Most developers use a local IDE of their preference: WebStorm, vim or emacs. RHMAP does provide the JBosss Developer Studio that can be used for Android native development and/or cross-platform JavaScript Cordova development. It is integrated with some hooks to the local mobile command line tools to ease working with the platform.

Server-Side (Cloud Apps)

The Red Hat Mobile Application Platform only offers one choice of programming langauge for the server-side: Node.js (JavaScript on the server). This can be used as much or as little as the developer wishes (e.g. just using it as a smart proxy to call server-side implementations developed in other languages such as Java, Go or Python). However, we find that the use of Node.js does allow rapid development and deployment both of prototypes and of full-blow supported production components.

The mobile platform has a built-in lifecycle management capability, so enterpises can map any number of logical steps in a lifecycle (e.g. dev, test, uat, production) to typically two physical hosted MBaaS (Mobile Backend-as-a-Service) deployments. Each physical deployment can have separate networking rules, so that production can be physically separated from non-production by mapping all non-prodcution lifecycle stages (we call these environments) to the a non-production MBaaS.

The platform offers a full implementation of Node.js – not some limited incarnation as many cometitors do – this means any 3rd party Node.js module can be used (currently this excludes the small subset of modules that have a native dependency in Linux).

We find that once developers discover the powerful productivity of the Node.js ecosystem, them will code more in Node.js than they may have originally felt was appropriate. We have found that Node.js skills can be picked up very quickly, so that good Java or .NET developers can become very confident with a few months.

Re-Usable Components (MBaaS Services)

The real power of the server-side Node.js compoents come when used in conjunction with the developer-extendable set of MBaaS Services. In the simple case each mobile solution in RHMAP comprises a single client-side and a single server-side app. The latter essentially allows the creation of a custom API for the client-side app, typically expsoing RESTful APIs returining JSON to the client, whilst integrating with public cloud services or on premise end-points (potentially over a VPN to that enterprise). However, it quickly becomes apparant that it is better to abstract certain integration code away from individual solutions into reusable MBaaS Services. These services can then be instantaited once for each enterpise and re-used across the set of mobile solutions being developed. The typical model is for the serev-side of each app to call these services rather than for the client-side apps to call them directly.

To aid the reuse of MBaaS Services that platform exposes them via API Blueprint with a UI for exploring these services, and even doing calls to them from the browser to see how they work. The permissions system in the platform then allows a set of priviliged developers to develop and expose these services, and a set of less privilged develoeprs to consume them. This means, for example, that an MBaaS Services that is configured with some environment variables with credntials to login to an enterpise API such as CRM, can hide those credintials from the app developers yet still allow reuse.

Rapid Mobile Aplication Development (RMAD)

In all the cases above one is assuming a developer building a solution by programming, albeit in the very productive Node.js and client-side Apache Cordova JavaScript ecosystems. This means that it can take weeks to months for solutions and prototypes to be developed (usually not years), depending the complexity of each scenario. In contrast the business need is often to see immeditate results in days not weeks. The RHMAP does provide a set of features around its App Forms that allow comptent users, who may not be developers, to develop solutions using a drag and drop forms builder (very like a webform builder) where the platform can auto-generate the server-side and the client-side code needed for the solution. Because the platform also has an automated Build Farm such users can actually build the apps in the cloud with very little technical knowdge of app development (it is usually easier if the enterpise account has been provisioned with the appropriate certificates in advance by someone with a bit more mobile app development expertise).

Build Farm

Developers often look askance at the Build Farm in the platform, how can it help them, when they have the ability to build apps on their local OSX, Windows or Linux laptop or desktop? In fact, as well as the RMAD use described above, where building apps becomes possible for non-developers, it is also very useful for fully fledged mobile developers. the big advantage is repeatability. Essentially it is a CI/CD tool that automates the build. This means, for example, that a production manager can build the final production version for release, after all phases of testing have passed, without the fear that some arcane and undocumented setting on the developers IDE was actaully needed. All the settings are explicit in the project configuration, and are archived in the versioning system within each lifecycle environment.

Microservices

Although we built this set of features before microservices achieved their current popularity, we firmly believe that this approach supports the microservices approach. Node.js is ideal for microservices given its low memory footprint and general efficiency for many usage scenarios (typically where the server-side processes are I/O-bound rather than memory or CPU-bound).

DevOps

Also, what we are providing is essentially a monoglot PaaS (i.e. it supports a single development language, Node.js). In our on premise MBaaS product that is launching in May 2016 we have fully re-architected the platform to use OpenShift by Red Hat as the PaaS, though we still only support Node.js. What a PaaS provides for developers is an abstraction where developers can stage directly to each stage of the lifecycle (potentaially including production) lowering boundaries between “dev” and “ops”. In our SaaS offering the complexity of managing the infrastructure (hardware and software) to support this is outsourced to Red Hat. When deployed on premise this workload is undertaken by an enterpise cloud operations team, who then hide that complexity from the developers. In all cases it encourages a DevOps culture where the developer can move from dev through test to production with the requirement for pass the ball to a separate team with a separate set of concerns. Of course to do this effectively developers do need to to leran how to architect the solutions to scale, but ironically the efficiency of Node.js means it is the exception rather than the rule when such resource limits are hit. Indeed container-based PaaS architecture supported by Red Hat offers the promise of dynamic scaling (e.g. automatic provisioning of new containers to manage peak load), and automated resilience (e.g. automated restart of non-responsive components).

Conclusion

This is a short description of some best practice we have learned in FeedHenry and Red Hat Mobile over the past six years of enterprise mobile solution development, deployment and management. We do still believe that Apache Cordova is a very productive cross-platform development environment for mobile solutions, and that such solutions benefit from an common JavaScript mindset across the “full stack”.