With cloud computing, you don’t do any of that. If you’re a
user of the cloud, you buy access to the application you want and then connect
to it from anywhere. Installing the software, maintaining the hardware and
software where the application runs, making sure that the data is kept safe and
secure—none of that is your concern. In the cloud, you buy software as a
service. If you need more storage than a typical user, you buy extra storage
from the service provider. If that means buying and installing a new disk
drive, that’s up to the provider. You just buy storage-as-a-service from them:
how they provide it is their problem. You tell them what you need—in both the
physical sense (“I need 1TB of storage.”) and in less tangible
quality-of-service senses (“I need to guarantee that my storage is
transactional, so that after I commit a change, data will never be lost.”). You
tell them your requirements, and some cloud provider will sell you a service
that meets those requirements.
What this means is that when you’re developing for the
cloud, instead of buying a computer and running software on it, you break
things down to basic building blocks, buy those pieces from service providers,
and put them together however you want to build a system.
The building blocks are the resources you need to run a
program or to perform a task. Resources include things like processing time,
network bandwidth, disk storage, and memory. As a user of the cloud, you don’t
need to be concerned about where these resources are located. You know what you
need, and you buy that from whoever can provide it to you most conveniently.
For developers, cloud computing introduces an even bigger
change. When you develop for the cloud, you’re not building a piece of software
to sell to your customers—you’re building a service for your customers to use.
Understanding that difference is crucial: you need to design your application
around the idea that it’s a service you’re going to provide to users, not a
standalone application that they’re going to install on their computers. Your
customers are going to choose a service based on the tasks they want to
accomplish, so your application needs to be designed with the task in mind, and
you must provide it in the most flexible way possible.
For example, if you want to build a to-do list application
for a desktop computer, it’s a fairly straightforward process. There are lots
of variations in how you can arrange the UI, but the basic idea of what you’re
building is obvious. You would build one UI—after all, why would you need more
than one? And you’d build it mainly for a single user. If you are developing
this to-do list application for the cloud, though, you’d want multiple UIs: at
the very least, you’d want one UI for people accessing your service using their
desktop computer and one for people using a mobile browser on a cell phone.
You’ d probably want to provide an open interface that other people could use
for building clients for other devices. And you’d need to design it for
multiple users; if you put an application in the cloud, there’s only one
program, but it can be used by lots of people. So you need to design it around
the assumption that even if users never work together using your application,
it’s still a multi-user system.
For developers, the most exciting aspect of cloud computing
is its scalability. When you’re developing in the cloud, you can write a simple
program to be used by one or two people—and then, without ever changing a line
of code, that program can scale up to support millions of users. The program is
scale-neutral: you write it so it will work equally well for one dozen users or
one million users. As you get more users, all you need to do is buy more
resources—and your program will just work. You can start with a simple program
running on one server somewhere in the cloud and scale up by adding resources until
you’ve got millions of users.
Source of Information : Pragmatic - Code in the Cloud Programming Google App Engine 2011
Source of Information : Pragmatic - Code in the Cloud Programming Google App Engine 2011
1 comment:
Post a Comment