What is Cloud Computing?
In simplest terms, cloud computing refers to computing “in-the-cloud” – where the processing of data can take place at any location in the cloud. Most people have both broad and narrow definitions for cloud computing – right from virtual servers on the internet to anything which is accessed for computing purposes outside the firewall.
That being said, cloud computing is a way to expand IT capacity or add capability on-the-fly. There are many cloud computing providers, providing a gamut of services such as applications, storage services, software, platforms etc. A cloud computing service architecture must take into account the requirements, along with the ability of the chosen solution, to integrate effectively with the existing on-premise architecture.
Service architecture for a cloud computing solution
Creating a service architecture for cloud computing involves:
· Understanding patterns or categories of cloud computing providers
· Deciding on patterns or categories of providers most suitable for your architecture
· Choosing a list of cloud computing platforms
· Analyzing and testing identified platforms
· Selecting platforms
· Deploying on platforms
We will now discuss the processes and steps that will serve as a guideline to create a service architecture for a cloud computing solution.
Patterns or categories of cloud computing providers
Services provided by cloud computing providers are classified as patterns, or categories. These categories let you choose a discrete or finite set of services for your enterprise architecture.
Patterns or categories can also be classified as
· Fine-grained services
· Coarse-grained services
The services that target specific solutions are fine-grained, and those that may be a complete platform on their own are coarse-grained. In other words, a coarse-grained solution would typically consist of many fine-grained services.
Table 1: Service categories of cloud computing providers
|
Service Granularity
|
Pattern/Category
|
Description
|
|
Coarse-grained services
|
Application-as-a-service
|
Any application delivered over the web, for example, SalesForce SFA, Gmail, GoogleDocs etc.
|
|
Infrastructure-as-a-service
|
More like a datacenter service; provides the ability to access computing resources remotely
|
|
Platform-as-a-service
|
A complete platform that includes interface , database and application development, besides storage and testing; Delivered to subscribers via a remote-hosted platform
|
|
Fine-grained services
|
Storage-as-a –service
|
This involves providing disk space on demand; the space exists on a remote server, but functions a logical storage for any application that requires it
|
|
Database-as-a-service
|
Though the database functions as if it were local, it is hosted at a remote site and may be shared with other users
|
|
Information-as-a-service
|
A well-defined interface, for example an API, lets the subscriber consume any information, for example, stock price information, or credit reporting
|
|
Process-as-a-service
|
A remote resource integrates services, data and applications to form processes, which are available on-demand
|
|
Security-as-a-service
|
Core security services are delivered remotely over the Internet
|
|
Testing-as-a-service
|
Test in-the-cloud or on-premise applications via remotely hosted testing services
|
|
Management/Governance-as-a-service
|
Manage one or more cloud services, for example, resource utilization, uptime management ; Enforce policies for services and data
|
The relationships between various categories are shown in Figure 1.
Figure 1: Relationship between categories
Sometimes, fine-grained services may integrate better with existing architectural components. Consequently, a cloud computing solution may also be chosen on the basis of architectural components.
Table 2: Architectural Components and Service Categories
|
Architectural Component
|
Cloud Computing Services
|
|
Processes
|
Application-as-a-service
|
|
Platform-as-a-service
|
|
Infrastructure-as-a-service
|
|
Process-as-a-service
|
|
Integration-as-a-service
|
|
Data
|
Application-as-a-service
|
|
Platform-as-a-service
|
|
Infrastructure-as-a-service
|
|
Storage-as-a-service
|
|
Information-as-a-service
|
|
Services
|
Application-as-a-service
|
|
Platform-as-a-service
|
|
Infrastructure-as-a-service
|
|
Information-as-a-service
|
Thus, you may choose a coarse-grained provider which can provide many fine-grained services or many fine-grained providers. The architecture may call for services from different cloud computing providers, and the final architecture may be an integration of various services provided by the same or different providers.
For example, you may use Process service via Amazon EC2, Infrastructure services via 3Tera Cloudware and Database service via Amazon Simple DB.
You also need to think about other core components, for example, Security, Testing, and Management/Governance, which could be deployed on-premises or in-the-cloud, depending on the requirement.
How do you move to the cloud?
To move to the cloud, consider following these steps:
· List possible cloud computing platforms
· Analyze and test platforms
· Select platforms
· Deploy processes, services and data to selected platforms
List possible cloud computing platforms
First, determine the following:
· What categories or patterns does your architecture require?
· In the required categories, which cloud computing providers should you choose?
Also, while categories depend on the requirements and final architecture, there are certain basic layers required by all architectures. These include:
|
Architectural Layer
|
Usage
|
Where it can exist
|
Selection factors
|
|
Storage
|
Storage, sharing and management of file systems
|
· Storage provider
· Infrastructure provider
|
· Performance: With respect to movement of files to and from the chosen service
· Capacity: Scaling of storage needs for the architecture
|
|
Database
|
Storage and retrieval of data
|
· Platform provider
· Database provider
· Infrastructure provider
|
· Functions and features support
· Performance: May be impacted to due to I/O overheads and data transfer delays
· The database being used: While Infrastructure-as-a-service providers allow usage of databases such as MySQL or Oracle, database-as-a-service providers may use a proprietary database.
|
|
Process
|
Deployment of processes
|
· Process provider
· Application provider
· Platform provider
· Infrastructure provider
|
· Reliable integration of processes, services and data (within the same provider, across providers or with on-premise components)
|
|
Services
|
For creation and hosting of services, or using existing services
|
Creation and hosting services:
· Platform provider
· Process provider
· Infrastructure provider
Using existing services:
· Application provider
· Information provider
|
· Performance considerations: Based on availability of computing resources on provider and number of services that you are using
|
|
Security
|
Secure thearchitecture
|
Security should be a characteristic of the architecture at all levels, and across components
|
· Identity management capability: Becomes crucial when services and components are shared between various providers and consumers
|
|
Governance
|
Implementation and management of policies
|
Use either a cloud computing provider, or consider using an on-premise system
|
· Performance: Enforcement of policies may lead to delays in processing
· Monitoring: Ability to monitor both runtime services and remote services
|
|
Management
|
Manage both on-premise systems and in-the-cloud deployments; Closely linked to governance
|
A cloud computing provider that can manage both on-premise and in-the-cloud deployments, and provides system-wise status or an on-premise management system
|
· Cloud providers: Must provide interface to let management systems talk to them
· Status update features: System-wise status updates at working/non-working levels, and at granular levels across on-premise and in-the-cloud deployments
|
As an architect, you must have a clear understanding of the various vendors, and the functionality offered by various products, to be able to choose a possible list of platforms for the architecture.
Analyze and test platforms
Once you have made a list of possible platforms, the next logical step is to test and validate the platforms to check which would be the most suitable for your architecture.
· Test generic functions of the cloud computing platform
· Validate to make sure that the platform supports architectural requirements
· Model the system for various loads
· Test performance to make sure that architecture will perform under stress, and identify potential bottlenecks: database, hardware or network issues
Select platforms
Having tested various platforms, you will now be in a position to select the most appropriate platforms for your architecture.
Selection guidelines include:
· Service Level Agreements (SLAs) for establishing expected levels of service
· Recovery from failure and Downtime limits
· Understanding Provider Policies
· Ease of switching between providers - If provider goes out of business, or a merger/acquisition requires removal a platform
Deploy to platforms
Last, but certainly not the least, create new services, processes, databases and validate that they are all working fine together
· Consider an evolutionary approach, rather than a revolutionary, “big-bang” approach
· Prioritize the architectural components that you need to create in-the-cloud, and test them to make sure that they work well when you integrate them with other on-premise or in-the-cloud components
Does it end here?
Not really. The cloud computing space is dynamic and constantly evolving, so creating service architecture does not mean just planning and implementation – besides regular maintenance activities, it will involve keeping track of new providers and products, changes in existing providers, and making sure that the systems work better for your business.