EnableCloud

CloudWatch Custom Metrics for better decision making...

2011-06-27T20:23:00.000-07:00

AWS Cloudwatch is used mostly to monitor AWS resources. The most widely used monitoring are system metrics like CPU utilization, memory consumtion, DISK and Network IO. Based on these information, we can take decisions to change the environements to cater to demand fluctuations. Though traditionally these information were primary source of predicting load behavior or system performance, in today's world there are better business parameters which can be used to forecast demands.

For example no of active user sessions, user experience or response time, no of transactions etc can also be equally important to analyze the performance and take decisions to scale up or sclae down resources.

Even business factors like there is expected surge in demand like there is a increase in rain fall or sudden decrease in temperature or sudden change in a match result, can also predict user demands. Although these parameters are computed outside the AWS systems, these can be fed to Cloudwatch to forecast demands and scale up and scale down resources and ensure better user performance.

This can be achieved by using the new features of using custom metrics in CloudWatch.

AWS Resource, Applications, Business related data can be fed to CloudWatch and then these metrics can be used by autoscaling to take decision to scale up or down. Also, these data can be fed to monitor graphs or enable notifications.

The recent release of cloudwatch APIs are supporting this feature and is avalialble in .Net, Java, PHP SDKs.
Here is a blog from AWS for some more information http://aws.typepad.com/aws/2011/05/amazon-cloudwatch-user-defined-metrics.html

Amazon AWS ecosystem

2011-06-27T03:02:00.000-07:00

As more and more organizations trying to adopt cloud solutions or hosting solutions on cloud, the ecosystem around cloud providers are are emerging strong. There are software and services providers, who are constanstly innovating to ensure the cloud adpotion becomes smoother. That's what I thought will showcase in this blog to understand what tools and technologies available around major cloud providers. Undoubtedly Amazon AWS is one the major IAAS providers today that organizations are looking at for hosting solutions. As Amazon AWS is there for a long period of time, the ecosystem around it has also been built strongly.

I will show from the perspective of a typical application hosting on Amaon AWS. For an application to be hosted on cloud, there are few concerns that need to be address. These concerns can be termed as key requirements for managing the lifecycle of an application. Let's look at some of these key requireements are of course Availability, Scalability, Deployment & configuration Management, System Management and Monitoring.

Availability - Amazon AWS provides multiple availability zones inside each region. Applications components can be deployed across multiple AZs to ensure it survives when disaster strikes.

Scalability - Amazon AWS provides auto scaling to ensure the provisioning and deprovisioning of resources as demand increases and reduces. Also, AWS provides load balancing to ensure the load is distributed across the resources for a better performance.

Deployment & Configuration Management - Deploying software platform and applications, configuring them, managing multiple versions of the deployment are always challenging. It is necessary to create an environment that is repetitively deployable and easily configurable.

The diagram above depicts a typical Amazon AWS environment along with ecosystem tools.

There are tools which helps create templates describing an environment. An environment can be defined using a template e.g. no of servers, amount of storage, whether it needs a load balancer and in which availability zones etc. So, when templates are deployed, it automatically provisiones the resources and create an environment. Software like chef/puppet can be used to install software platforms and configure them as needed.

Some of these tools are

Rightscale (http://www.rightscale.com/)
AWS BeanStalk (http://aws.amazon.com/about-aws/whats-new/2011/01/19/introducing-aws-elastic-beanstalk-beta/)
enStratus (http://www.enstratus.com/)

System Monitoring & Management - Cloud resources like servers, virtual machines, storage should be monitored along with application components to ensure high availability. There are tools available which provides plugins to monitor such objects like Zenoss (www.zenoss.com) and Nimsoft (www.nimsoft.com) . These tools can be used to monitor hybrid kind of environments having cloud and non cloud resources. Cloudwatch monitoring from Amazon AWS is available to monitor specifically AWS resources.

Cloud This Week - Sept 18

2010-09-15T05:54:00.000-07:00

Here is a brief headlines on what happened this week in the cloud.

Amazon AWS

1. Amazon AWS has released micro instances with 613 MB of memory that can support 32-bit and 64-bit platforms. This will cost $0.002 for linux and $0.003 for windows instance. The micro instances can be used for applications or components of applications that will need less resources.

http://aws.amazon.com/about-aws/whats-new/2010/09/09/announcing-micro-instances-for-amazon-ec2/

2. AWS Console support for Virtual Private Cloud. VPC is to integrate amazon cloud with in house infrastructure. The in house security features can be extended to VPC. The instances in amazon are isolated and are not accessible directly from internet and they can be accesses through only company firewalls. Even subnets can be created in the amazon cloud and the internal IP addresses can be assigned to these instances.

The new console from amazon will help configure the VPC cloud, making it more user friendly and manageable.

http://aws.amazon.com/vpc/

3. Amazon released it's own version of Linux on AWS. This instance contains bare minimum services or applications to start with and amazon will keep upgrading or providing patches regularly. Amazon says it is optimized for EC2 environment and comes with some basic set tools for working in AWS.

Here is a link to the Amazon Linux Guide.

Google App Engine

1. Google App Engine now support multi tenant applications using namespace APIs. Now the same applications can be used by multiple tenants and their data will be segregated and isolated from each other. This can be done using different namespaces for each client organization. For data operations, the namespace should be used. The data viewer in the appengine management console also have a namespace field to view data for each clients separately.

2. 1000 entities for query limit is removed. Now the query will return end of the result or until the query reaches timeout limit.

Private Cloud

1. Vmware and HP have come together for and end to end private cloud offering. The highlights of this alliance are

HP Insight control is integrated with Vmware vCenter to provide single management infrastructure for both physical and virtual infrastrcure.
The storage attached to HP Proliant G6 servers and inside it can be converted into virtual pool of storage and made available to virtual machines. This removes requirement for external storage like SAN. This will help implement high availability using VMware vCenter without the need for an exernal storage.

Why large organizations may not find public cloud so attractive?

2010-08-22T23:44:00.000-07:00

Large organizations, may not find public cloud so attractive for the reasons below.

1. Disruption: Some applications can not be migrated as it is. The applications may need to be modified in order to accommodate to a particular public cloud technology or architecture. This will need investment and may cause disruption to the on going business.

2. Vendor Lock-in: As little standards available in the cloud, most of the public cloud implementations are proprietary. This means there will be a vendor lock-in once you develop for a particular public cloud. Migrating from one cloud to another will be challenging in future, once applications are locked-in to a particular cloud technology and architecture.

3. SLA – Service levels offered in terms of availability, security or performance may not be acceptable to some of the organizations. Organizations that required higher level of service levels, will find it inappropriate in spite of the cost advantage promised by the public cloud providers.

4. Security or Compliance Constraints – There may be some security or regulatory compliance issues, which may bar applications and data to be moved onto a public cloud. Some regulatory compliances may need data and applications to be restricted to specific premises or regions or geographies.

5. Integration Challenges – Most of the organizations have many applications running in their premises that are interdependent or tightly coupled. Moving some of these applications to public cloud may impose serious integration challenges from security or technology perspective. As most of the organizations have strict firewall and data communication policies, integrating applications, which reside either sides of a firewall, may be impossible.

The above issues are major challenges in considering moving to public cloud, especially for medium and large organizations. Neverthless, there can be some specific business case, where large organizations may find public cloud very appropriate.

Large organizations, may opt for private cloud or hybrid cloud, as they will have the money to invest to create this model.

Solutions on Cloud 4: High Performance Computing

2010-07-14T01:52:00.000-07:00

I am writing about this solution because of the announcement of Amazon's Platform for High Performance Computation this week.

Hadoop framework has been popular for sometime for running complex and time consuming jobs like indexing large amount of files or data ( millions or billions of files), data mining, running analytics for financial or bioinformatics analysis. Here is a list of real life use cases for Hadoop. Hadoop uses Map Reduce algorithm, to divide the work among hundreds or thousands of systems and then combining the results to produce the final output.

But the practical problem of running Hadoop is provisioning of large amount of servers. It may not be possible for most of the organizations to actually allocate so many servers for limited amount of time, to run these programs. Amazon solves the problem by providing a platform for running Hadoop, called Amazon Elastic MapReduce. It abstracts the configuration and administration of servers and the Hadoop framework so that developers can focus on developing map reduce programs to solve their problem. Amazon allows to provision as many server they want for the amount of time they require.

Solutions on Cloud 3: Disaster Recovery

2010-07-11T21:37:00.000-07:00

Building a DR site for your critical applications and data, can be an expensive affair. Especially if you are a small or medium sized organization. It calls for investment in space, energy, hardwares, personnel etc.

Todays' cloud vendors provide an infrastructure that can be leveraged to build a DR solutions at a very nominal cost. Building such solutions are definitely within the reach of SMEs and the benefits it can provide outweighs the cost.

There are three options for building DR solution.

1. Deploy the primary solution on your own data center and have the backup components running in the cloud. This deployment architecture can be used for cloudbursting.

2. Deploy both the primary and backup components in the same cloud infrastructure. For this the cloud vendors need to have multiple data centers, which are isolated from each other.

3. Deploy the primary components on one cloud vendor, while deploying the secondary components on the other cloud vendor.

Let's looks at some of the cloud vendors infrastructure and how it can help build a DR solution.

Amazon AWS

Amazon AWS has data centers in four regions ( us east, us west, europe, asia-pacific ). Each region has multiple availability zones. Each availability zones are independent data centers. Each availability zones have their own servers, own power supply and completely isolated from failures of any other data centers.

But the availability zones are interconnected with high bandwidth networks.

So, while primary components of your solutions running on one availability zones, the backup components can run either in active or passive mode in other availability zones. The AWS load balancers can route traffic to multiple availability zones in the same region, thereby actively using all components in all availability zones. But the solutions should have enough intelligence built into it, to initiate takeover when a component fails.

Amazon AWS S3, provides highly durable storage infrastructure, by redundantly storing data in multiple availability zones. S3 data can also be copied over to other regions. Amazon AWS EBS snapshots can be taken and stored in S3 for later retrieval.

GoGrid

GoGrid's multiple-datacenter feature also provides multiple data center. One in US East and one in US West that can be used to deploy a DR solution.

Rackspace

Rackspace does not have multiple data centers yet, but you can use it for deploying your DR site while running the primary components on your own data center. Rackspace's DR Service provides infrastructure and value added services like professional services for building DR solution for your organization. And these DR solutions can be customized as per organization needs.

Similary, the DR solution approach 1 or 3 (as specified above) can be built using any of the cloud vendors.

One of the most important factors to consider is the SLA contract with cloud vendor. It will provide insights into what services the cloud vendor can provide or can not provide and whether it will fit your DR solution requirements.

Please post your comments and feedbacks.

Solutions on Cloud 2: Storage

2010-07-10T06:03:00.000-07:00

One of the solutions that organizations can take advantage of in the cloud is storage. Opting for storage solutions in the cloud means cost savings in hardware, personnel and physical storage space. Managing storage devices, monitoring for storage capacity planning, managing tape libraries are expensive tasks for small and medium sized businesses. These services are available as Storage as a Service from multiple cloud vendors.

Storages that are available as services are can be any of the following types

1. Disk based storage - Raw data storage. Cloud vendors provide features like high availability, automatic fail over, regular backups, scaling on demand. These features make storage as a service very attractive. Small and medium sized organization can avail these features for nominal charges, for which they would have spent hundreds of thousands of dollars.

2. Databases - Databases on demand. Features like running databases in clustering or master-slave mode, regular backups and automatic recovery from failures are definitely appealing features to opt for these services.

3. File Storage - Files can be uploaded and shared with others. The ACL for files can be set for different levels of access for users.

4. Building content delivery networks - Delivery contents faster to users that span across geographies need lots of investment in building a content delivery network. But if CDNs are available at a fraction of this cost, then it becomes irresistible. Now any website can use these CDNs to improve performance and reach their users globally faster.

5. Modern distributed databases (noSQL databases) - These schema-less databases are gaining popularity for building solutions that are horizontally scalable.

Here are some of vendors that are providing these services


Vendors	Disk based Storage	Distributed Databases	RDBMS	File Storage	CDN
Google		Datastore (BigTable)		Google Docs
Amazon AWS	EBS	SimpleDB	RDS (mySQL)	S3	CloudFront
Permabit	Cloud Storage
Rackspace				Cloud Files	Limelight
GoGrid	Cloud Storage
Box.net				Cloud File Server
Microsoft			SQL Azure	Azure Storage
Nirvanix	hNode				SDN
Verizon	Cloud Storage

Besides the above basic infrastructure level services, there are third party solutions which are built on top of these and provide value added services. One such solution, worth mentioning here, is Zmanda Cloud Backup solution. It provides a GUI to configure and manage backups, and automate the process to a large extent.

Please let me know more about other solutions in you comments and feedback and I will keep adding to the list.

Solutions on Cloud 1: Overview

2010-07-10T00:55:00.000-07:00

I am starting another series on solutions that we can build on cloud. Some are general solutions, some specific to a particular cloud provider offering and some inspired from how organizations have exploited cloud to build innovative solutions.

There are several usages of cloud. Here are few examples.

Storage and Backup
Disaster Recovery and Fail Over
Mobility Applications
Content Delivery
Distributed Database
High performance Computing: Map - Reduce or Grid Computing
Business Intelligence
Application Hosting
Website Hosting
Testing

I will look into each one the above from the perspective of how to build these solutions on cloud, what are the pros and cons and insight into some case studies.

Migrating to Cloud 4: Identifying data

2010-07-09T22:50:00.000-07:00

Below are few considerations to identify data for migrating to cloud.

Consideration 1: Data Sensitivity and Privacy

As specified in the earlier post, sensitive data should be kept out of cloud as of now. For example, if an application deals with credit card information or personal information like social security number, then

1. Either the application should be kept out of the cloud

2. Or the part of the application and data that deals with sensitive information should be kept in house.

But to implement the second option, the application components should be loosely coupled. Then it makes it easier to move few components to cloud while keeping the other in house. As far as data is concerned, it is easier if the data is segregated properly.

Applications with monolithic design and tightly coupled are challenging to adopt such an approach.

Consideration 2: Regulatory Compliance

It must be understood, whether data need to adhere to any regulatory standards. These standards could be industry specific ( like HIPPA ) or across industries (like SOX). Some standards are also geography or country specific for example, EU does not allow storing personal information of Europeans outside the country.

Identifying data to migrate to cloud, must be carefully chosen as these must comply to the applicable regulatory standards.

Consideration 3: Data Transfer

If data transfer between cloud and in house applications are huge, then also it may become a bottleneck. Some applications may need to transfer data for transactional purpose or some applications may need to transfer data for batch processing. You must estimate the cost of such data transfers both in terms of performance and money.

If data transfer becomes a bottleneck, then either consider migrating all required application to cloud or migrate none.

Consideration 4: Data Storage and Backup

There are some considerations that work in favor of cloud. For example, if you solution has extensive data storage and backup needs, then cloud will be a good option. Some cloud providers like amazon provides highly available storage solutions. Data is backed up across multiple availability zones ( i.e. multiple data centers ) and hence data is never lost. There are third party solutions on top of cloud vendors that provider comprehensive storage solutions.

Besides above, you need not invest on storage products and monitor usage for storage capacity planning. In cloud, you can always allocate required storage capacity as the usage grows. This saves lots of upfront investment.

The best way to get all the information is from information architecture in your EA repository. The information model should provide all relevant information to take appropriate decisions.

Migrating to Cloud 3: Identifying applications

2010-07-09T10:25:00.000-07:00

As explained in the earlier blog, the scenarios can help to identify applications that can be candidates for migrating to cloud. But there are some more criteria that should be taken into account while identifying application or data migration.

Applications that are quite independent and can run in isolation are always best candidates for migrating to cloud. But applications, that need integration with other applications or resources, need to be carefully studied. Following are some of the considerations to make

1. If interface points between applications are not well defined, then it can be a real challenge to migrate such applications.

2. Applications that need deep integration with several other applications or other resources.
3. If applications need to communicate with other assets for most of the transactions.
4. If several applications collaborate with each other to accomplish most of the tasks, then either all applications need to migrate to cloud or none should be migrated. Migrating only few to cloud while keeping others on premise can lead several integration challenges.

Davis Linthicum in his book "Cloud Computing and SOA Convergence in your Enterprise" has explained this issue exceptionally well. He also advocates that enterprises, that have adopted SOA, will find it easier to migrate to cloud. That is mostly because the interface points are well defined and can be monitored for SLA compliance.

As shown in the diagram below, if the application interface points as well defined, it would be easier to migrate few applications to cloud, while the remaining application can still run in house.

The interface points can be subjected to SLA monitoring. SLA monitoring will enable performance and security compliance of applications.

Similarly, it is necessary to assess the sensitivity of data. If the data the application is dealing with is highly sensitive, then it may not be appropriate to migrate these data to cloud. Or part of application or data that are not sensitive can be migrated to cloud, while keeping the sensitive data in house. But in these scenarios, it is also imperative to understand the integration challenges.

I will look into some of the scenarios in coming blogs. In the meantime, please send your comments and feedbacks.

Migrating to Cloud 2: Assess and Identify

2010-07-09T08:34:00.000-07:00

The first and foremost step in migrating to cloud is to assess and identity. It is imperative to understand what values cloud computing will bring to the organization. And it will be specific to an organizational context. Each organization has it's own characteristic, it's own business drivers and pain points. Understanding your own IT dynamics is key to this initiative.

Cloud computing benefits are known but not applicable directly to any IT organization without understanding it's pain points. The best place to find the required information is Enterprise Architecture continuum.

For example, if you have already invested significantly in data center and you already have excess capacity to deploy the solution, then cloud may not look beneficial immediately.

Looking at the roadmap, if you encounter some of the following scenarios

1. Some developments are waiting for resource allocations like hardware, then these can be assessed for cloud deployements
2. Proof of concepts for market testing e.g. developing some ideas for testing market feedback
3. Stress testing or load testing waiting for resources
4. Batch processing applications which need huge amount of resources but for limited period of time
5. Build storage backup solutions (building such a solution needs significant investments)
6. Build a disaster recovery solutions (building such a solution needs significant investments)
7. Build content Delivery solutions - If you need faster delivery of contents across the globe but can not build such an infrastructure)
8. New solutions that will have variable loads or fluctuating demands
9. Existing applications seeking more resources to cater to increase in demands
10. Applications running on old servers, which are about to be decommissioned

Besides the above, there can be some of the non-functional requirements that can be fulfilled by using cloud.

If you think some of the solutions need higher availability (99.9%) of infrastructure and you do not enough expertise or resources to support such SLA, then transferring the risk to a IaaS provider is a good option. But you need to understand the providers SLA compliance levels.

Identifying the right components to deploy on cloud is a critical to the success of cloud migration.

The following are some of the inputs for doing the right assessment

1. Solutions Roadmap from enterprise architecture repository
2. Other architectural documents from EA Repository

3. Application/System monitoring and performance Reports
4. Capacity Planning reports

Please provide your feedback and some of your experiences on cloud migration.

Migrating to cloud 1: Overview

2010-07-01T08:46:00.000-07:00

We all understand what benefits cloud can provide? But for an organization that want to move to cloud, how should it proceed? Is there a systematic process or methodology that can help migrate to cloud successfully?

Well, as cloud is still new and evolving, the approch to migrate to cloud is also evolving. There are case studies and experiences from people and orgranization that explain some of the steps, difficulties and challenges in migrating to cloud. But above all, there is a book by David Linthicum which addresses this problem very nicely.

David's migration approach to cloud is based on an orgranizations maturity level in SOA implementation. He advocates an organization, which has implemented service oriented architecture (SOA), will find it easier to move to cloud. We will look at the reason, why?

These are the basic steps that can be done to migrate to cloud. These are very high level steps.

Understand the business driver and values
Understand the Risks
Create an inventory of assets
Identify the assets ( Applications & Data )
Build Prototypes
Create migration strategy and plan for Migration
Implement migration

Move the assets to cloud
Integrate with internal resources
Test the migration
Parallel Run
Roll over to cloud completely

Monitor and manage the new environment

The above steps can be grouped together into four basic stages.

Assess and identify
Plan
Migrate
Monitor & Manage

I will write more details on each basic steps in the following steps. In the meantime, please send me your feedback.

Moving to Virtualization : Part 1

2010-06-14T03:35:00.000-07:00

Virtualization is the foundation for creating a dynamic data center today. It is the primary component behind every cloud whether it is public or private.

I am planning to start a series on how to move to virtualization platform from traditional datacenter.

The reasons for moving to virtualization platform need not be mentioned any more as everyone working in IT infrastructure understands the pain points of traditional data center model. But if someone asks to quickly summarize the primary reasons then I will say "under utilization of servers, proliferation of physical servers, ever increasing space and energy cost and non responsiveness characteristic of data centers".

Virtualization seems to be the answer to all these pain points which creates a more dynamic data center. The responsiveness and flexibility is created by abstracting workloads from physical servers. They are not tightly coupled any more. Servers can be provisioned on demand based on workload requirements thereby increasing the data center efficiency.

I will write about some of the solutions that can be built using virtualization in a later post. Today I will look into what stages normally an organization has to go through to move it's data-center to virtualization platform.

There are mainly three stages to move to virtualization. For simplification purpose, each stage is defined as per the deliverables it outputs at the end of that stage.

These three stages are

1. What to virtualize?

2. How to virtualize?

3. Implement Virtalization platform

The first stage will output what to virtualize? This stage involves assessment of current inventory? The inventory includes servers, applications, softwares, network devices, storage solutions etc. There should be an up-to-date inventory assessment, which becomes an input for analyzing inventory to understand the candidates for virtualization.

Second stage involves understanding of virtualization technologies or product lines available for implementation, creating an architecture for the dynamic data center, and then doing proper cost-benefit analysis to arrive at the acceptable and cost effective solution.

Third and final stage involves, implementing the real virtualization platform. Besides, testing the staging environment and migrating to production environment, it involves managing the environment once it becomes operational.

I will go into details of each stage in the forthcoming blog posts. Please do not forget to give your comments and feedbacks on this post.

SaaS Architecture 6 : Extending data model

2010-06-13T09:16:00.000-07:00

It is only fair that customers will expect some degree of customization in the application. Examples of some customizations are

1. Personalization and branding of UI ( showing customer logo on the page )

2. Separate business rules

3. Extension of data model.

Out of these configurability options, extension of data model is very complex and I am going to discuss in this blog.

Extension of data is quite simple, if separate database or separate schema is chosen. Schema can be modified as per the customer needs. Though it will lead to further operational complexity for supporting separate schema for each customer.

But the real challenge lies where shared schema approach is chosen. Schema can not be modified as everyone shares the same schema. There are two approaches that can be used to implement data mode extension in shared schema approach.

Preallocated fields

In this approach schemas have few extra columns to save additional fields and these extra columns can be defined only as strings. Another metadata table can be used to define column field name and type. Following picture shows.

But the disadvantage is that the number of columns are fixed. So, tenants can only extend their data model to a certain extent. Alternatively, providing too many columns will leave fields unused and database will become sparse and wasteful.

Name value pairs

In this approach the base table (the data table for customer information) will have record id for each customer record that is inserted. Then meta data table can be defined for additional field names and types, that each tenant choose to extend. Then create a name value pair table to store new field values for these extended fields. The record id will relate to the extended fields and these extended fields are defined by the type table. The following picture represents this approach.

This is an extensible model and can store any number of fields. The application logic need to written to convert these fields to appropriate types before they are actually used in the application.

The only disadvantage is it is a very complex approach and needs a lots of testing to ensure quality.

Name value approach is best choice, which provides an extensible and robust SaaS architecture in the long run.

SaaS Architecture 5 : Shared Schema Approach

2010-06-12T18:19:00.000-07:00

As explained, shared schema approach is the best choice for a SaaS architecture from operational efficiency perspective. But in the meantime, it is also highly complex from developmental perspective. Extra care must be taken to ensure authorized access to data.

As all data belong to all tenants reside in the same table, each row must have required information to identify which tenant it belongs to. Adding tanant ID is the best way or adding an ID that can be mapped to a tenant ID uniquely is also an option.

Every query must be filtered using a where clause WHERE tenantID = <>. Views can be created using this filter criteria and all queries must be allowed only on the view relevant to a particular tenant.

Using encryption to protect highly sensitive data is a good design alternative to provide another layer of security. The encryption key should unique for each tenant. Either symmetric or asymmetric keys can be used for this purpose. Using asymmetric keys for data will come at a cost of performance. So, a better alternative is to use symmetric key to encrypt data, but protect the symmetric key using a key pair. Please consider encrypting only sensitive data rather than all data.

For better performance, data can be partitioned for faster access. Partitioning can be based on tenant ID. For example, tenants from 1-100 in one partition and 101-200 in another and so on. But, this may not uniformly distribute data, if usage patterns vary across tenants. So, you need to understand usage patterns of tenants before making a decision. But, keeping all data for a tenant in a single partition is always advantage, as all queries will be related one tenant only. Partitioning data using geographic locations of tenants is another alternative if you have customer spread across geographic locations.

In the next post, I will explain how to extend a data model in shared schema approach. In the meantime, please provide your inputs and feedback on this series of SaaS Archiecture.

SaaS Architecture 4 : How to choose a data model?

2010-06-12T06:48:00.000-07:00

I described the three data models for a multi-tenancy architecture in my earlier post. But how to choose one and based on which criteria? In this post, I will discuss some points that we need to consider while choosing a particular model.

1. If there are regulatory requirements that customers' data need to be isolated from each other, then you may have to choose separate database option. Such regulatory requirements may exist in some industries like financial or health care, which are highly protective about their data. So before making any decision, make sure you understand the regulatory requirements for your industry very clearly.

2. If you have a very large set of target customers, for example in hundreds or in thousands, then separate database option is NOT feasible. It is practically impossible to support thousands of databases. Shared database is the best option in this case and will ultimately provide financial benefits, once you reach a certain level of maturity in operational efficiency.

3. If you are providing specific features like SEPARATE backup or failover or disaster recovery strategies to separate customers, then you can achieve this by adopting separate database option. But if you provide same backup or DR strategies to all customers, then you can provide it at a lower cost using shared schema option.

4. If your customers are highly skeptical and unconvinced about the data being shared, then you need to consider separate database schema. It is not always about technology, sometimes you have to live and comply with customer's perception. Especially, if you are from an industry where customers are ready to pay a premium for a peace of mind that their data is secured and the privacy is guaranteed. So, understand your customers perception about data, security and privacy.

5. For shared schema option, you need to make more investment at development time as the complexity of developing such a solution is higher. You need to make upfront investment to reap the benefit later. But if you do not have the money to invest in development, but believe that you can bear the operational cost when you have the customers then separate database is an option for you. You can pass on the operational cost to your customer. But you will slowly realize that you may loose the competitive advantage if someone else can provide a solution with much lower operational cost.

It is imperative to understand technology, industry perception, regulatory requirements and many other environment factors before making a decision on choosing a particular data model for your multi-tenancy architecture.

Please share your experience on choosing a model.

SaaS Architecture 3 : Multi-tenancy Data Architecture

2010-06-12T05:55:00.001-07:00

Multi-tenancy is core aspect of any SaaS architecture. All SaaS based solutions should ultimately move to multi-tenancy architecture for the business model to work. It is necessary for any SaaS offering to keep their operations overhead to minimum to actually make this financially successful business model.

Multi-tenancy is the ability to host multiple customers data on a single instance while protecting everyone's privacy. Designing Multi-tenancy application is different than designing an application for a single customer. The complexity of the design increases if applications are made highly configurable. Configurability is introduced to make applications customizable for customers to a certain extent.

In this blog, of course we will look into data architecture of a multi-tenant application.

There are three models that can be adopted.

1. Separate Database

2. Shared Database, Separate Schema

3. Shared Schema

Separate Database

Features:

Each tenant has it's own database
Data of each tenant is isolated from each other
Datamodel can be extended
Data restoration per tenant is easier is case of failure
Maintenance cost is higher
May be useful for applications that need to comply with strict data isolation requirements ( Financial or Healthcare )

Shared Database, Separate Schema

Features:

Each tenant has it's own schema under same database
Different set of tables for each tenant
When tenant subscribes to service, the provisioining service can create schema for the tenant
Data model can be extended as per tenant requirement
There is some degree of isolation
Data restoration per tenant is complex in case of failure
Is feasible for application with less number of tables. As no of tables increases, this approach becomes very complex

Separate Schema

Features:

All tenants share the same database and same schema
Each record is associated by a tenant ID
Cost of maintenance is low
Code need to be more robust for security so that records are accessed by corresponding tenant
Data model can be extended as per tenant requirement
There is no isolation
Data restoration per tenant is complex in case of failure

SaaS Architecture 2: Must have modules in SaaS Application

2010-06-10T07:26:00.000-07:00

If you are building an application based on SaaS Model or if you are a packaged application vendor and planning to offer services in SaaS model, then you must have the following modules developed in your offering.

1. Usage Metering

2. Pricing Engine

3. Billing

4. Payment processing

5. Subscriber self service

6. Service Provisioning

Usage Metering

Usage metering modules should have the ability to measure consumption of resources, services and functionalities. Some examples, how many users or customer records, how many requests, how much of storage space, how many transactions etc. These information will be input to the billing module for charging the customer. This module is foundation for the pay per use model. These metering can be real-time or can be run periodically.

Pricing Engine

This module is used to set price for services or functionalities being consumed. The module should be accessed by authorized people to set pricing. If the market where the services are being offered is highly competitive, this module becomes very important to keep adjusting prices to remain competitive. There should be an approval workflow process for setting prices to ensure that the changes are actually intentional and authorized.

Billing

The output of usage metering will be fed to billing module for generation of invoices. It takes input from pricing engine module and calculate the charges at the end of the billing period and updates the customer record for viewing. It should have integrated with notification services ( Email, SMS etc) to send billing details to customer after invoices are generated. If customer has provided payment information, it raises a request for payment processing.

Payment Processing

This is a highly sensitive module as it stored customer payment related information like credit cards. These modules are integrated with payment gateways for processing payments.

Subscriber Self Service

SaaS based products are always available on demand. Customer should be able to signup, configure initial setup, provide payment details and ready to use the software. So, subscriber self service modules are very important for retaining customers. Now-a-days everyones want instant gratification. Customer should be able to do it themselves.

Service Provisioning

As soon as the customer signs up, all required details should be created immediately and the customer should be able to start using the software.

To be a successful SaaS provider, all the above moduled need to be developed and integrated into the main module. There are various third party products available for metering, billing, payment processing and can be used for faster integration.

Pros and Cons of Private Cloud..

2010-06-09T20:19:00.001-07:00

The concerns of security and privacy and loss of control, have made a way for private cloud. While it is impossible to ignore the benefits the clouds can provide, organizations are looking into alternatives like private clouds to first experiment with the concept of cloud.

No doubt, private cloud needs large investment and it can not provide economies of scale that large public cloud offer.

Internal IT should may not have skill to keep pace with the speed of change in cloud technology. Unless the private cloud adapts to the change in technology faster, it may become obsolete soon and a burden at the end.

Private clouds can be used as stepping stone for public cloud. People who are skeptical about public cloud, may start with the private cloud on a smaller scale and make sense of the benefits it provides. Or organizations who have invested heavily on hardware and can not get rid of it, may reuse them to build private cloud for internal applications or development or testing purpose.

Private clouds can not provide the benefits that public cloud provides like no capital spending on hardware, no maintenance or operations overhead or pay per use. Private cloud needs upfront investment on hardware and softwares.

Organizations who have invested in virtualization can go one step ahead to build private clouds to get benefits like self provisioning, dynamic pool of virtualized resources or resources on demand.

In my opinion, private clouds are not an option for small and medium sized enterprises, who look to save money by not spending upfront or capital investment.

Private clouds are good options for large enterprises who have a strong internal IT team to create and manage such an environment. As mentioned earlier, private clouds can become a staging environment before moving to public cloud.

SaaS Architecture 1 : Key Architectural Aspects

2010-06-09T09:47:00.000-07:00

While discussing with a customer, who is planning to move their application to SaaS model, we concluded on four key architectural aspects for developing a SaaS based application.

These four aspects of architecture are

1. Multi-tenancy

2. Configurability

3. Scalability & Reliability

4. Security and Privacy

Multi-tenancy

Multi tenancy refers to hosting all clients on single instance of application. Until now, it was always one instance per client for companies providing services on ASP model. But as the number of clients increase the complexity of managing these environments also increase if separate instances are provisioned for each client. So, the key to SaaS model is to host all clients on a single instance, and ensure that clients are able to access their part of data. Multi-tenancy brings many benefits like improved operations efficiency and providing feature updates simultaneously to all clients.

Configurability

As all clients access same instance of the application, it is very difficult to cater to specific client needs if the application is not highly configurable. Different clients will have different personalization requirements on presentation layer, specific data model extensions or different business rules. All these can be fulfilled only if the application becomes highly configurable. Clients should be able to configure and extend functionalities.

Scalability & Reliability

SaaS based applications will need to support hundreds or thousands of clients at some point of time. So, these applications need to be designed to handle high traffic volumes and still comply to SLA commitments like performance and response time. Also, the application should be designed to recover quickly from the failures or disasters. Imagine, how downtimes can cripple thousands of customers, if the application does not recover quickly. So, for a SaaS application to be successful, it need to scale out and run reliably.

Security & Privacy

All Clients data will be on a single instance. Care must be taken to provide enough security and privacy so that no clients can not access other client's data. Mostly these clients will be competitors in the real world and need assurance from the SaaS providers that their data is protected from unauthorized access from other clients. In fact, the clients identity should also be kept secret from other clients.

Any architect who designs a SaaS application must look into these four aspects seriously. Only addressing all these four aspects of the architecture will ensure a good and successful SaaS model.

Some interesting Q&A from AWS talk by Matt Tavis

2010-06-04T01:34:00.001-07:00

Here are some more interesting Q&As from Matt Tavis's talk on wednesday evening at ThoughtWorks, Bangalore.

Q1. Someone from the audience told that they encountered "Resource Not Available" error, while trying to spawn more resources from the same availability zone. They were spawning all resources in the same availability zone assuming communication between availability zones will be effected because of network latency.

A. There is of course no guarantee that resources will always be available for creating new instances all the time. There might be shortage of resources sometimes, if there are too many simultaneous requests. But there is no reason why someone should allocate all resources from same availability zone. Resources can be allocated from other availability zones. As the availability zones in a region are connected through high speed network fibers, there should not be any network latency for instances communicating across availability zones in a region.

Q2. The 1024 bytes limitation on simpleDB row size sometimes makes it difficult to define large sized key-values ( multiple values ) in a single row. What is the workaround to this problem?

A. Two workarounds to this problem can be applied.

First: The workaround to overcome this limitation is to split some key-value definitions into multiple rows and then join them in the runtime in the application.

Second: Provide a S3 location in the Simple DB key value column and then pick up the properties file from this location in the runtime to read long value properties.

Q3. How to integrate applications running on cloud with legacy systems running within enterprise's network?

Approach 1: Create a vpn tunnel between the cloud application and the mainframe applications and the interfaces like 3270 terminals can be accessible to the cloud applications through VPN tunnel.

Approach 2: Write web services wrappers around the mainframe applications and expose as web services. Normally web ports are accessible from outside enterprise networks, so the cloud applications can make a direct call to these web services and which in turn interacts with the mainframe applications.

Q4. Is Amazon planning to provide and support vertical stacks out of the box for various applications like LAMP?

A. Currently there are many third parties providing these kinds of stacks on top of Amazon. But if Amazon sees opportunities or increasing demand for any particular stack, they may consider providing and supporting it. For example, they saw good demand for Hadoop and provided it on Amazon Stack. It is offered as Map-Reduce currently. It abstracts the complexities of configuring a hadoop environment for hundreds of servers. Currently map and reduce functions can be written and deployed to run on hundreds of servers very quickly and with little configuration.

Q5. Is there any plan to support VMWare images to run on amazon stack directly?

A. No. Amazon will not tie to any particular virtualization technology.

Q6. How Amazon ensures security from hypervisor security loopholes?

A. Currently the virtualization technology on amazon uses hard partitioning of memory, CPU and Disk space. So, there is no way an application can access other applications' memory or disk space. Unused memory or disk space is not utilized for other instances. As far as, network access it concerned, the network traffic is controlled by security groups. An instance can only see the traffic that are allowed by security groups. So, it is advisable, to configure security groups strictly to ensure only authentic traffic reaches an instance.

Q7. How to integrate applications running on cloud with LDAP system running inside enterprise's network?

A. There are two approaches to integrate applications with the LDAP system.

Approach 1: Organizations hosting internal applications normally make use of VPC to isolate their instances in the cloud. These applications can integrate with internal LDAP server through the VPN gateway.

Approach 2: An LDAP server instance can be hosted in the cloud and the LDAP can be synchronized periodically with the LDAP instance in house. EC2 instance will authenticate against LDAP server on cloud.

Amazon Cloud Architecture Principles

2010-06-03T09:30:00.000-07:00

I attended the Amazon AWS presentation at ThoughtWorks in Bangalore on 02 June. The main objective was to introduce amazon AWS to interested audience who wants to explore Amazon Cloud capabilities. Presented by Matt Tavis, a Amazon's solution architect from Seattle, US.

Besides introducing amazon cloud features and giving a live demo, Matt also talked about the architectural principles for cloud applications.

Here are the list of architectural principles that he talked about.

1. Design for failure

Assume everything fails and design to overcome failure. CPU, DISK, Memory, Processes everything will fail at some point of time. So, it is necessary to design applications in such a way that withstand these failure and recover from it.

2. Loose coupling sets you free.

Design components like black box with properly defined interfaces. Designing loosely coupled components help applications scale easily. Scale out, not scale up is the new mantra. So, loosely coupled systems will help scale out systems easily.

3. Implement Elasticity

Scale up and down systems as demand changes. This will ensure optimized resource usage and being adaptive to demand fluctuations. Amazon provides features like auto scaling to implement elasticity.

4. Build Security in every layer

Implement security groups, encrypt data in transit and at rest, use encrypted file systems, rotate AWS credential periodically and use multi-factor authentication to get access amazon cloud.

5. Do not fear constraints

Two examples giver are:

a. If processing needs more memory, it can be shared across multiple instances. A shared distributed cache like memcached can also be used for more cache memory and faster access.

b. If more database IO needed, then mutiple read-only databases can be configured. Writes allowed against master, while reads can be against the read-only databases.

6. Think Parallel

Simultaneously executing processes and then aggregating results. Like Map Reduce framework, hundreds of instance can be spawned to processes the requests and then aggregate the results.

7. Leverage many storage options for different activities.

SimpleDB for key value pair store.

S3 - file storage. Very good for storing large files.

EBS - Raw Disk storage.

RDS - MySQL Database. This feature comes with many automated backup and recovery options.

These are good architectural principle for any cloud development. Only the examples or scenarios are given from Amazon AWS perspective.

Hope this is useful to you.

LDAP intergration for Amazon Cloud...

2010-06-02T21:21:00.000-07:00

If organizations host some of their internal IT applications in the cloud, then it becomes necessary to integrate these applications with their LDAP service to authenticate the users. People ask questions what models to follow while integrating LDAP.

Recently I attended a seminar by Matt Tavis, Solutions Architect from Amazon in Bangalore. He suggested two approaches. Here are they,

1. Organizations hosting internal applications normally make use of VPC to isolate their instances in the cloud. These applications can integrate with internal LDAP server through the VPN gateway.

2. An LDAP server instance can be hosted in the cloud and the LDAP can be synchronized periodically with the LDAP instance in house. EC2 instance will authenticate against LDAP server on cloud.

I will write another post on how to integrate applications with AD FS to enable single sign on.

Fine Prints in Cloud Service Agreement: Data Security

2010-05-18T22:48:00.000-07:00

Cloud service agreements (CSA) are the contract terms and conditions for both the cloud provider and consumer before entering into a relationship.

CSA is the face of cloud providers. It specifies what it can provide and at what level of guarantee. It talks about providers strength of ensuring cloud security and privacy, which is of course the top most concern of Cloud computing.

CSA also provides details of who is responsible for what part of data security? Cloud provider may be responsible for providing physical and network security to protect data from unauthorized access, but consumer should be responsible for providing application level security. Consumer should also be responsible for uploading restricted content to cloud and ensuring it complies to applicable regulations.

What contract terms one should look for in CSA? There are several aspects that need to be looked into. In this series, we will look into only data security related terms and conditions?

1. Where are the data centers located? The location of the data centers are very important from the perspective of keep sensitive data in the cloud. For example, the electronic records of patients from Europe should be stored with in Europe.

2. What level of physical security is provided to the data centers? Who has access to these data centers? Whether they have proper authorization and auditing process in place or not?

3. Whether cloud provider's security policy is sufficient to comply with consumer organization's internal security policy requirements?

4. Whether the cloud provider agrees to undergo periodic auditing and security certifications? For example, a third party certification like SAS 70.

5. Do they do regular backups and have a recovery process in place that is conforms to organization's SLA requirements?

6. Are the backup taken in portable format so that the consumer can retrieve it's data if disaster strikes cloud provider or the consumer decides to move out of cloud provider environment?

7. What life cycle process do they follow to manage data? For example, if you delete data, whether that data is also deleted from backup or is retained?

8. What are the encryption mechanisms provided by the cloud provider? Are these encryption mechanisms the best available in the industry.

9. Can it comply with regulatory compliances if required? For example HIPPA, SOX etc.

We will look into other aspects of CSA in upcoming blogs.

Solutions for building private cloud

2010-05-06T03:04:00.000-07:00

Private cloud is a cloud infrastructure built within organizations premise.

Private cloud is an good option

1. For organizations which have made significant investments in data centers and also want to take advantage of cloud computing.

2. For organizations, which can not move certain applications or data to cloud because of regulatory compliance restrictions. A hybrid cloud kind of implementation can give them an option of deploying such applications / date into private cloud and other non-sensitive applications and data into public cloud.

3. Organizations can use a private cloud as transition bed to finally move into public cloud. They can understand and learn the skills to move to cloud and support applications in cloud.

There are lots of options to build a private cloud in house.

Following softwares are worth mentioning

1. Eucalyptus

2. OpenNebula

3. VMWare's vSphere

I will write another post about pros and cons of building a private cloud.

Migrating Applications to Amazon Cloud - Part 1

2010-05-04T05:56:00.000-07:00

I am starting a series of posts on how to migrate existing applications to cloud. The applications can be of different kinds. We will start out with simple web applications.

The intention of these articles are not to reinvent the wheel, but the point to solutions or products already built and available to do this job. We will look into some of these solutions and how they help migrating applications to Amazon Cloud.

I will also point to the products information pages and blog posts that explain how to do it.

In the first part of the series, we will look into CloudFoundry.

CloudFoundry can be used to migrate web applications that uses following software stack.

Apache web server, Tomcat Container and MySql.

They have provided a simple interface to upload your application war file and configure the deployment topology.

You can deploy all the components in a single EC2 instance or configure it to deploy different components (Apache web server, Tomcat container and MySql) in separate instances. And it automatically configures master-slave configuration for you MySql database.

CloudFoundry tools is in beta phase now, hence is available free of cost.

If your application war file is ready, then it will take not more than 10 minutes to migrate to Amazon Cloud.

How to start? Where to Go?

Here is the getting started guide.

Here is a screencast that shows how to upload your application to Amazon EC2.

Licensing for the cloud

2010-04-30T04:59:00.000-07:00

How licensing of softwares work in the cloud? Are the current licensing models suitable for cloud computing?

First of all there are licenses for the OS running and then the softwares that we install to run our applications.

OS licenses are taken care of by the cloud providers mostly. Amazon has started a pilot program of brining your own windows server licenses to the EC2. This is currently available only to US customers and in US region.

Software licensing models are surely lacking behind and not very compatible for cloud computing scenarios. You still need to buy licenses for your peak load. For example, if you run 100 application server instances during your peak load but only 20 servers rest of the time, you still need to pay for 100 server licenses. The licensing models for commercial softwares have not kept pace with cloud computing paradigm.

Probably because, the software vendors are not ready for commoditization of their softwares.

Open source softwares are best fit for the cloud environment. You can start as many instances as you want and run for as many hours as you want. That's why they are very popular. And most the migrated applications to cloud currently run open source software. I think they have made the right decision to use open source softwares and now benefiting from cloud opportunities.

Softwares with server licenses are worst, as you need to pay for the maximum number of servers, that you may need to run at some point of time. Though you benefited from moving to cloud but not on software licensing front.

Also, you should be careful about your auto-scaling features, as you may start server instances more than the actual licenses, that you have paid for. This would be a breach of software licensing contract. Currently there are no way to monitor and manage licenses in the cloud, at least not any that I am aware of.

Softwares that have CPU hours licensing model are definitely most welcome and is the way to go for most software vendors in future to keep in pace with cloud computing.

My suggestion is that you must understand the licensing models before jumping into cloud, if you are using commercial softwares. Also push your vendors to come up with a cloud compatible licensing model.

It is only matter of time before the software vendors are forced to adopt models for the cloud.

Security designs for Amazon AWS cloud

2010-04-30T03:36:00.000-07:00

Security is becoming my favorite topic. What need to be done to ensure that our data is safe in the cloud. Here are some recommendations while deploying applications in the cloud.

1. Always use trusted public AMIs, whether it is windows or linux.

2. Disable root logins in your systems. Access systems using SSH shell and using keys. Users should use sudo for administrator jobs.

3. Never store user credential information on machine images. It is advisable to build AMIs with minimal software. On booting, initialize the instances with required softwares and configure it. Sensitive data like user credentials or database user-id/passwords can be passed in the command line while booting the instances. These information should never be persisted in EBS or bundled with AMIs.

4. Encrypt the file system on EBS. XFS + RAIDO is a good option. If your applications read/write any information on the file system, then encrypting the file system is a good idea.

5. Encrypt your backup files. After taking backup of your EBS volumes and before storing in in S3, make sure it is encrypted.

6. Encrypt the sensitive data in database or keep sensitive data out of cloud. Use the keys to decrypt the information in memory and never store decrypted data on persistence store or file system. Clear memory after required operations are complete.

7. Use security groups to ensure only required access is given to authorized people and systems. Deploy different components of application in different instances e.g. use separate instances for web server, application server and database servers. And enable security groups for strict access.

8. Use SSL for encrypting data in transit. Users should access and transfer application information using SSL. Atleast enable SSL for those functionalities which access critical pieces of information.

9. Use multi factor authentication for accessing your amazon account information. It will provide higher security.

10. Harden your OS to remove unnecessary services running and unwanted users from the system. Tools like Bastille are good for hardening linux OS.

These are basic security steps that need to taken to ensure security of your data and applications in the amazon cloud.

Here is a good whitepaper from Amazon on AWS Security.

Amazon releases AWS in Asia-pacific Region: Singapore

2010-04-28T22:04:00.000-07:00

Amazon has finally released AWS region in Singapore, Asia pacific. Earlier this year Amazon had released an edge point in Singapore for it's CloudFront solution. This is a good news for Asia pacific customers and Amazon's commitment to continuously increase better experience with it's cloud solution.

Already Amazon AWS value add service providers like RightScale and enTrust have planned to release their offerings in asia-pacific region very soon.

All AWS offerings EC2, S3, SQS, SDB, RDS, Notification service, Cloud Front will be available Singapore region. Amazon will now push hard it's offerings in the Asia Pacific region.

Here is the announcements: http://aws.amazon.com/about-aws/whats-new/2010/04/29/announcing-asia-pacific-singapore-region/?ref_=pe_2170_15199740

Cloud will make your CFO happy

2010-04-27T09:50:00.000-07:00

The cloud economic benefits are so compelling that it will make your management especially happy. Let's look at some factors why it is so promising financially.

Expenditure

-------------

On premise solutions need capital expenses for buying hardwares, setting up data-centers etc. As capital investments are funded by cash reserve or loans, the rate of return should be higher than cost of capital. Also IT Capital assets depreciate faster (about 2-3 years), so the return on the investment should be realized during this short span.

Cloud computing expenses are operating expenses and funded from revenues.

Cash Flow

----------

All investments for on-premise solutions are upfront investments. But it is "pay as you go" for cloud computing.

Financial Risk

--------------

As the investments are upfront there are high risks involved if the returns are uncertain. The risk is low in case of cloud computing, as it gives you flexibility NOT to incur the expenses if the returns are low.

No huge upfront investment with reduced financial risk is an advantage for organization choose to adopt cloud computing.

But I must emphasize, that careful calculations and comparisons should be made with available organization data, to arrive at a conclusion on how much benefit, moving to cloud can offer. The benefits can not be same for all organizations. Some organizations might have additional data center capacity or might have reached highest level of maturity in IT operations. Moving to cloud may not offer additional benefit to them.

You must take inspirations from others, but MUST do the ground work properly to evaluation the transformation.

Last but not the least, organizations must also consider the cost of not moving to the cloud. Will talk about it in a later post.

A Cloud Security Leader?

2010-04-25T22:15:00.000-07:00

Eveyone's concern on cloud secuity and privacy is actually driving innovative solutions. This is what is going to happen and many innovative solutions will emerge and make the case for cloud computing more compelling.

One such leader is definitely CohesiveFT. It's product VPN-Cubed can create overlay networks in the cloud. The overlay network can created in a single cloud or it can span across multiple clouds or between cloud and oranization's private infrastructure. An overlay network is "a computer network built on top of another network.

This solution can be used to implement following security related solutions
1. You can bring your own static IP addresses and assign to virtual servers on public cloud.
2. You can run solutions that rely on multicasting (some clustering solutions use multicasting)
3. Extend existing network monitoring solutions for your datacenter or private infrastructure to monitor cloud infrastructure as well.
4. Deploy solutions across multiple cloud and still configure it as part of the same network. The overlay network can span acros multiple cloud. (Clouds that VPN-Cubed support). This feature can be exploited to implement failover strategies.
5. All communications are encrypted in the overlay network. It can create a industry standard IPSec based VPN. IPSec protocol prevents attacks like man in the middle, DoS or network intrustion.

VPN-Cubed is currently available on Amazon EC2, GoGrid and terremark's vCloud Express. It has a free edition AMI in Amazon, which can be used to create a virtual private network on cloud of upto 5 instances.

These innovative solutions will fill the gaps and make a compelling case for organization's to adopt cloud. Here is an article on how VPNCubed compares to Amazon VPC and is more complete solution.

Load or Stress Testing on Cloud

2010-04-25T10:18:00.000-07:00

I forgot to mention in one of my earlier post "Suitable or not Suitable for Cloud" that load or stress testing is one of the suitable business cases for the cloud. Simulating an actual production load is not always possible as it would require similar setup that needs lots of investment. Most of the organizations do not have enough investment for such stress test setups. Organizations normally do a stripped down version of stress testing to find out any obvious bottlenecks.

Cloud can come handy in carrying out a real life stress testing scenario. In fact cloud can be used for both:
1. Deploy and scale applications on cloud to do stress testing
2. Generate load for your testbed

There are few good testing tools available for cloud testing of applications. Two tools that stand out are SOASTA and PushToTest.

Here is an article on how SOASTA was used to simulate 1 million concurrent virtual users to test myspace.com. 800 EC2 servers were run to generate such a huge traffic.

SOASTA's CloudTest has on demand EC2 instances to quickly and affordably simulate the real time web environment. Multiple instances can be started to simulate more users. Simulating this kind of scenario in house is a real challenge and opting for cloud is an abvious advantage.

SOASTA can test web applications and services which support SOAP, REST or HTTP(S) protocols. It has recording, monitoring and analystics tools to perform end-to-end testing and analysis. Please check it out here.

Similarly, PushToTest's TestMaker is available as Amazon AMI. This can be used to simulate thousands of concurrent users. You can check the product here.

Cloud testing provides few visible advantages.
1. No more buying licenses, setup software and hardware for the testbed
2. These services are available at commodity prices. Pay only for what you use and how long you use. No need to incur heavy software costs like traditional test tools.
3. Test can be done to simulate geographically distributed users using various cloud providers or mutiple regions in Amzon AWS. This is quite close to real life scenario for webstites providing services globally.

This shows how Cloud Computing is changing many faces of IT. Please give your comments or send mailto: manaranjan@enableapps.com

Creating Security Perimeter in Amazon AWS

2010-04-25T04:48:00.001-07:00

The concept of perimeter security is to create fortified network boundaries for servers to restrict access to only intended traffic using firewalls and provide network security from malicious attacks like network intrusion, man in the middle attacks and packet spoofing.

Amazon provides two solutions to create similar solutions in the amazon cloud.

1. Security Groups

2. VPC ( Virtual Private Cloud)

Security Groups

-----------------

Security groups can be defined and linked to EC2 servers to restrict traffic from particular set of IP addresses and allow access on particular ports. Security groups act like virtual firewalls.

For example, traffic can be allowed from internet on port 80 to EC2 instances running web servers. But traffic from only web servers are allowed on a particular port to EC2 instances running application servers. Similarly, traffic can be allowed only from application servers to EC2 instances running database servers. This is to make sure that unintended access are not allowed to servers.

VPC (Virtual Private Cloud)

-----------------------------

Amazon's VPC solution can be using create virtual private network by isolating EC2 instances and connect to enterprise's existing IT infrastructure using encrypted IPSec VPN Connection.

IPSec protocol is designed to prevent network intrusion, DoS and Man in the middle attacks. Organizations can create a subnet for EC2 resources and assign an IP address range for EC2 instances within subnets.

This is a good option for organizations looking to move to cloud but considering integrating with their existing infrastructure using secured networks.

Cloud Computing & why it matters

2010-04-24T02:15:00.000-07:00

There is a wonderful presentation on "Cloud Computing & why it matters" by Simon Wardley. I loved this one. He talks about how innovations become products and ultimately a commodity which are normally available as services. Like electricity which had seen this transition from being one of the hot innovations in early nineteenth century to become a regular commodity later. Countries built grid to provide this to every home and it became ubiquitous.

Similarly computing power will also become a commodity and this utility will be available as a service.

Simon talks about how 4 parameters effect this transition. Concept, suitability, technology and attitude.

The concept is already there. Is the industry and environment suitable for this revolution? Is the technology available for this transition? And lastly the willingness of organizations to change and adopt this change.

He also mentioned that once computation becomes commodity, it will loose it's spark. It will not be strategic to business and will only be a cost of doing business. Like electricity is not a strategic differentiator any more, it is only a cost of doing business. Everyone will have access to computation power depending on their need and their ability to consume.

I agree that cloud computing is not a technology but a process of transition of computation from being a product to become a commodity and being offered as a service.

I thoroughly enjoyed the talk. It is only 14 minutes talk.

Suitable or Not Suitable for Cloud

2010-04-23T18:12:00.001-07:00

Customers ask normally, whether they can move everything to cloud or selectively move to cloud. It is actually a good question to ask. Cloud is not a solution for everything. Until unless you gain from moving to cloud, why bother at all. And the biggest promise cloud provide is economic benefit.

Let's look at some business cases, where cloud makes lots of sense and where it makes little or no sense.

Business cases that are good fit for Cloud

1. Specialized functionality

--------------------------

let's start with an example. NY Times wanted to convert their 15 million scanned documents into pdfs and create searchable indexes. Total size of this documents are 4 TB. It would have taken months to do this task. But they did over a weekend in amazon cloud using 100 of linux servers. Most importantly they could do it using a credit card.

Similar functionalities that need huge amount of resources but not on a continuous basis is definitely a good fit for cloud.

There are some cloud offering that solve specific problems. For example, Amazon's CloudFront. It is a good fit for content delivery around the globe. They have edge point servers across the globe and your contents can actually be cached in edge points to delivery contents faster. Imagine if you have to actually setup such infrastructure across globe to achieve this. Amazon provides this at a fraction of a cost that you would actually incur if you decide to go on your own.

There is no predefined list of specific tasks that fit the cloud. You need to look at your need and decide by comparing cost-benefit between cloud and in-house solutions.

2. One-off tasks

----------------

One time tasks that need computation power. For example, if you need to create searchable index on you documents one in a month. Then upload the documents, run your programs (Map-Reduce a good option) to create indexes and then download the indexes. Again look at your requirement and decide.

3. Inconsistent load/demand

---------------------------

Applications that have variable or seasonal load. Applications that are accessed by users between a time-frame e.g. only during day time having a peak load for only 2/3 hours. Or if your application or website is accessed during holiday seasons or pertaining to a event like sports event that happens once in a year. These are good fit for cloud. There will be lots of unused capacity if these solutions are hosted in-house. Cloud provides excellent economic benefits for these kinds of applications. You can scale up or down depending on demand and these can be automated in most of the cloud provider environments.

4. Expensive or no expertise to run in-house

------------------------------------------

If you are a startup and do not have capital for investment in your own infrastructure. If you do not have expertise to build data centers, applications or run your IT operations. Then cloud is a good fit. Cloud is pay as you go and can be scaled as business grows.

5. Time-to-market is essential

-----------------------------

If you need to develop and host something very quickly and you can not waste valuable time in ordering new servers, setting up infrastructure. Then cloud can be your friend.

Cloud is not a best option for what kind of applications

1. Applications that need deep integration into your enterprise

-------------------------------------------------------------

If you application integrates with several other applications in your enterprise and all applications can not be moved to cloud. If your application interacts with many applications for most of the work it does. Then moving this application may require compromising on performance or security aspects. These applications are not a good fit.

2. Highly sensitive and heavily regulated data

-------------------------------------------

Sensitive data must be kept out of cloud unless you have a very strong security implementation. There are some regulation that data can not be kept out of organizations's premise or national boundaries. These kind of applications are not good fit unless cloud providers provide solutions specific to solve these issues. Amazon EC2 provide data centers in US and Europe. So, you can choose where your data or application can run and hence comply to some regulations.

3. Applications already running in premise and have reached highest level of maturity

------------------------------------------------------------------------------------

I think no need to disturb applications that are running and have reached higher levels of operational efficiency. If you still want to migrate then you can do a proper cost-benefit analysis to understand implications.

Summarize

-----------

Cloud and some applications are made for each other. Some applications are good if they run in-house. If one suggestion I would give then that would be : Architects should compare cloud and in-house for all new application developments. And only after making proper analysis they should choose what is right for it. Rejecting cloud without considering pros and cons, is not advisable.

I hope you enjoyed reading this blog.

Please provide your comments or write to me at manaranjan@enableapps.com

Is cloud less secure?

2010-04-23T05:42:00.000-07:00

Whenever I attend any cloud sessions or seminars, most of the questions people ask are about security and privacy. Undoubtedly this is one of the major concern for the cloud adoption. But is cloud really less secure?

I think there are two aspects to this.

1. One is lack of awareness

2. Readiness for cloud migration ( Cloud provider and consumer )

The general perception is if my data is out there in the cloud, anyone can access it. It is not true. The same set of security technologies that is available to enterprises are also available in the cloud.

Let's see what are top Cloud Security Concerns

-----------------------

1. Data protection

2. Access Controls

3. Network Vulnerability

4. Availability

Data Protection

----------------

General best practices are that data should be encrypted in the cloud for protection. e.g. customer information should be encrypted if stored in the cloud to protect privacy.

Keep highly sensitive data out of cloud. Do all operations related to sensitive data in the premise of the enterprise and find a secured way to integrate what is in cloud and what is in enterprise.

e.g. keep credit card related information and do authorization related operations in the enterprise premise and return only results to the cloud.

This is where readiness comes into picture. Is your enterprise data properly segregated? Do you know what is sensitive data and what is not? Do your application components loosely coupled so that various components can be deployed in distributed environments.

Access Control

---------------

Ensure that right people gets access to right resources. This is where most cloud vendors are lacking. We do not see most cloud vendors providing a mechanism to integrate with enterprises' existing identity and access management infrastructure. There are ways to integrate it right now, but innovations need to happen here.

Network Security

------------------

Encrypt the data in transit in networks. Cloud vendors already providing a mechanism to isolate your instances and connect to your enterprise using VPN. Amazon AWS provides features to create Virtual Private Cloud using IPSec security. This ensures protection against Man in the middle attacks, Denial of service attacks and Packet sniffing.

Amazon's security group features also provide a firewall like feature to filter relevant traffics to servers and applications.

Availability

-----------

This is one fear that what happens if cloud vendor's infrastructure fails or disaster strikes.

So, before choosing a cloud vendor make sure if the cloud vendors have a disaster recovery mechanism, whether they have multiple data centers to fail over. Amazon provides data centers in multiple regions and available zones. So, some of their services automatically fail-over. But you also need to ensure your application architecture exploits these features to remain available.

What happens if cloud vendor goes bankrupt?

Find an alternative cloud provider and have a backup system running on it. It can be active-active or active-passive configuration. The good point is cloud is elastic. So, you need not have a full capacity deployment in the alternative provider environment. But when you fail-over, you can scale up as you need. Make sure you do routine drills to ensure this mechanism works as expected.

To summarize

--------------

Clouds can be more secure as cloud providers invest more in security as it is critical to their business. Cloud providers are doing more research, investment, testing and improving security infrastructure continuously. Small and medium sized companies probably do not have much investment and expertise to implement all aspects of security. So, for them moving to cloud can actually mean more security.

As far as perception is concerned increasing adoption will create more comfort and change in perception for other customers. Salesforce.com is a good example. More and more customers are subscribing to it everyday.

So, before concluding cloud is less secure, please ask the following questions

1. What security aspects that is required for your enterprises are not available in the cloud?

2. Are your applications ready to move into the cloud?

3. What are threat perceptions if you move your application to the cloud?

Start little, keep learning and increase maturity in cloud migration.

Please provide your comments or write to manaranjan@enableapps.com