Reality Check: The rise of mobile-first enterprises and the impact on devops

Editor’s Note: Welcome to our weekly Reality Check column where C-level executives and advisory firms from across the mobile industry share unique insights and experiences.
Agile and development and operations methodologies have made sweeping cultural changes in enterprise IT. Many of these changes have had technological enablers – virtualized servers, server-based app deployments (think HTML and CSS), and unit test frameworks – that made continuous testing and continuous deployment truly possible. It’s hard to determine whether culture changed the technology or if technology change the culture. Either way, we are getting good at it. Take, for example, Amazon.com’s frequently quoted deployment stats: 11.6 seconds between deployments; more than 1,000 deployments in a single hour; and as many as 30,000 hosts receiving a deployment simultaneously. The numbers are staggering.
Meanwhile, in the face of all this progress, the mobile application tsunami has hit many enterprise IT organizations pretty hard. The response – the equivalent of a post-tsunami rebuilding program – is frequently to declare the company has become “mobile first,” which shows determination to make mobile the primary platform and move away from desktops, terminals and desktop browsers. But, there is bad news – the creative destruction wrought by mobile apps renders many of our shiny new devops weapons useless. The pendulum that swung out from distributed, desktop apps (DBase, Lotus 123) back to centralized control (Web servers) is once again swinging outward – and this time to billions of hand-held devices, each of which is a fully-capable computer in its own right.
Conceptually, mobile devOops should follow along the state of the art – but significant technical roadblocks can slow mobile-first to a crawl unless dealt with head-on. First, there are the overwhelming numbers – we have gone from a handful of browsers and Web servers to a completely new world of carrier networks, handsets, tablets and disparate mobile operating systems with multiple versions. Metrics-gathering tool vendor Crittercism estimates there are 2,582 device types running 106 operating system versions serviced by 691 carriers worldwide. Testing all of those combinations requires 189,121,172 runs for every test case. Even if it were possible to spin up real mobile devices as easily as we do Web servers, the size of the undertaking is still overwhelming. Moreover, we become ever more egalitarian: it was possible to ignore Linux-based systems when considering desktop Web – not many used Linux as a desktop system – but mobile first puts Linux front and center because the Google suite – Android devices – is based on Linux.
But we cannot spin up real mobile devices at will, and software emulators or simulators are an anathema to devops. For devops to yield its continuous-integration gains, test environments must be as close to production as possible (the “ops” in devops). So, virtual machines running emulators or simulators will not do. The real device has hardware, memory, processor, storage and operating system factors that are unique to each type of mobile device and each operating system. Constructing reasonable production environments is difficult but possible in mobile (most successful organizations target a popular set of phones and tablets running several recent versions of the operating system – iOS 6 and 7 account for more than 98% of Apple devices). But, building an efficient and automated devops scenario is harder yet.
Web browsers are freely available in unlimited quantities, while testing mobile-first apps requires the test engineer to have an actual device – itself a security exposure and an expense. Massive inefficiencies arise from four aspects of this need: either every tester has one of every device or we risk having idle testers, waiting their turn for a device; installing apps on mobile devices is hard because of the closed nature of the operating systems and their app-store models (none harder than Apple, who requires that an app be signed with a certificate created on an Apple website after joining and paying fees); tools used to install apps on mobile devices are prone to manual intervention (app stores, and command-line tools) and are not oriented to the kind of devops automation we take for granted in Web world – leading to the very real possibility that testers install the wrong app version; and collaboration among testers and developers may be severely impaired if they cannot share a view of what is happening with the app on the device. When the app is in-hand on a device on one continent, and the developer is on another continent, the collaborative loop gaps wider rather than closing, as devops should.
The cumulative effect of these problems – interference with collaboration, manual processes that are time consuming and error-prone, manufacturer interference in the processes and idle testers waiting for devices could effectively neuter the devops progress so many organizations are rightfully proud of. However, the good news is that many tool vendors see this need and have been working for some time to address it.
Clearly, new tools and new technologies must form new underpinnings – the devops culture is in place, it is time for tools to catch up. Collaboration struggles and device-sharing inefficiency can be greatly improved by using a private mobile device cloud that enables geographically dispersed teams to easily share and view mobile devices by remote links. Tools associated with the device sharing cloud must have both test automation and devops automation imprinted in their DNA – support must exist for automating user interface testing on real mobile devices and for constructing the mobile equivalent of a production environment in an automated, hands-off manner. For the tester, the experience should parallel her experience with Web – upon opening a viewer on the device, they should see the correct (and latest) build pre-installed, one that matches the objectives the app has for operating system and form-factor support. Build system automation that can drive a shared device cloud’s app-management functions is an answer.
The pessimistic view of “mobile first” is that it changes everything – and in some ways could return us to a darker time before devops was (technologically) conceivable. But a much more hopeful view is based in the awareness that these challenges exist and in the determination not to give back ground that was won before “mobile first” washed over the beaches. This time, the devops culture must bring technology to heel.