Evaluating Software Quality Attributes for Applications developed using Google App Engine

Evaluating Software Quality Attributes for Applications developed using Google App Engine --------By Amit Piplani

Google App engine (GAE) is a web application hosting service. GAE can serve traditional website content too (such as documents and images), but the environment is especially designed for real-time dynamic web applications.
This article will use the FURPS model for evaluating the following software quality attributes (functional & non-functional) for applications developed using Java runtime for applications:
1. Functionality - Feature set, Capabilities, Generality, Security
2. Usability - Human factors, Aesthetics, Consistency, Documentation
3. Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure
4. Performance - Speed, Efficiency, Resource consumption, Throughput, Response time, Scalability
5. Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Install ability, Localizability, Portability
1. Functionality

Feature Set - Irrespective of the platform, feature spot holds the prime spot in any software development project & primary concern for software architect/designer/developer. So any web application irrespective of the platform should be able to meet the requirements.
Capabilities & Generality - Also an architect/designer needs to check whether the system capabilities can be met by Google App engine’s core components – Sandbox environment, datastore & the services(for example, applications relying on multi-threading, using lot of network bandwidth, relational database triggers, accessing the in-network data) before choosing Google as platform. Also the Google App engine costs nothing to get started and hence the capital expenditure [CapEx] at the start of the project is negligible (considering the deployment servers only). So this process can be somehow called as server- less topology at on-premise networks.
Each App Engine resource is measured against one of two kinds of quota: a billable quota or a fixed quota. Every application gets an amount of each billable quota for free. Customer will be charged only for the resources web app actually uses, and only for the amount of resources used above the free quota thresholds. Fixed quotas are resource maximums set by App Engine to ensure the integrity of the system. These resources describe the boundaries of the architecture, and all applications are expected to run within the same limits. They ensure that another app that is consuming too many resources will not affect the performance of your app.
The quotas and limits allowed by Google app engine platform needs to be checked too before making a selection & can be found on App Engine’s Site http://code.google.com/appengine/docs/quotas.html . So using the operational expenditure (OpEx) costs are directly proportional to the amount of resources used in a given calendar day. Also only Web Apps (with limited cron functionality) can be developed on Google App engine platform.
Security –
Sandbox environment increases the security feature of web app as application code can’t access the server on which it is running in the traditional sense. An application can read its own files from the file system, but it can’t write to files & it cannot read files that belong to other applications. An application can see/access the environmental variables set by App engine, but manipulations of these variables do not necessarily persist between requests. An application cannot access the networking facilities of the server hardware. App engine features integration with Google Accounts and hence can use the authentication capabilities of Google with minimal coding/configuration. Also If application is using the authentication via Google Accounts, App Engine includes HTTP headers in the response that give the information about the resources used by a given request.
So sandbox environment can act as "Blessing in disguise" with providing secured wrapper to web application but limiting the capabilities of an application & needs to be carefully checked to see if it really meets the needs of the required web application.

2. Usability
Although this concept is somehow holds the same weight age whether web application is developed using Google App engine Platform or not.
By using Google Web Toolkit (GWT) by far the quickest way to deploy a better UI experience full stack web application using the absolute best possible technologies available (Google’s scalable infrastructure, asynchronous http, image bundling, monolithic JavaScript compilation, easy RPC).Google app engine provides a separate set of Static file servers dedicated to delivering the static files (HTML, CSS, and JavaScript). These servers are optimized to handle requests for static resources. The static files for a given application can be uploaded along with application code along with configuring how static files are served, including the URLs for static files, content types, instruction for browsers to keep copies of the files in a cache for a given amount of time to reduce traffic and speed up rendering of the page.
3. Reliability
This attribute is primarily related to the datastore capabilities provided by Google App engine. The App engine datastore is designed for applications that need to read quickly, ensuring that data remains in consistent state. Unlike traditional databases, the datastore uses a distributed architecture to manage scaling to very large data sets.
The update of a single entity occurs in a transaction in App engine and each transaction is atomic: the transaction either succeeds completely or fails completely, and cannot succeed or fail in smaller pieces. It leaves the entity in consistent state. The app engine datastore natively supports local transactions. An application can read or update multiple entities in a given transaction, but it must tell App engine which entities will be updated when it creates the entities. The application does this by creating entities in entity groups. If a user tries to update an entity while another user’s update of an entity is in progress, the datastore API returns immediately with a concurrency failure exception. App engine uses optimistic concurrency control. Reading the entity never fails due to concurrency; the application just gets the entity in most recent stable state. Multiple reads can be performed in transaction to make sure that the data read in transaction is current and consistent with self. If application is getting lot of concurrency failures, then it’s important to design entity groups.
So the downtime of application will be due to either failure of the Google servers or when the application is taking lot of time to process the request (more than 30 seconds). The first one goes back to availability of Google infrastructure & no one can question presently their uptime and second point goes back to the performance issue of application (which will be discussed in next section).
4. Performance
The Google App engine's main components - "The sandbox environment, the datastore & the services" defines this quality attribute mainly. When the App engine request handler receives the request and identifies the application from the domain name of the address, it selects a server from many possible servers to process the request & this selection is based on which server is most likely to provide a faster response. App engine mitigates the risk of starting the application for every web request by keeping the application in memory as long as possible & when a server needs to reclaim resources, it purges the least recently used app. So distributed scalable architecture comes at the expense of a little performance degradation.
When the application creates new entities and updates existing ones using the datastore API, the call returns with success or failure after creating/updating entities along with updating every corresponding index. This makes queries very fast at the expense of the entity updates. But again Google app engine runtime uses the memcache service for caching the results of frequently performed queries or calculations. The application checks for a cached value, and if the value is not present in cache, then it performs the query or calculation & stores the value in cache for future use.
Also the runtime environment also limits the amount of clock time, CPU use and memory a single request can take. App engine keeps these limits flexible & applies limits to those applications that use up more resources to protect shared resources from “runaway” applications. But the response time for application can also determine the number of requests the application can handle dynamically. These figures can be checked for quotes & limits restriction defined by Google Platform and can be accessed via URLS mentioned in references section.

URLFetch Services, task Queues & cron jobs are also being defined so that web application can respond to web requests quickly & hence better the performance of the web application.
URL Fetch services are being used by app engine applications to access other web services. The service makes HTTP requests to other servers to retrieve pages or interact with web services and this interaction can be made to fetch the URLs in background so that request handler can continue to process the request. But the fetch URLs process must complete during the request handler lifetime.
Task Queues let request handlers describe the work to be done at a later time, outside the scope of a web browser. Queues ensure that every task gets completed eventually and configured at the rate at which queues are processed to spread the workload throughout the day. A queue performs the task by calling a request handler. It can include a data payload provided by the code that created a task and delivered to the task’s handler as an HTTP request.
App engine has Cron Jobs service for executing tasks at specific times of the day. The scheduled tasks can invoke a request handler at a specific time of the day, week or month based on the schedule provided in configuration.
Scalability attribute is considered as one of the selling points for web applications developed on Google App engine as the applications scale automatically. All three components – the sandbox environment, the (scalable) datastore & the services scales independently from each other.
5. Supportability
Testing –
JUnit test cases can be used for testing the services, datastore & task queues. Google app engine also provides access to different versions of the same application at a given moment of time and can be tested parallel by hitting different urls (along with version-id). This feature can be very useful if newer version of application can be tested completing before launching the same to outside world.
Manageability –
Very minimal as management tools to manage the resources used by application is being done by Google itself and report for the same can be accessed via Administration console.
Configurability -
web.xml is the configuration file defaulted for any web application. In addition to this, Google App engine appengine-web.xml needs to be provided before application is deployed or uploaded onto Google Infrastructure. Appengine-web.xml specifies the app's registered application ID and the version identifier of the latest code, and to identify which files in the app's WAR are static files (like images) and which are resource files used by the application.
Install ability –
As easy as it can get to install an application to Google infrastructure using admin console (via browser) or even using the plug-in for development environment.
Portability & Migration –
This can be one of the attribute not working in favor of the most of the platform providers as they provide vendor lock-in for data. Although the existing applications (using java.io, EJB’s, multi-threaded etc) are not the good candidates for migrating into Google App engine platform (as mentioned these ones are limited by platform capabilities. Even though there is vendor-lock in for the data being stored in datastore and need to retrieve the same back in some format so that the application can be hosted on in-premise infrastructure instead of Google platform.
Some of the open source applications are being written to synchronize the data between Google App engine datastore and relational database. For e.g., AppRocket is an open-source replication engine that synchronizes Google App engine datastore and MySQL database.
App engine includes a tool for uploading and downloading data via the remote API. The tool can create new datastore entities using data from a comma separated values (CSV) data file & can even create CSV files with data from the app’s datastore. These remote API comes into two parts – remote API request handler and the tools & the libraries that call the handler. The remote API handlers are part of Java & Python runtime environment whereas the remote Access tools & libraries are only available for Python. These tools & libraries can be used within Java Application via the Java Remote API request handler, but Google is working on it to provide these libraries and tools part of Java runtime too so that it makes the migration and porting of java application easily into Google Infrastructure.

So selection of Google App engine as platform is mainly driven by no-capital cost, pay-per-use model for resources used beyond free quota, scalability, manageability, server less on-premise infrastructure but limited by its sandbox capabilities and quotas, only web application support and on-going activities to add additional features in java runtime.
References
1. http://en.wikipedia.org/wiki/FURPS - FURPS Model
2. http://code.google.com/appengine/docs/quotas.html - Billable Quotas and Fixed Quotas
3. http://code.google.com/p/approcket/ - AppRocket provides live synchronization between Google App Datastore and MySQL