High Availability is synonymous with Cloud. The entire application developer community believed so, till the Amazon incident in 2011. After that day, there are multiple ways and opinions that the application developer can choose to follow while ensuring high availability.

Lets’ start by looking at what the providers offer today:

• Packages: There are multiple models\packages offered by the cloud providers that advertise varying percentage of availability. Of course in many cases, your application can survive with less than 6 nines availability, if it is not a critical application and you don’t want to spend a lot of money!
• Availability Zones: Providers also offer availability zones. These zones are insulated from failures in other zones, as they do not share infrastructure with other zones. As a result, by choosing machines in separate zones, you can add to the availability of your application.
• Deployment Configuration: There are various choices in deployment configurations. This is more based on what type of deployment you are comfortable with.
  • There can be a single powerful machine hosting everything – web\app server, databases etc.   The advantage here is in case of failure, the entire machine can easily failover to the replicated mirror site. Obvious disadvantage is the performance bottleneck.
  • There can be the standard configuration with web\app servers as well as databases on separate machines. In fact, as cloud is advocating distribution, this type of typical deployment is in favor now-a-days. Here, in case of failure, there is a possibility, that your machines may end up in geographically dispersed areas, giving rise to network latency. To counteract this possibility, the providers have a feature where you can group your machines, so that on failure, the entire group does a failover to replicated mirror site.
  • Geographical Locations: The providers also let you have control over geographical locations of the purchased instances. This way, in addition to avoiding the network latency, you can also achieve higher redundancy.
  • One Stop Shop: The providers offer everything that the application may need in one place.  Eg. In addition to EC2 servers, Amazon also offers EBS \ S3 databases. They also provide services like Elastic Load Balancing as well as Cloud Watch and Auto Scaling. Opting for such setup will enhance the availability of your application multi folds.

However, in case the Amazon incident is a trust breaker for you, there is always the way where you can take care of the high availability on your own. There are various configurations suggested, where people have diversified their deployment configuration to involve multiple cloud providers. The idea is, you make a machine from one cloud provider a hot standby for your server currently residing with another cloud provider. This is a costly proposition, and the synchronizations, monitoring and failovers need to be managed by you.

In spite of the Amazon failure, I would anytime recommend trusting the cloud providers’ high availability claims. This is because of the huge infrastructure as well as sophisticated algorithms and strategies that the providers have in place for ensuring the high availability.  Afterall, nothing is perfect – even 6 nines of availability does result in a possible downtime of 30 seconds per year

Earlier we saw useful design techniques for a cloud enabled application. In this blog, we are going to look at various guidelines that help in the selection of Cloud Provider and Cloud Type for an organization.

Provider Selection

Typically, an organization’s Technical as well as Business needs drive this selection. Here is a list of few such aspects.

Technical Considerations

The organizations technology choices as well as criticality of information, user load etc. will play a role in provider selection as follows:

• Use of Framework / API: The application can be cloud enabled by using API available from the provider (e.g. AWS ) or by using frameworks like AppHarbor or Heroku. These API as well frameworks many times support specific cloud providers.
• Language of Application Development: Currently, the providers and frameworks favor specific development languages. E.g. Azure platform typically favors .Net based applications. Or Heroku framework currently supports Ruby and Java based development. So the choice of development language will in turn determine the provider.
• Security: Security Vulnerability is a major consideration especially in case of Hybrid and Public clouds. Focus on Access control and Authentication/ Authorization is essential for a successful provider. Most of the providers follow various security practices, and support techniques like identity management. They also offer multiple security certifications. The choice of right provider may depend on presence or absence of any of these.
  
• Portability: The choice of cloud platform may change over the period of time. So the ease of getting out as well as availability of tools supporting such porting can be an important consideration.
• Integration with Private Cloud: Many times the enterprises start with small Private Clouds. With time, there may be a need to expand the infrastructure. A common scenario here is formation of Hybrid Cloud. As a result, the ability to integrate Private Cloud with the public solution can also be a deciding factor.
  
• Easy access to other cloud features and tools: The cloud providers as well as frameworks provide access to many types of databases. They also support a wide range of tools for gauging cloud performance, finding memory leaks etc. They may come with easy deployment options as well as best practices like test driven development. All of this may influence the final selection.

Business Considerations

First and foremost of the business consideration is overall cost of the solution. This cost will depend on the architecture, cloud type as well as provider. Almost all providers offer a wide choice of solutions offering a range of costs.

Various other administrative criteria that apply while selecting the provider are:

• SLA: The service level agreement should be carefully studied and negotiated before deploying the application to the cloud.
  
• Support: The quality of technical support can be a deciding factor for ongoing relationship.
  
• Billing Models and Accuracy: As the major benefit of cloud deployment is pay per use billing, the provider selection can depend on various payment options as well as claimed accuracy in the billing.

Cloud Type Selection

Selecting a Cloud Type suitable for your business need is very critical, as it determines the overall architecture and in-turn the cost of the solution. Possible options for cloud types are Public Cloud, Private cloud and Hybrid cloud.

Public Cloud

On one hand where Public Clouds are cost effective, easy and efficient in sharing resources, they also provide lesser control over operations and storage and can be more vulnerable to security threats. In this case, no infrastructure is owned by the enterprise. Understandably, typical clientele for this option is applications with less sensitive data, less budget and higher user loads. They are also preferred for projects having a lot of collaboration work.

Private Cloud

Other end of the spectrum is the Private Cloud. As the name suggests, it provides maximum security and better control as enterprises own their infrastructure. Both services and infrastructure is maintained on a private network. Obviously, this is a costly preposition, usually favored by large enterprises.

Hybrid Cloud

Hybrid Cloud presents the ‘in between’ approach, and tries to provide the user with best of both worlds. A portion of the infrastructure is owned by the enterprise and public cloud space is used for the remaining. This spreading allows each business aspect to be in most effective environment. The challenge here is the communication between private and public cloud, without introducing security loop holes. The Hybrid cloud also needs to have its virtualization policies defined. There can be a high risk, if public infrastructure is used for sensitive data during virtualization.

In the next blog-post, we will look at High Availability and Cloud.

I recently got an opportunity to attend a TiE event “TiE Cloud: Breakthroughs in Cloud Security” in Silicon Valley on 2^nd Feb. This conference was hosted by Mr. Allwyn Sequeira, CTO & VP, Cloud Networking & Security, VMware and Mr. Pradip Shankar, Vice-President, Ericsson.

In many of the presentations and discussion forums in this event, looking at the questions and interest from the attendees, many of them emphasized on how to best set-up their cloud infrastructure securely. Cloud security continues to be a major concern for enterprises, in fact many of the CIOs expressed that they have no immediate plans to migrate to private cloud concerned by its complexity, security issues and fear of losing control over their data and privacy.

In one of the interesting presentation by Mr. Tim Mather who is an advisory director at KPMG, he focused on ‘The existing top security technologies that are broken by the cloud’:

 -         Cryptographic Key Management
-          Data Leakage Prevention (DLP)
-          Data Sanitization
-          Federated Identity Management (FIM)
-          Security Incident & event Management (SIEM)

According to him the Virtual Private SaaS companies such as CypherCloud, Navajo Systems (recently acquired by Salesforce.com) and Big Data platforms such as Red Lambda and Splunk will do fair in the cloud security race and ‘SIEM’ may have to consider its multiple vendor policy in the long term.

Currently, the need for increased cloud security is a huge challenge and slowing down the enterprise adoption of the private cloud, also the mobile virtualization has increased the attacks on cloud servers. Public clouds like Amazon services are a prime target of hackers and proved to be easy to hack as evidenced with the recent issue with Sony Corporation.

Nowadays, many of the telecommunication companies are turning out to be the cloud service providers (CSPs), The Cloud Security Alliance (CSA) in the standard body with 29,000 members and 120 corporate members working hard on securing the cloud services. As mentioned in one of the blog post (Is your application a candidate for cloud migration?) by one of my colleague, the multiple efforts by the cloud infrastructure providers are putting as well as the advance security techniques are now available at application level itself, it is reducing the threat level significantly. Let’s hope the future of the cloud will be more secure and many enterprises will follow the best practices and will adopt the secure cloud.

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.