Flickr
This is a test post from 
, a fancy photo sharing thing.
Purest form of Cloud Computing
"Real cloud computing is when you're working with a provider where virtually every resource they offer is unlimited, and you're able to scale up to infinity on each of those resources. You can write applications without worrying about running out of anything. And usually you're paying for only what you use (or in the case of Google, you get a lot for free as well)."
I remember this reading somewhere.. out in the clouds, you have unlimited and enormous power for you in the server which your code can leverage without any struggle. Amazon has the purest form of cloud computing server. As the name suggest EC2 (Elastic cloud computing), the server has the power which will be provided to you. If your app needs more power to spawn the threads or do some super calculations, the server uses its elasticity to automatically increase the power which it initially has and fuel your app. But pay for what you use. ...
This site shows the evolution of the gmail chat window.
They have come up with the chat window in the gmail undergoing a tough reviews and feedbacks.
Amazon's Simple DB Beta
Amazon has introduced a real cool thing which works in conjunction with S3 and EC2 is Simple DB.
Imagine a startup company investing hell lotta money in buying a Data base, employing a person to administer it, performance tune it, store the data and properly index it.
So, whats their exact business? are you going off-track on their business? .. unfortunately yes.
So, this is the win-win situation for both amazon and the guys out there have a start up with them.
They will give the structured data to amazon, and the responsibility dies out there.
Its amazon's responsibility to maintain and manage the database. The company can retrieve the data on the user click basis and pay for what they had used. is nt it cool??
the storage of data will be schema less. The amazon is going to index everything and make it accessible safely.
More here
Amazon S3
Amazon S3 is storage for the Internet. It is designed to make web-scale computing easier for developers. Amazon S3 provides a simple web services interface that can be used to store and retrieve any amount of data, at any time, from anywhere on the web. It gives any developer access to the same highly scalable, reliable, fast, inexpensive data storage infrastructure that Amazon uses to run its own global network of web sites. The service aims to maximize benefits of scale and to pass those benefits on to developers. Amazon S3 is intentionally built with a minimal feature set. Amazon S3 is based on the idea that quality Internet-based storage should be taken for granted. It helps free developers from worrying about how they will store their data, whether it will be safe and secure, or whether they will have enough storage available. It frees them from the upfront costs of setting up their own storage solution as well as the ongoing costs of maintaining and scaling their storage servers. The functionality of Amazon S3 is simple and robust: Store any amount of data inexpensively and securely, while ensuring that the data will always be available when you need it. Amazon S3 enables developers to focus on innovating with data, rather than figuring out how to store it. Amazon S3 was built to fulfill the following design requirements: A forcing-function for the design was that a single Amazon S3 distributed system must support the needs of both internal Amazon applications and external developers of any application. This means that it must be fast and reliable enough to run Amazon.com's websites, while flexible enough that any developer can use it for any data storage need. The following principles of distributed system design were used to meet Amazon S3 requirements:
Article about System Scalability
The scalability is often misunderstood by the developer community. May be this article will explain it better.
Scalability is frequently used as a magic incantation to indicate that something is badly designed or broken. Often you hear in a discussion “but that doesn’t scale” as the magical word to end an argument. This is often an indication that developers are running into situations where the architecture of their system limits their ability to grow their service. If scalability is used in a positive sense it is in general to indicate a desired property as in “our platform needs good scalability”.
What is it that we really mean by scalability? A service is said to be scalable if when we increase the resources in a system, it results in increased performance in a manner proportional to resources added. Increasing performance in general means serving more units of work, but it can also be to handle larger units of work, such as when datasets grow.
In distributed systems there are other reasons for adding resources to a system; for example to improve the reliability of the offered service. Introducing redundancy is an important first line of defense against failures. An always-on service is said to be scalable if adding resources to facilitate redundancy does not result in a loss of performance.
Why is scalability so hard? Because scalability cannot be an after-thought. It requires applications and platforms to be designed with scaling in mind, such that adding resources actually results in improving the performance or that if redundancy is introduced the system performance is not adversely affected. Many algorithms that perform reasonably well under low load and small datasets can explode in cost if either requests rates increase, the dataset grows or the number of nodes in the distributed system increases.
A second problem area is that growing a system through scale-out generally results in a system that has to come to terms with heterogeneity. Resources in the system increase in diversity as next generations of hardware come on line, as bigger or more powerful resources become more cost-effective or when some resources are placed further apart. Heterogeneity means that some nodes will be able to process faster or store more data than other nodes in a system and algorithms that rely on uniformity either break down under these conditions or underutilize the newer resources.
Is achieving good scalability possible? Absolutely, but only if we architect and engineer our systems to take scalability into account. For the systems we build we must carefully inspect along which axis we expect the system to grow, where redundancy is required, and how one should handle heterogeneity in this system, and make sure that architects are aware of which tools they can use for under which conditions, and what the common pitfalls are.
Subscribe to:
Posts (Atom)