Cloud computing requires an architecture shift and new development models. Traditional application and data architecture does not enable optimal elastic scalability and maximum utilization of shared infrastructure. To build Cloud-friendly applications that will maximize benefits, development teams must apply Cloud application design patterns to build systems that exhibit parallelism, multi-tenancy, autonomy, distributed interactions, declarative definitions, separation of concerns, and federation. Cloud applications are not simply web applications deployed on external provider infrastructure. Cloud applications represent an evolution of the application model away from sequential processing, synchronous interactions, shared resources, and static clusters. There are some core issues that development teams should look at while architecting for the cloud:

· Manage resource capacity to ensure consumer demand is satisfied while maximizing resource utilization

· Scale workload processing and increase performance while minimizing infrastructure spend

· Allocate, provision, monitor, manage, and administer resources across multiple tenants

· Operation’s desire to right-size the infrastructure.

· Is the application architecture flexible enough to deploy on any topology while meeting deterministic performance requirements?

1. Cloud Web Application (Scalability): Host traditional Web apps and interactive apps that compose two or more data sources and services. These include traditional hosted Web applications, emerging composed applications that may utilize two or more data sources and services. These applications need automatic scale-out and scale-down capabilities. An application like Facebook is a good example. In such scenarios the organization may be a startup that wants to spend little capital on infrastructure while being able to handle increasing demand. Or suppose the application’s load will vary significantly, with occasional spikes in the midst of long periods of lower usage. An online ticketing site might display this pattern, for example, as might news video sites with occasional hot stories, sites that are used mostly at certain times of day, and others. Running this kind of application in a conventional data center requires always having enough machines on hand to handle the peaks, even though most of those systems go unused most of the time. If the application is instead built on the cloud, the organization running it can expand the number of instances it’s using only when needed, then shrink back to a smaller number. Since cloud charging is usage-based, this is likely to be cheaper than maintaining lots of mostly unused machines. E.g. A start-up creating a social networking application expecting to spend little capital on infrastructure.

clip_image001

2. Transactional, LOB app (24x7): ISVs are trying to continuously innovate and bring feature rich applications to their user base while continually building to differentiate from their competitors and offering solutions in a frictionless manner with lower costs to the end customers. With advent of agile development methods; ship cycles are shrinking and the traditional 3-year product cycles are being reduced to less than a year where the ISV offers new features and components 2-3 times a year. A SaaS model also lowers the burden of maintenance on ISVs as they now need to manage only 2 versions of their applications (current and previous) while end-customers do not need to invest in infrastructure and IT resources to run these applications. Typical architecture in this category will follow the traditional 3-tier model with front end-middle tier-back-end database; this kind of an application fits well with the growth pattern scenario; the application can be run as single tenant or multi-tenant where a multi-tenant application will have additional benefit of cost optimizations for running the application. An e.g. of such an application is Acumatica ERP where Acumatica is targeting the SMB space with their offering and are managing the SLAs with their customers or with the VAR channel which sells their offering on Windows Azure while in turn being the customer for WAP and handling provisioning; administration and scaling of the app for their user base. E.g. SugarCRM; Acumatica

clip_image002

3. Parallel Computing applications: Large-scale parallel execution of compute tasks. Normally these tasks execute for a short period of time utilizing more compute and storage resources. There are the parallel computing applications that need to perform multiple tasks in parallel so that a huge project can be executed in a short period of time. There are plenty of examples of this: rendering at a film special effects house, new drug development in a pharmaceutical company, financial modeling at a bank, and more. While it’s possible to maintain a large cluster of machines to meet this occasional need, it’s also expensive. Cloud computing can instead provide these resources as needed, offering something like an on-demand supercomputer. Again, paying for the one-time-only large capacity that cloud computing can provide is a cost-effective solution. E.g. A newspaper decides on digitization of reports for better Web consumption; InterGrid (GreenButton)

clip_image003

4. Analytical applications: Analytical processing executes various analytical and data mining algorithms over the same data again and again. There are lots of situations where Web-accessible software also needs to initiate work that runs in the background, independently from the request/response part of the application. For example, think of analytical applications whose main function is to run processor-intensive operations and data mining, often over the same data many times, or about a video sharing web application that needs to accept browser requests, perhaps from a large number of simultaneous users. Some of those requests will upload new videos, each of which must be processed and stored for later access. Making the user wait while this processing is done wouldn’t make sense. Instead, the part of the application that accepts browser requests should be able to initiate a background task that carries out this work. Based on the rate of traffic, the background processing requirements could be smooth or sporadic and on occasion, require access to a great deal of storage capacity and processor availability all at once. There is no need to pay for such huge capacity twenty-four hours a day, seven days a week, however, so cloud services are appealing. E.g. A financial company executing Monte Carlo simulations on financial data to assess risk periodically

clip_image004

5. Building block service: A building block service is an example of a cloud component/service which fills a gap within the platform. Consider a cloud provider which provides monitoring data for services running on its cloud and applications can leverage to automatically scale by increasing or decreasing the number of instances for a particular scale unit within the application. Now every ISV could use the management APIs within their application and build this functionality or an ISV could build this functionality as a component that could be leveraged by other ISVs to scale their solution. This would be a canonical example of a building block service which by itself has no use or function but once employed within another service can provide significant value. The ManageAxis solution by Cumulux is an example of such a service – it enables businesses to manage, monitor and deploy applications on the Microsoft Azure cloud infrastructure. Manage Axis enables monitoring of critical KPIs, automatically scale cloud applications and enables deployment automation of Windows Azure applications

6. Collaboration: service / data sharing between partners and customers: This application pattern can have numerous uses such as multi-enterprise integration, B2B & e-commerce applications; supply chain management, health and life sciences and domain specific services to name a few

a. E.g. SCM vendors shares inventory levels with partners; in PLM space CAD designer shares models with co-work

clip_image005

7. S+S pattern: Software + Services represent an industry shift towards a design approach that is neither exclusively software-centric nor browser-centric. By deeply and genuinely combining the best aspects of software with the best aspects of cloud-based services, we can deliver more compelling solutions for consumers, developers and businesses. Across the industry, Software + Services is growing as a model strategy – as evidenced by the emergence of hybrid scenarios on PCs, mobile phones and other devices that meld services and software together. The idea for the ISV is to augment their existing on-premise offering with cloud based services which provide value-added differentiation to end-customers. An example would be Bing Maps 3D – the application is installed and runs on the client but leverage Bing maps service for building the 3D models upon.

clip_image006

8. Microsoft “Dallas” data provider: The “Dallas” service allows ISVs to monetize information as a service. There are numerous examples where ISVs have datasets which they could potentially license to customers - ESRI (geographical shape files); WETA (digital renderers shared with production houses). In such scenarios the ISV publishing data to “Dallas” is building an important service for the cloud which not only builds mindshare for the Windows Azure Platform but also promotes consumers of this service to build their applications on the WAP.

9. BI / Reporting: Another application pattern involves providing BI as a service. With the advent of data, the ability to provide mining and intelligence on specific datasets is becoming increasingly important for companies to remain competitive and build optimization in their manufacturing, selling and marketing processes. Today Business Intelligence tools have significant costs putting them out of reach from smaller ISVs. With the ability to provide BI as a service even smaller ISVs could include reporting and analysis solutions in their applications and provide greater value to end customers. This can also be helpful to ISVs building custom databases which don’t allow for traditional BI.