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.
The RHMAP supports any 3rd party client-side SDKs required, whether for use in native development, or with 3rd party Apache Cordova modules.
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.
Server-Side (Cloud Apps)
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)
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.
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).
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).