As outlined in earlier blog (Is your application a candidate for cloud migration), any application can be deployed on cloud, using right cloud application framework. However, in order to take maximum advantage of cloud features like dynamic scaling and high availability, it is advisable to make some design changes in the application. Here is a list of a few such design considerations:

• Use of Decoupled Components
• Asynchronous Communication
• Stateless Application Design
• Choice of Database
• Data Storage Strategy

I plan to discuss these design considerations in some detail, in the coming sections.

Decoupled Components

As in case of traditional designs, more modular the application design, more will be the scalability of the application in the cloud. The trick here is to make independent application modules in order to make distribution and in turn dynamic scaling of application easy. Some of the techniques used for such decoupling are as follows:

• Use of API interfaces or Web Service Interfaces for module integration and interaction
• Use of atomic transactions within the modules
• Avoiding direct data exchange between modules as far as possible. All module data should be derived from the database.

All the steps described further in this article also contribute in decoupling the modules.

Asynchronous Communication

In addition to use of API/web services, the application can have Message Based communication between its modules instead of procedure based tight coupling. This will function something similar to the asynchronous communication in standard workflow modules.

Stateless Application Design

Stateless application design enables distribution. As a part of this, session state needs to be stored outside the application or component, in the database.

Choice of Database

Almost all the available cloud platforms support a variety of databases. Various extensions offered by cloud application frameworks make using these databases easier. Now-a-days in addition to traditional RDBMS like SQL Server and MYSQL, there is support for NOSQL database like MongoDB. Distributed database are offered as a service in the cloud application frameworks. The application design may want to evaluate use of any such databases, to further support distribution.

Data Storage Strategy

As a strategy, consider keeping dynamic data closer to the compute and static data closer to the end-user. This translates to storing the data generated in the cloud, within the cloud and storing the static data on CDN, near the end user.

Further Guidelines for data and application deployment

• Use of Cloud Application Framework: There are various cloud application platforms that provide faster deployment as they work directly off the source code repository like GitHub. Development using the cloud application framework may also be easier and faster compared to that using Cloud Platform API
• Automatic Configuration Processes: Automated configuration of new machines to be added in the deployment environment is vital in order to enable dynamic scaling. Machine images as well as various scripts can be used for this.
• Shorter Deployment Cycles: This will keep the cloud version latest, offering new features often
• Agile Testing: The testing needs to be faster and modular for the cloud setup. This will save time in the functional and regression testing. Most cloud application frameworks offer choice of test driven development, which can be very helpful here.
• Decision about which part of the application to be moved on cloud: This decision can be critical for big enterprise applications, where moving everything to the Hybrid / Public cloud may not be possible due to various security policies as well as need of complete control on the module deployment and workflow. Following guidelines can be used here:
  • Modules which are compute intensive and are needed for short bursts of time can be moved to the cloud
  • Peripheral modules can be moved to the cloud
  • Modules that may experience varying user load can be moved to the cloud
  • Use of private cloud or deployment restricted to the private portion of hybrid cloud can be considered for critical modules

Other than this, there are various design considerations related to security and cloud type. We will look at these in detail in subsequent blogs.

Any application can go on cloud, even without any design changes. However, following these guidelines, it is possible to design horizontally scaling application and reap all the benefits of cloud deployment. We will look at the guidelines for selecting cloud provider in the next blog.

It is now safe to say that the future of Software Application Space is ‘”Cloudy”, and for once, it is a very good thing! The Cloud platforms have been around for a while, but now more and more applications from Enterprise as well as Consumer space are seen to take advantage of them.

So the question is, which applications can migrate to cloud? Short answer: all applications.

For a descriptive answer, we should go into details of what the Cloud can provide us.

Cloud is basically offering Infrastructure (Platform) as a service. Once I migrate my application to the Cloud, I transfer the headache of setting up proper infrastructure to the cloud provider. This translates into various benefits for the application:

• High Availability
• Scalability
• Distribution
• Pay-Per-Use for infrastructure
• Easy ability to integrate with Social and other collaboration portals*

The scalability and pay per use architecture is vastly important for many applications. In the application lifecycle, there are times, when for a specific duration, scaled up infrastructure is required. Some examples can be – the holiday seasons for an eCommerce Retail Application, the benefits enrollment period for a Healthcare Application, tournament seasons for Sports Application etc.

This is a period where the user load can increase multifold, and the application provider needs multiple servers to handle that load, without affecting performance. However, outside this specific period, the infrastructure needs are pretty regular. As a result, hardware investment becomes a tough decision.

Cloud provisioning can be a perfect answer for such dilemmas. The cloud providers can make multiple servers available for short duration for any application. This scaling can happen transparent to the end users. The providers will charge only for the time the infrastructure is used.

In addition, the cloud providers will also take care to make the application Highly Available. To support this, Virtualization, Replication and Distribution are taken care at the provider level. As scaled up infrastructure is used, application performance is also no longer a headache.

Security has been a critical aspect of cloud deployment. However, multiple efforts by the cloud infrastructure providers as well as advance security techniques available at application level have reduced the threat level significantly.

There are multiple cloud providers like Amazon, Azure, Rackspace in the market. However, the application to be migrated need not directly interface with the cloud providers. There are multiple Cloud Application Frameworks like Heroku and AppHarbor that provide easy integration interfaces to make the cloud deployment possible at the click of the mouse. These Application Frameworks also work with multiple development platforms including .Net, Java, Ruby and PHP. In addition, they follow test driven development pattern, to make application development / migration easy.

Cloud supports SAAS whole-heartedly; however, it is not necessary for your application to follow the SAAS model in order to take advantage of cloud.

As per a survey published by Cloud Standards Customer Council (CSCC), cloud and the corresponding architecture changes also lets the application developers integrate easily with available social and other collaboration portals.
In short, any application irrespective of domain, technology and architecture can be migrated to the cloud.

In next article, we will take a look at the design considerations for an application migrated to Cloud.

* As per survey published by CSCC

Working with XCode IDE, I had always felt the need for a top-level entity that could support and organize my multiple XCode projects.  It wasn’t easy to access the files of one project from another in XCode 3.2, even if you had cross project references between them. Code sharing was always an issue if two or more projects used the same libraries and we had to copy them into each project folder separately.

Introduction of “Workspaces” brings in one of the new bits of “magic” that XCode 4 does for you: Multiple-Project Support. A workspace is basically a container meta-file that groups together multiple projects and other documents. It also provides implicit and explicit relationships among the included projects and their respective targets.

 Concept of workspace also allows us to create and use third party libraries in iOS projects in a much simpler way. However, the procedure is still more complex than it needs to be. Apple documentation suggests that it should automatically detect dependencies and other index classes across workspace.

 There are few key behaviors of workspace on how to share code across different projects in XCode:

• All the projects in a workspace are built in the same directory, referred to as the workspace build directory.
• XCode inspects the files in the build directory to discover implicit dependencies between them.

• Each project in a workspace continues to have its own independent distinctiveness.

 Steps that worked for me:

1. Create a new workspace and add the shared library project.
2.  Add the application project that would use the above shared library.  
3. Open Build Phase of shared library and make sure when copying headers it is grouped to public .
4. Open Build settings of application and in the Header Search Paths type in “BUILD_PRODUCTS_DIR”\usr\local\include .
5. And in Build Phase of target, include a link to static library (shared library) .
6. Now, clean and build and everything should build successfully.

 Incase you are having linking errors while setting up the workspace in XCode, you can refer this article whats-the-correct-way-to-configure-xcode-4-workspaces-to-build-dependencies

 All said and done, this worked like a charm for me. The workspace concept benefited me by sharing the code and build folders across multiple projects. Now, with the use of XCode 4 workspace we don’t have to copy the library files in every project and this saves lot of development time and effort.

 How is it better than eclipse workspace?

There are two main aspects in which I found XCode workspace to be better than Eclipse workspace:

1. In XCode 4.0, file indexing is done across the whole workspace so, code completion and refactoring operations act across all the content of the workspace. You can refactor the API in a framework project and in several application projects that use that framework all in one operation. This feature is missing in the current version of Eclipse.
2. All the XCode projects in a workspace are built in the same directory, which is referred to as the “workspace build directory”. As all of the files in all of the projects in a workspace are in the same build directory, all of these files are visible to each project. Hence, if two or more projects use the same libraries, you don’t need to include them into each project folder separately.

 How it improved my development process?

This article might give you an impression that setting up the workspace is a lot of work; but fortunately it’s not, especially if you do it more than once (considering that the aim here is to share code across multiple projects). I have been using this workspace approach for about four months with several projects and it’s definitely saved me a lot of time especially when the application projects used the same static libraries again and again.

 Instead of copying the source code from the “shared libraries” into every project (which used to take me an hour or so for every project), I just keep the shared library code in a separate XCode project and use it to build static libraries along with the application project. It is just a 5-minutes job now!

Coded UI Test (CUIT) is a new feature introduced by Microsoft for UI Automation. The automated tests created by CUIT are used for the functionality testing of an application.

To know about this tool, we started exploring its ‘Record and Playback’ feature. A very simple test case that we initiated this effort with had the following steps:

1. Launch Internet Explorer
2. Navigate to www.google.com
3. Search for “Code UI Test”
4. Validate if the result returned “How to: Create a Coded UI Test” link (an MSDN article on the topic)

Though it generated huge code for such a simple test case, the overall Record and Playback process highlighted the strengths of this tool. The well structured code and powerful element identification mechanism really caught our attention.

Besides that, the CUIT playback engine is also powerful. Playback engine performs duties such as searching for a control and ensuring that the control is visible and ready to be acted upon. Once the control is ready the engine performs actions such as ‘Click’, ‘Select’, ‘Set a Value’, etc. on it.

Recording feature alone is of course, not sufficient for building a full-fledged automation suite. However, CUIT’s recording feature certainly helps you if you decide to write your own scripts. It primarily helps in getting proper hierarchy of controls on the page (such as browser – iframe – div – control) and a set of properties that can be used to identify a particular control uniquely.

We also developed a UI Automation Framework using CUIT. While developing this framework, we experienced that CUIT has got several strengths. Its Recording feature really helped us save development time to a good extent.

Overall, if you decide to go with CUIT, here are some pros and cons of using it for your product:

Pros

1. The element identification mechanism is powerful
2. Uses C#, the compiled language, which comes with its own advantages over the scripting languages
3. Works well with Web as well as Desktop applications
4. Strong support for Synchronization. The Playback Engine allows settings such as “WaitForReadyLevel”, which can be either “UIThreadOnly” or “AllThreads”. It makes the Test Execution stop until either UI Threads or All threads are ready.

Other supported settings are– “Stop on Error”, “Match exact hierarchy”, “Search in minimized window”, etc.

1. It supports AJAX
2. The tests can be run on Remote Machines with the help of Tests Agents

Cons

1. Generates huge code for even a small UI operation, and hence hampers maintainability to some extent
2. Code Reusability is limited; it regenerates code even if it was already generated for a particular action
3. It uses almost all the Property – Value pairs to identify and locate the UI Controls which at times seems to affect the performance of the script

Guidelines for Automation using Code UI Test

1. Test creation is certainly a time consuming task, but it is worth going for it if the application under test is pretty stable and has got a large number of tests to be executed repetitively
2. Having said the above, it is not worth putting efforts in generating Test Scripts for an application which has frequently changing functionality
3. It can be used for Web as well as Windows applications. It supports,
   1. AJAX
   2. Silverlight

With such advantages and the reliability of the scripts, CUIT appears to be a promising tool for the UI Automation. There are other areas to explore. For example, we have not yet tried it with application containing Flash controls. That might be a topic for a future blog post, but in meanwhile, have you tried it with Flash? Write to us in comments and share your views.

Last month, I attended a RIA conference by Adobe at Pune. If I have to choose the most interesting part, I would go with the demo on use of Flash Builder 4.5 for Mobile application development with Flex 4.5.

Adobe is trying to answer one of the most sought-after questions – is it possible to develop an iPhone application without using Xcode? Is it possible to develop an application for Android that will run on iPhone as well?

Adobe wants to use Flex as a mechanism to answer the above questions. If you know Flex, you can build apps for Android, BlackBerry Playbook, iPhone and iPad.

Key features of this approach in creating applications for multiple mobile platforms are:

• In-built component library for UI
  • List, Busy Cursor, Scroller, ItemRenderer, different buttons and navigators etc.
• Auto scaling based on device pixel density
• Support for mobile themes including default
• Performance optimization
• Multi-resolution bitmap support

Here is a nice step-by-step overview on how to develop a mobile application using Flex 4.5 SDK. I must agree that this is really a huge step forward to enable developers concentrate on business needs rather than different platforms when it comes to mobile development. If we look at the rich feature list and support mentioned, there is no doubt about bringing down the cost of developing and improving the time to market for developers.

So, is Flex something that everyone should consider when building a multi-platform mobile app? I think the following questions and considerations will help one decide.

1. Do you have an existing app developed for either iPhone or Android.
   If you plan to extend support for additional platform, it would be 50-50 decision as development efforts involved will be same. Using Flex 4.5 could really make a difference if in the future, you plan to add more features to an existing app.
2. Which mobile platforms are you planning your app for?
   If your focus is mainly on platforms supported by Adobe, it’s worth evaluating.
3. Complexity of the app and features to be supported.
   I am yet to evaluate complete feature list, but overall it looks promising for simple data driven apps. It will take a while to evaluate and comment on its ability to support complex business requirements without compromising performance.
4. Is there any platform specific feature in your application?
   One of the challenges with respect to developing cross platform app is always the diverse set of platform specific feature list. For example, on Android, almost every device has back button to exit app whereas Apple apps are largely unaware of existence of back button or app exit functionality. Although you have a common code-base with Flex, it is purely based on similarities across multiple mobile platforms, which makes things difficult.

As mobile platforms are continuously evolving, Adobe’s attempt is commendable. What I am looking forward to now is how Adobe is going to incorporate support for future versions of these mobile platforms – essentially, how fast Adobe can add support for newer versions of operating systems in the future, to position its Flex platform over the individual Android/iPhone/Blackberry platforms.

Since we all started using Google & Facebook there is always a mentioning about performance these portals have provided. There are many articles/blogs/stories published on the same and all in all it stops at NoSQL. Early this year, when Netflix migrated to use NoSQL successfully, now almost everyone wants to evaluate this technique further. As first major NoSQL Now Conference started in August (August 23 – 25) this post is to give quick introduction of NoSQL and touch base pointers that will help in evaluating its use in existing or future projects.

NoSQL commonly expanded to ‘Not Only SQL’. In my observations, mostly it’s been considered as an alternative to RDMS as we are used to ‘SQL’ means RDBMS because of its popularity. In fact it’s not an alternative; it’s a different database model with set of different objectives. One more point to be noted here is, NoSQL is not a single system/solution rather it’s a class of database management systems that differ from classic RDBMS.

Recently I was working on solving a performance issue in one of the project. It involved intensive File IO and huge set of DB operations. Due to complexity of queries and size of data, module was lacking with respect to desired performance. Ultimate solution for the problem was to de-normalize existing DB schema, add batch processing and on top of it distribute batch processing across multiple nodes to further enhance it. I don’t see much difference between this solution and NoSQL at concept level, NoSQL takes this concept to a broader level. I would say NoSQL engines rely on a distributed storage systems and parallel processing across different nodes.

NoSQL implementations are generally categorized as below:

• Document Store – Apache CouchDB, MongoDB, SimpleDB etc.
• Graph – AllegroGraph, OrientDB etc.
• Key-value Stores – Apache Cassandra, BigTable, Apache Hadoop etc.

So why or when I will use NoSQL?

• For certain use cases so admired ACID nature of RDBMS takes its toll on application performance and eventually availability of the application. Some of the applications may not need relationship between data stored along with it.
• One of the most talked aspects is SCALABLITY. With classic RDBMS approach scalability is achieved with architecting the database properly. On the other hand, NoSQL datastructures have no predefined schemas. It focuses on only those datastrctures that can scale and restricting use of these datastructres ensures significantly higher horizontal scalability.
• High Availability is another important dimension of NoSQL which comes at relative cheaper cost than RDBMS. With synchronous replication of data, it ensures high availability.

As its still evolving, migration from RDBMS to NoSQL is not simple step; approach followed by Netflix is a very good example to consider here.

Though throughout this post I have compared NoSQL with RDBMS, it’s mainly to highlight features and explore use of NoSQL to solve problems faced with RDBMS. RDBMS is not going anywhere. In evaluating few of NoSQL engines; I have observed complexity as compared to RDBMS. Being this said, I think NoSQL implementations on Cloud will definitely be a next step forward.

In this post, we’ll take a look at some usability evaluation methods most commonly used in software design today. These can be applied at different stages in User Centered Design process. These methods can be broadly categorized into 3 categories – Inquiry, Inspection and Testing.

• Contextual Inquiry (Inquiry)
  When – Early stages of development, the information collected through this techniques is quite subjective
  Why –  When it is important to see how different users work in different environments/domains
  How – It is sort of an interview method where you need to go to the user’s workplace, ask them few standard questions based on your purpose and observe them while they work

• Focus Groups (Inquiry)
  When – Early stages of project/product planning
  Why – To obtain various reactions/opinion about a particular concept. It’s also useful for gathering different insights & preferences.
  How – This is a group interaction activity where a selected range of people gather to discuss a particular topic and give their reactions, opinions, insights etc. This discussion usually happens under the guidance of a moderator who follows a discussion plan.
• Heuristic Evaluation (Inspection)
  When – At any stage of design phase
  Why – To determine the usability problems in the design
  How – Usability experts (mostly one to three) judge the compliance of various user interface elements with established usability guidelines.

• Card Sorting (Inspection)
  When– Early design phase of the project
  Why – To design the Information Architecture and know how users would categorize and label the information
  How – Test users are given a unsorted collection of items and asked to organize them into categories, determining associations, grouping and finally label them.

• Usability Testing (Testing)
  When – Wireframe stage & also the later stage
  Why – To test the user friendliness of the application/product in terms of speed of use, ease of use, overall efficiency etc.
  How – This is a testing method in which the test user is observed using the product. Thinking Aloud protocol is a popular technique used here in which the users are requested to vocalize their thoughts while exploring the product or performing a particular task. The observation can be either obtrusive or non-obtrusive.

Above methods are followed by careful and systematic analysis through proper interpretation sessions which include evaluation of the most important usability problems and studying affinities.

At Harbinger, we use these methods regularly based on the needs of our clients. Do you use of any of these during your product design? Or are there any other techniques that make your product go from good to great?