Шукати в цьому блозі

середа, 27 квітня 2011 р.

Main reasons for Choosing Scale-Out

1. Continuous Availability/Redundancy: You should assume that failure is inevitable, and therefore having one big system is going to lead to a single point of failure. In addition, the recovery process is going to be fairly long which could lead to a extended down-time.

2. Cost/Performance Flexibility: As hardware costs and capacity tend to vary quickly over time, you want to have the flexibility to choose the optimal configuration setup at any given time or opportunity to optimize cost/performance. If your system is designed for scale-up only, then you are pretty much locked into a certain minimum price driven by the hardware that you are using. This could be even more relevant if you are an ISV or SaaS provider, where the cost margin of your application is critical to your business. In a competitive situation, the lack of flexibility could actually kill your business.

3. Continuous Upgrades: Building an application as one big unit is going to make it harder or even impossible to add or change pieces of code individually, without bringing the entire system down. In these cases it is probably better to decouple your application into concrete sets of services that can be maintained independently.

4. Geographical Distribution: There are cases where an application needs to be spread across data centers or geographical location to handle disaster recovery scenarios or to reduce geographical latency. In these cases you are forced to distribute your application and the option of putting it in a single box doesn’t exist.

вівторок, 26 квітня 2011 р.

понеділок, 25 квітня 2011 р.

Delivery Models

Found summary of the cloud service classification like Delivery models and Deployment models see previous post

Cloud services delivery can be broadly classified into three models. This is commonly called as SPI model.

1. Software as a Service (SaaS): Software applications delivered from the cloud using multi-tenancy and accessible by various devices using a web browser. The vendor controls the entire stack from hardware to applications with users having the control over their data.

2. Platform as a Service (PaaS): Application platform that completely abstracts all the complexities of the underlying infrastructure and delivered as a service for the users to deploy applications that can be accessed over the network. There are striations inside the PaaS itself with IDE as a service on one end to pure middleware as a service on the other end. For the sake of simplicity, we stick to the SPI model and consider various types of platform services within the PaaS categorization itself. The provider controls everything from hardware till the platform layer and users have complete control over their applications.

3. Infrastructure as a Service (IaaS):
Raw compute power and storage offered as a service with a metered billing where users can deploy and run different software from operating systems to platforms to applications. Compared to PaaS, the abstraction is taken to a lower level in the infrastructure and users get more control over the configuration of platform itself. The provider manages the hardware and other infrastructure needed to run the virtual machines and the users get to control everything from OS to applications.

Deployment Models

One of the most important model in the cloud services is – delivery models

1. Public Clouds: Public Clouds, also called as the real cloud by some purists, is the availability of cloud infrastructure to general public and accessible through the Internet. The infrastructure is owned by 3rd party service provider and is present outside the firewall of organizations using it. Multi-tenancy is the key differentiating factor here, which results in what we now call as Cloud Economics.

2. Private Clouds: Private Clouds are cloud infrastructure operated solely for an organization either by the IT of the organization or 3rd party. The infrastructure can be present inside of the organization’s firewall or operated in a 3rd party datacenter. Cloud economics will not be in play here but organizations can take advantage of other cloud characteristics like better utilization and elasticity.

3. Community Clouds: Community Clouds are cloud infrastructure shared by different organizations that supports specific community or verticals with shared needs. One or more of the participating organizations or a 3rd party may manage the infrastructure. The infrastructure can be present either inside the firewall or with 3rd party datacenters.

4. Hybrid Clouds: Hybrid Clouds are cloud infrastructure made up of two or more clouds (public, private, community) with one of them leveraged from a public cloud provider. These are independent cloud deployments that are bound together by standardized or proprietary technology that enables data and application portability. Usually, enterprises with a private cloud infrastructure tap into public clouds to push certain non-critical workloads in order to meet their sudden resource requirements

10 main requirements for SaaS/Cloud applications

Find interesting post regarding 10 main requirements for SaaS/Cloud applications. Below is short notes:

1. True Multi-tenancy. Multi-tenancy is the only proven SaaS delivery architecture that eliminates many of the problems created by the traditional software licensing and upgrade model—period.
2. Regularly Delivered, Vendor-Managed Updates. A cloud application is a single version of software that is regularly updated, often several times a year, for all customers, at no additional charge.
3. Seamless Integration On Demand. Cloud applications should be built from the ground up to lower the cost, time, and risk of integrating them with existing on-premise and on-demand applications.
4. Business-Driven Configurability. Cloud apps should be configurable, so your IT organization is freed from costly customizations (the most over-rated virtue of traditional software, in my opinion), and businesspeople can configure processes that meet the specific needs of the organization. That said, you should be able to choose from among multiple types of configurations.
5. World-Class Data Center and Security. A cloud application provider should be able to offer world-class security and data privacy better than its customers can do on their own, and at no additional cost. That includes physical, network, application, and data-level security, as well as full back-up and disaster recovery. The provider should be compliant with security-oriented laws and auditing programs, including Safe Harbor, ISO 27001, and SAS70 Type II.
6. A High-Performance, Sustainable IT Infrastructure. The provider should maintain a high-performance IT infrastructure, which includes the data centers and databases, operating systems, networks, and storage systems used to run cloud applications and manage customer data.
7. Predictable Total Cost of Ownership Model. There should be no surprise costs with cloud applications. Implementation costs should be predictable, subscription-based pricing should have no hidden fees, and no investments should be required for hardware and software license fees.
8. Faster Deployment. Since cloud applications don’t require investments and installation of hardware and software, you should be able to get them running and productive in a fraction of the time compared with on-premise software.
9. Control. Cloud applications should allow you complete control of your organization’s data, even though it is located off premise. Nothing should hinder your ability to import, export, purge, and archive data to and from the application without having to first contact the SaaS vendor.
10. Liberation from Non-Strategic IT Issues. Cloud applications should free teams from time and energy spent on non-strategic, back-office IT operations and software coding. Today and into the future, the most highly valued CIOs—the ones that become heroes to the business—are those who are closely aligned with strategic business initiatives and drive the IT projects that support those initiatives.

Original post is here