1. Revenge of the Tablet: Just as Android created some serious competition for Apple with smartphones, it’s about to do the same with the tablet. 2012 will be the year when we finally see some serious alternatives to the iPad.
2. Gesture-Based TV: The last few years have seen gesture-based technology come to the phone, the tablet and the game console. Next up will be the TV. Why search for the remote when you can just snap your fingers? And why not run apps directly on your TV?
3. Machine to Machine: Next year we’ll see more and more real-world applications of M2M. Our cars already talks to the cloud; very soon anything and everything of value will.
4. Social Goes Enterprise: I predict that 2012 will be the year when most corporations start to embrace social networks and look for ways to harness their value. Think: “Who in my company knows how to optimize Android for video the best?”
5. Return of Zero Install: With the introduction of HTML5 and 4G/LTE, our tablets and smartphones will no longer be dependent on apps and app stores. We’ll be able to access an app’s functionality without the installation.
6. A Planet’s Worth of Data: With sensors showing up in everything, the amount of data we can gather and keep is exploding. What if all this data found its way back to the cloud? Well soon it will, and we’ll need BI tools that can help us understand not just a company’s worth of data, but a planet’s worth.
7. Consumerization of Healthcare: With government incentives pushing doctors from one side and patients pulling from the other, we’ll soon see an explosion of consumer-to-doctor options. We’re already seeing sites like Zocdoc change the way you schedule an appointment. A patient record that you can actually see can’t be far behind.
8. Political Apps: Technology is having an increasing impact on politics, especially elections. With the 2012 U.S. election less than a year away, you can bet this cycle will see an explosion of political apps for tablets and smartphones.
9. Voice Gets Smart: With the Siri feature on iPhone 4S, you can bet voice apps are about to get a major boost. We’ll see voice interfaces getting built into more and more devices.
10. Agile in Business: This rapid development approach, which favors continuous results over analysis paralysis, is making its way into business. Agile makes sense for companies that want to get into new markets quickly and use learning over planning as the way to “get it right.”

After understanding the requirement, it was learnt that the application doesn’t need to access any of the native feature of mobile device like camera, accelerometer. In other words the application was a data driven application having rich user interface. It triggered the thought!!! Why not have Mobile Web Application for this?

What is Mobile Web Application?
Mobile Web Application is web application, optimized to run in mobile device web browser. Some of the parameters under consideration are:

• Screen size
• Bandwidth
• Device orientation
• Native user interface

Present day mobile web browsers contained by smart phones like IPhone and Android can show almost every website that we can open on desktop browser.
Advantages
One of the biggest advantages of Mobile Web App is, it can be uses over the variety of smart phones. If any customization is required for specific mobile device model, then it can be done on the server side. There is no need to create ports for different mobile devices.
In case of there is any update in the application, then the web server contents only needs to be updated. The mobile client will always get the updated contents.

Conventional Mobile Web App

Conventional mobile web can be created in any web platform like PHP, ASP.NET. It essentially consists of a home page which uses HTML mark-up along with CSS and javasript. Mobile user starts the web browser and hits the home page and starts using the application. For each such page, the server sends and HTML mark-up and images to have a decent user interface. One drawback here is the look and feel. Once the user starts the web application, he/she gets an off-deck user experience. The mobile web application look and feel in most of the cases is very different from the mobile device native user interface.

Leveraging HTML 5 & CSS3

HTML 5 is fast catching up. W3C has already created the draft for HTML 5 and CSS3 standards. Popular desktop browser like Chrome, Firefox 4.0 and Opera 9 supports most of HTML5 and CSS3 standards.
Good news is, IPhone mobile safari and Android device web browser also supports most of the HTML 5 and CSS3 features. With support for CSS3 and HTML 5, the developers get extra arsenals for creating more sophisticated mobile web applications

Native Look & Feel using CSS3

With the use of CSS3 it is possible to have native look & feel for IPhone and Android devices. Some of the CSS3 features are:

• Text effects, Gradients
• 2D transformation
• 3D transformation
• Transitions
• Animations

With above feature we can add the animation and transition effect to mobile web applications similar to what IPhone and Android devices provide. Due to support for gradient and text effects in CSS3, we can minimize use of images. This also helps further to reduce the page pay load

Test Web page without any specific CSS.

Test Web page in Android emulator after applying CSS

Test Web page in IPhone emulator after applying CSS

HTML 5 features

HTML 5 provides many new features as compared to HTML 4. IPhone and Android mobile web browsers now support most of the HTML 5 features.  Some of the important HTML 5 features are:

• Local Web storage. Can be used to store the intermediate data locally and when required the data can be saved to cloud or the web server
• Access to Geolocation. Can be used to location based application
• Audio API. Can be used to control and play audio
• Video API
• Canvas support. A 2D drawing mechanism.
• Web Sockets. Real time application

Full Screen Browser Or Native application with embedded web browser (Hybrid)?

The most common way to start a Mobile Web Application on mobile device is to start the web browser and type the application URL.  We can use JavaScript to set the web browser to full screen mode. For some people still this may be dislike.
For such, we can have a native device application. This application then embeds the Web view. Of course, this device application needs to be created to all supported platform. The user downloads this native application from app store. When launched, it displays the embedded web view in full screen view and hits the application home URL. This way the user has a seamless user experience. With this hybrid one can also provide a mechanism to intercept the events in the web view. For example we can intercept click events for all hyperlinks in the view and then may call some native function using the device specific language.

Accessing phone’s native features

There are many instances, in which we may need to access the native phone features like Geo-location, accelerometer. At present not all native phone features can be accessed using JavaScript API from HTML5. Unfortunately not all native features can be access using the JavaScript API. Currently JavaScript APIs are available to access the Geolocation and Address book.
For other features like camera, accelerometer we need to use some bridge. Most common way is to use PhoneGap. It provides an interface to access the native features of mobile devices. It is available for IPhone, Android and other smart phones

The functionality demands special consideration on extensibility and configurability during designing of the module. The module/system requires support for a plug-in architecture where new web services can be added in future. High configurability will help updating integration parameters easily without any recompile and redistribution/redeployment. Desktop/Mobile applications – that requires social networking integration – should consider for forced auto-update in order to update plugin binaries due to changes in service APIs/protocol.

Different services support different authentication mechanism. These methods often change over time, and therefore, would be one cause for the service plug-in to require an update. Table below summarizes authentication mechanisms for different services.

Typical integration challenges like data transformation, network issues, orchestration etc. should be considered. One may have to incorporate transaction management if single requirement requires multiple interactions with these services.

Most of these services impose restrictions while interacting. Due considerations should be given to these limitations while designing and development.

Facebook has upload limit of 200 photos per album, however there is no restriction on number of albums. If there is requirement of uploading videos on FB, then it should be less than 1024 MB and length should not exceed 20 minutes. .The aspect ratio of the video has to be between 9×16 and 16×9. While downloading wall posts the API returns an array of post objects containing the last 30 days or 50 posts, whichever is greater.

YouTube has video upload limit of 2GB in size and 15 minutes in length. It supports lesser video formats as compared to FB. One can download only two videos per hour.

Picasa restricts photo and video size to 1 GB. It supports lesser video formats compared to FB – specifically it does not accept Flash (.flv) or Real Media Video (.rm) files. Although one can upload videos to Picasa, APIs does not support downloading videos.

Gmail supports POP3 and IMAP. If you need labels (attached to emails) information IMAP is the option.

GDoc has upload limit of 1GB. In addition it also has further restrictions on type of document like documents cannot exceed 512,000 characters, regardless of the number of pages or font size; spreadsheet cannot exceed 400,000 cells, with a maximum of 256 columns per sheet etc. Download APIs supports 2GB of download at a time.

Most of the APIs supports pagination while downloading, but for the services which does not support it one has to device own algorithm.

Finally, as technical support from network site is not that prompt/active and APIs sometime does not behave as expected one should consider more time during estimation and planning.

About the author:  Dr. Jim Walsh, CTO of GlobalLogic, leads GlobalLogic’s cloud architecture team.  GlobalLogic has designed and is implementing cloud-based carrier-scale streaming media solutions, cutting-edge analytic systems, and IaaS and PaaS systems for a number of multi-billion dollar companies.

In my previous blog post, I discussed the architectural principals behind good cloud design. Now let’s explore how to apply them to form a functional definition of a cloud-based system. For example, is a single virtualized data center a cloud? I would argue that while there is nothing to stop a cloud-based application from being deployed in a virtualized data center, there is also nothing about a single virtualized data center that requires or takes full advantage of the unique characteristics of cloud-based applications. So my short answer would be: No, a single virtualized data center is not a cloud. It does not impose the conditions of variable latency, location anonymity or other characteristics for which cloud applications are architected.

What if such a single-location virtualized data center uses private cloud technology provided by several excellent vendors, some of whom are GlobalLogic clients? Even here, I would argue that because it is in a single physical location, or even—in some cases—on the same rack, such a deployment is not in itself a cloud. It certainly may have some of the characteristics of a cloud—for example, a limited degree of location independence may be required to support the different latency requirements of same-rack versus rack-to-rack component connectivity. Still, such a single-location environment is not comparable to a world-wide distributed environment, and applications deployed on it need not be architected to the same principals as a full-scale Cloud system in order to work effectively.

So, at what point does a virtualized data center become a private cloud? Obviously at some scale this is possible, but where is the dividing line? I would say that, to be considered a “virtual private cloud,” the following conditions should be met:

1. There are multiple interconnected virtual private data centers with significant geographic separation between them (e.g., multiple continents). OR, applications are designed to scale elastically to utilize both the virtual private data center(s) and publically hosted clouds in a “hybrid cloud” model.

2. The provisioning of new systems that host the application components is entirely automatic and in response to load.

3. No human intervention is required to provision a new system, to deploy an application component on the system, or to de-commission an existing system.

4. Deployed systems and components can freely or algorithmically migrate between the distributed data centers in response to load, both with and (ideally) without human intervention.

Unless the above conditions are true, there is really no need to architect an application that follows all the cloud architecture principals discussed in my previous post; a more conventional approach would be equally suitable (unless you envision an eventual migration to a “true” cloud environment). However, I would not consider a deployment environment to be a cloud if it does not meet at least the “virtual private cloud” criteria listed above (although I admit that’s a high bar).

Perhaps a more useful concept to consider in this transitional time is an application’s “degree of cloudiness,” rather than a simple “cloud / not cloud” dichotomy. In reality, few existing applications or cloud infrastructures meet all the above criteria. However, I believe this is where the cloud is headed. It is in the embodiment of these principles that we will see the real benefits of this new paradigm.

That being said, there is nothing wrong per se with not being a cloud or a “full” cloud application! There is plenty of scope for non- or semi-cloud applications and infrastructures, both within organizations and as commercial offerings. When an application or an infrastructure is not a cloud or is instead a partial cloud, I think we should admit it without apology instead of trying to stretch the definition of cloud to encompass it. A definition is not meaningful until it’s clear what it does not apply to. If everything is a cloud or a cloud application, then the term loses any meaning. And I think the concept of the cloud is way too useful for us to let it just drift away!

About the author: Dr. Jim Walsh, CTO of GlobalLogic, leads GlobalLogic’s cloud architecture team. GlobalLogic has designed and is implementing cloud-based carrier-scale streaming media solutions, cutting-edge analytic systems, and IaaS and PaaS systems for a number of multi-billion dollar companies.

As I mentioned in my previous blog post, not all virtualized systems are as cloud-oriented as others. From a functional standpoint, fully-realized cloud-based systems adhere to key architectural principles. Let’s look at some of the principles that GlobalLogic’s architecture team has found helpful in designing effective cloud systems:

1.     The underlying architecture is distributed. Although cloud computing and distributed architecture are in theory orthogonal, we have found that distributing the application architecture is a very important step to capitalizing on the full benefits of cloud computing, which we will demonstrate in the subsequent bullets.

2.     Each component is highly tolerant of the variable degrees of latency between messages sent to and from other components. When invoked, one resource might be deployed on a VM in California while a resource it communicates with is located in India. When called another time, the resources might be co-located on the same subnet in the same data center in Europe. Called yet another time, they may be in Argentina and Ukraine. Although an extreme example, the point is that, in a fully cloud-enabled application, you don’t have full control over where your components are located –nor should you care. Components should not rely on their communication being synchronous, or even having latency between components that is low and constant, since resource location is dynamic. To be sure, some commercial cloud offerings let you specify an affinity for a particular data center or even the same equipment rack—but applications that require such approaches are, in my view, using a workaround and not architected to take full advantage of this new paradigm.

3.     Cloud components are as stateless as possible, with each state maintained in a shared, distributed data store or cache. The dynamic “elasticity” of a cloud application is a key benefit because you can create or destroy instances of any given component at any time in response to the workload. To take maximum advantage of this, the individual components in a pool must be as interchangeable as possible—in particular, they should ideally not carry state. If a component must carry a state, it should be maintained in a separate data service so it can be shared between component instances. This can be done via a distributed data store or caching mechanism, which can provide redundancy for fault tolerance and support for elastic scalability.

4.     The system tolerates eventual data consistency rather than enforcing immediate data consistency. Because distributed components operate asynchronously and with variable latencies, enforcing instantaneous global data updates can lead to race conditions, bottlenecks, retries and a general loss of system efficiency. Cloud systems are better architected to support local updates that propagate through the system over time and are consolidated eventually (as opposed to a single monolithic data repository that is guaranteed complete and accurate at all times). While this may not be possible or desirable in every situation, note that even bank ATM systems are generally architected to enforce eventual consistency of your account balance. And “eventually” commonly means only seconds, although it may be shorter or longer depending on the system’s requirements.

5.     The system minimizes data movement by pushing code toward the data or acting only on the data closest to each compute node. Utilizing a centralized data source diminishes the efficiency of a cloud system because of (a) the time it takes to propagate data to the distributed components and (b) the components’ attempts to access or modify the same co-located pool of data with their variable latencies. To improve processing parallelism, it is better to move away from a physically centralized data store entirely. Instead, utilize a distributed data source that enables each processing component to act against its local data. Those intermediate results may then be consolidated at a higher level. This is how Google search is able to achieve such high levels of performance against the entire internet: data is distributed across many compute nodes. In such a “MapReduce” operation, each “mapper node” searches a relatively small amount of data contained in its local attached storage, with the results then consolidated globally at the reducer nodes. In applications where it is not feasible to distribute the data, it is better to move the compute nodes as close to the data store as possible, as this minimizes the impact of data traffic and latency. This location bias definitely is a workaround that makes the application less “cloud” oriented, but it is a workable paradigm where legacy data stores, for example, must be incorporated into a new cloud application.

6.     The system asynchronously redistributes data in the background. Since elasticity is a fundamental feature of the cloud paradigm, systems must be architected to tolerate the fact that machines may come and go in a planned or an unplanned fashion. Because application state must be retained somewhere—hopefully in a shared and distributed data service rather than in each individual component—the systems that carry each state must themselves be tolerant of being created or destroyed. In other words, when the pool of stateful components grows or shrinks, data has to be redistributed across surviving or newly created nodes. Also, new data coming into the system must be transferred to the components that will use it (this is true even in a MapReduce operation). Our preferred way to mitigate the performance and other impacts of these data movements is to implement them as “background” tasks that are executed asynchronously from processing tasks. The processing components that depend on the data must then be architected to tolerate temporary data inconsistencies, but this has other benefits as we discussed above.

7.     The system minimizes data movement as the component pool grows and shrinks. Moving data is expensive in a cloud system since data must sometimes travel at WAN speeds. In particular, the need for a “real-time” data transfer should be avoided due to its potential performance impact on the system. In systems where the data is distributed—for example, in the distributed web search scenario we mentioned previously—spawning or removing a stateful component requires that other stateful components surrender or acquire the data being managed by the new or deleted component. Because of fault tolerance, it is generally better to have data redundancy built into a distributed system so that removing a stateful component instance does not necessitate an immediate data transfer to ensure accurate results. By building the system to tolerate a degree of redundancy—e.g., filtering out redundant results at a higher level of the system—data may be cached or transferred asynchronously around the system to take advantage of the addition (or compensate for the removal) of a stateful component.

8.     The system maximizes the use of cache. Once your system is designed to tolerate data consistency issues, you can leverage cache more effectively. Use of a distributed cache is an important mechanism to support the separation of concerns that result in stateless components, asynchronous data distribution and eventual consistency (as discussed earlier). Some excellent commercial and open-source alternatives are readily available. Memory-based architectures with terabytes of reliable and in some cases non-volatile storage are becoming a reality for cloud applications, and cache-centric architectures that follow the principals described above will be well positioned to exploit these new developments.

Now that I’ve outlined the architectural principals behind good cloud design, I’ll discuss in my next blog post how to apply them to differentiate between applications that are cloud, partly cloud or not cloud at al.

What is the Cloud?
Part I: A More Concrete & Human-Readable Definition

As a leading R&D services player, GlobalLogic’s engagement with new technologies tends to be a leading indicator of what the market as a whole is doing. Based on what we’ve seen over the last twelve months, there is no question in my mind that the cloud has gone from an “interesting” to a “foundational” technology. I believe we will see the pace of major cloud-deployed technologies and business offerings accelerate in 2011 and beyond.

But what is exactly is the cloud? Many offerings and initiatives seem to be labeled as “cloud” simply because the word has become trendy. Misunderstandings about what the cloud is or isn’t have the potential to dilute this new paradigm’s impact, and I think it’s a good idea to get clarity on this point.

The defining characteristic of the cloud is that the assets required to deliver a unit of functionality (e.g., computation, data access, networking devices, etc.) are in unspecified and potentially dynamically changing physical locations. These functional units are addressable over the internet, usually via a URL and programmatically via paradigms (e.g., REST) and protocols (e.g., SOAP). However, these assets cannot be addressed as conventional physical resources (e.g., hostname or hardware-specific IP address) as they would be in a corporate network — except perhaps as aliases for an anonymous system. This “location anonymity” is actually what drives some of the most powerful aspects of the cloud paradigm.

It would be easy to interpret “location anonymity” as “cloud = ignorance of location.” However, a more useful characterization is “components of a well-designed cloud architecture shouldn’t assume nor care about having a specific location.” In other words, a cloud application or service is best architected so that each of its components can tolerate wide variations in (1) the proximity of the other components and resources it needs and (2) the physical locations of the clients it serves. In this sense, cloud is the software equivalent of geographic globalization, where modern business practices and technologies make the physical location of resources increasingly irrelevant.

In fact, independence of physical location is a key driver of cloud “elasticity.” If a given system is anonymous, its function can easily be grouped as a “pool” of identical systems that is addressed through a virtual load balancer. This system can achieve great scale because you can “create” new virtual machines from the same boot image whenever you need them and then “destroy” them when they’re no longer needed, thus achieving more economy. In a physically tied system, deploying more systems can take weeks if not months. Even in a virtualized data center, this process can involve considerable manual configuration effort. With the cloud, elasticity is intrinsic to the paradigm and only takes minutes when properly implemented.

Of course, independence of system components isn’t the only characteristic of the cloud. Some systems are more cloud-oriented than others, which I will address in my next blog post about the architectural principals behind true cloud-based systems.