Why Saas and Continuous Delivery Is a Match Made in Heaven for Mobile Apps

In recent years, application usage has evolved and grown tremendously. Unlike core IT systems (ERP, HR, etc.) that are under the close scrutiny of corporate IT, Software as a Service (SaaS) and now mobile applications come with very different requirements. What’s valuable and efficient today might not be what’s valued tomorrow: SaaS and mobile applications have to constantly evolve and adapt to user requirements if they are to avoid becoming legacy applications. As a consequence, developers have to be in a constant “discovery-mode” for trends in user requirements, experiment with what works or doesn’t work and iteratively improve the ROI of the application.

Before we talk about the special challenges with mobile development, let’s look at how IT has evolved in application delivery to Software as a Service and ultimately, to mobile.

All software used to be packaged code that had to be installed, configured, patched, managed and upgraded by IT. Today more and more software is sold as a SaaS - entirely managed by the vendor providing it. While this might seem a superficial difference at first, it has radical consequences both for the consumer and provider of that service.

•SMBs don’t have the resources and competencies to support the IT burden associated with packaged software, and enterprise teams can’t necessarily get the attention they need from corporate IT. Subscribing to a ready-to-consume service, hence shifting the provision/install/manage burden from internal IT to a third-party vendor, enables an organization to use necessary software without being dependent on internal IT. 

•Many organizations have started to realize that what really differentiates them in the market is not how efficient they are at building data centers, installing and cabling servers or patching operating systems. They want to focus on true differentiators (revenue-generating activities) – such as developing/enhancing applications.

•As mobile devices grow in sophistication, more and more business users have started using them, too. The move to mobile changes the definition of where private data is allowed to reside. Historically, firewalls acted as the demarcation line between the inside – where data was stored - and the outside, where sensitive data wasn’t allowed to flow. However, this definition is rapidly becoming a legacy definition. SaaS – and mobile – applications usually have to access data outside of the firewall. 

Traditional software development is clocked by release cycles lasting anywhere from months to years. The shorter the cycle, the easier it is to get new features out and remain competitive; yet, IT organizations typically do not have the bandwidth to constantly upgrade to new releases. Upgrades require analysis, data migration, beta-testing, deployment to user workstations, possibly even to subsidiaries – and all of this is costly. Many IT organizations simply skip releases and wait as long as they can afford (or as long as the vendor allows) before upgrading to new releases.

Packaged software is not only painful for IT buyers, it is also painful for vendors. Since they’ll typically support older software versions in addition to the current release, they end up maintaining multiple versions. This is an expensive proposition.

In an -as-a-service model, it becomes the vendor’s responsibility to perform all of the management, patching, monitoring and upgrade tasks. Initially, this could be perceived as an increased burden for the vendor. Yet, when looking at the big picture, the analysis becomes vastly different:

•The SaaS provider will typically only offer a single version of its software: the version that’s currently running in production. It doesn’t need to allocate engineering, QA and release resources to focus on babysitting legacy codebases.

•SaaS vendors will typically release new versions on a weekly basis. Frequent releases means that the feature differential between the previous and the current version is very small and much easier to QA. Also, the release to production has a significantly reduced impact – thus, lower risk. 

•Since the vendor is operating the service, it is able to analyze, in real-time, how the new feature is impacting its customers. For example, is the new version of the Shopping Cart Checkout function leading to a better conversion rate? If the feature is a success, the vendor keeps it. If the feature is not a success, it can immediately be pulled back from production. Once removed, there is no need to support it for 10 years: the keep it/kill it decision can happen very fast at a very low cost - present and future.

•The SaaS provider controls the IT environment. The infrastructure variables encountered in customer installations of packaged software are endless. Huge amounts of vendor support time are devoted to resolving environment-specific issues. With SaaS applications, those issues disappear.

•The bug window is narrower in a SaaS environment. Without multiple versions and environment-specific issues to deal with, real bugs are uncovered earlier, often by unobtrusive techniques like dark- and canary-deployment, and fixes are delivered to all users more quickly than with packaged software.

•SaaS provider’s technology investment can now be applied to operational efficiency and feature/function development in order to improve competitiveness, providing a competitive edge for SaaS vendors compared to packaged software vendors.

While the promise of SaaS development is appealing, SaaS development comes with its own processes, tools and practices. A vendor that aims at pushing new releases on a high-frequency basis will only be able to do it if their ability to implement, build, test (units, UI, performance, etc.), release and meter (and possibly rollback) their services can happen in a smooth/no-friction manner: traditional packaged software practices come with a high-friction cost that makes this impossible.

In a SaaS world, the underlying philosophy is to always be release-ready. That is, the software is in a state at all times where it is ready to be released, if a business decision was made to do so. This might not be what you want to do for a variety of reasons – that’s fine – but the idea is to make sure your application is as stable as it can be at all times. 

The only practical way that applications can be release-ready at all times is to have all of the release processes, from code to production, fully automated and pre-integrated. If the processes have to be manually executed and maintained, the overhead cost and friction make it challenging to maintain a constant release-ready state. The mindset that frequently exists in typical packaged software environments (“Let’s start integration and testing of our application three months before release date”) doesn’t work in the SaaS/mobile world.

To that end, two concepts are extensively used in a release-ready environment: continuous integration and continuous delivery. 

In traditional development, testing activities take place sequentially as a phase near the end of development and before production release. However, Continuous integration (CI) is a process by which testing activities take place in parallel with the development process, continuously. 

With CI, whenever a developer performs a code change, a complete series of tests is initiated to make sure the code change doesn’t break the application. If the tests fail, it is easy to spot the issue and resolve it. Understand that the term “test” doesn’t simply mean basic unit tests: a CI server is able to coordinate a very sophisticated set of tests, gated by previous results (unit tests, integration tests, smoke tests, mobile testing, load-performance testing, security testing, etc.)

The result of leveraging CI is that it leads to higher quality and greater agility. 

Continuous delivery (CD) is the natural extension of CI, where the output of a CI cycle is pushed to a testing, staging, pre-production or production environment in a fully-automated fashion. This makes it possible to try the next iteration of the software in a real-life situation or, in the case of an internal deployment to production, to quickly deploy a new version of an application with no IT friction. 

Deployment can happen in stages (such as in A-B testing) and can be automatically rolled back if something goes wrong. Given that no friction is involved in pushing a new release to production, deployment can happen frequently, for incremental feature changes.

The obvious consequences of leveraging CD is that it leads to safer deployments, is an excellent discovery/validation process for new features and provides much faster time-to-market.

Now, what about mobile applications? 

Everything that we have discussed about SaaS applications applies equally to mobile applications. Unlike traditional packaged software running on servers, mobile applications are typically trivial to update by non-IT users. This makes it possible for vendors to support one version of their software and perform high-frequency release cycles. 

However, a number of additional constraints apply to mobile applications that SaaS applications (using a web browser/HTML front-end) do not face:

•Users might not necessarily upgrade to newer versions immediately. While some of this can be forced – for example, by preventing old applications from launching - the update cycle is not entirely in the control of the vendor.

•Mobile applications typically have to be provided through the mobile vendor marketplace (such as Apple’s AppStore). These marketplaces incur their own friction; it can sometimes take days before a new version is made available to mobile users.

•Consumers might not be willing to give an application a second chance if it doesn’t work well. It will get uninstalled and probably never re-installed again. On the other hand, a web site probably has a better chance of being revisited to see if something has changed.

•While a SaaS application can revert back to a working version from a buggy release in seconds, a mobile application might have to go through a full release cycle within the mobile device vendor’s marketplace, creating lots of unhappy users while this process takes place. This is clearly a much riskier scenario compared to web applications. 

These first four points reinforce the importance of rigorous testing for mobile applications before a new version is released.

•Mobile applications have to be tested on many different devices, different hardware, form factors, etc. This makes multi-platform testing a much more difficult problem to tackle than testing a few browser/OS combinations backed against a relatively well-respected HTML5 standard.  

Consequently, mobile application development not only requires a zero-friction development and deployment environment, but it also requires an environment in which extensive automated mobile application testing and qualification can occur, all in the same pre-integrated fashion.

It is clear that mobile is here to stay. As more and more businesses and consumers use mobile applications, the applications will develop in sophistication. To keep up with business demand and be successful in their markets, development teams will have to support this new application paradigm by adapting automated development technologies, processes and team culture. 

They should:

•Explore use of a continuous integration solution – to help develop/stage high quality code – and extend CI practices into application delivery in a process known as continuous delivery. There are many such solutions available today, perhaps the most popular being the open source Jenkins CI server. 

•Use cloud services to supplement on-premise infrastructure, as needed, for testing and running builds. Cloud services allow you to immediately scale up or down, as needs dictate, only paying for resources actually used.  No more begging for resources or incurring long delays while infrastructure gets ordered, received, provisioned and configured. 

•Finally, you must automate the testing process, itself – check out automated applications for testing various devices, form factors, operating systems and for the distribution of beta releases. Several good applications are available today for these important – and very tedious – activities, from vendors such as SOASTA, Zhubium and TestFlight.