91d437f0fb56cfb5b64de81b60bd6738

I discussed the subject with one of colleagues who is a Cloud Computing architect. I’m logging what my comment here

=-=-

To continue our previous talk is a huge discussion. I’d recommend you could start to get involved in http://twitter.com and follow

http://twitter.com/mashable
http://twitter.com/j3ffyang -> me
http://twitter.com/OpenIBM -> I own this too as of being admin for IBM Open Source Global community

When you hit any of above, you can see the bytes come from http://aws.amazon.com actually, which is an IaaS with no doubt. Twitter is a kind of social collaboration network -> an application running over Amazon Web Services (AWS). Twitter doesn’t own any hardware resources. Whenever Twitter needs computing capability, it goes to AWS and AWS fulfills its request… on demand. Even though Twitter sometimes out of service due to its overload.

@ IaaS, AWS not only gives power of hardware (CPU, memory, disk and network…), but also provides plugin / API to connect Twitter with Hadoop… and Simple Queue Service (SQS), and Simple Database (SDB).

You shouldn’t be surprised @ Twitter’s power to gather thousand of thousand developers around it, if keeping our eyes open. (Some reasons of the motivation of social collaboration in term of Web2.0). See these:

http://tweetwheel.com
http://ftags.com
http://tweetvalue.com/
http://www.tweetizen.com/
http://twittersnooze.com/
http://mrtweet.net/home/j3ffyang
http://tweettrail.com/search/hadoop
…
…

This list is almost endless. They’re all independent of twitter.com. The above are all SaaS, plugable into Twitter.com where provides API -> http://apiwiki.twitter.com/ and http://twitter.com/downloads – @ PaaS

This is an ecosystem.

Source: http://aws.amazon.com/solutions/case-studies/medcommons/

One of MedCommon’s offerings, HealthURL is a personal account hosted on Amazon Web Services. MedCommons HealthURL provides a web-based storage repository for consumers to store and share access to their health records. These temporary or long-term accounts live on Amazon S3 where they meet HIPAA requirements of security and redundancy.

“We choose AWS because of their reputation and the scalability of their solution,” states Adrian Gropper MD, Co-founder and Chief Science Officer. “We use Amazon S3, EC2, Elastic IP to store and host individual HealthURL accounts. Compared to traditional hosting providers, Amazon EC2 was easy to set up and pretty inexpensive. The fact that there’s no bandwidth costs between our gateways and long term storage servers will be a huge cost savings.”

With HealthURL, consumers can open an account and upload PDF files, DICOM imaging, CCR information, and other relevant medical data. Then, using credentials, patients can share access with family members, physicians, specialty providers, large hospital networks, or even employers. The patient maintains control of their identity and privacy by granting or revoking access to others as needed.

HealthURL accounts are a $2/month subscription plus a hosting fee. To determine the hosting fee and charge the subscription cost, MedCommons utilized Amazon DevPay to charge and meter customer usage. “DevPay tracks the actual storage and communications expenses for very large diagnostic imaging objects as well as service fees to be paid by the patient/consumer. This billing system saves a great deal of work and enables our transactional business model to compete with the ad-supported model of Google and Microsoft.”

MedCommons also utilizes Amazon FPS to manage direct and third party billing transactions between consumers and MedCommons or patients and doctors. Both Amazon FPS and DevPay allow MedCommons’ customers to simply pay using the existing payment information stored in their Amazon.com account.

With a scalable solution in place, MedCommons also had to consider HIPAA compliance of their application. “Our app was designed to be hosted in the cloud and patient-centric from the ground up. In order to be HIPAA compliant, we had to design our application to allow careful identity management, detailed activity logs, a secure console system that facilitates audit of users and accounts, a clear access consent mechanism, and a locked down app deployment procedure that provides a minimum attack surface—encryption and SSL certificates.”

“We have saved many man-years of work by going with AWS for our in-the-cloud, on-demand healthcare information service. The capability of usage-based pricing at the patient level adds commerce capabilities not available anywhere else. The confidence in the Amazon brand by consumers everywhere makes it our best choice for in-cloud storage and computing,” says MedCommons’ CEO Bill Donner.

Source: http://news.ycombinator.com/item?id=422225

With a price tag of $0.150/GB/month, storing 1TB of data costs around $150/month on Amazon S3. But this is a recurring amount. So, for the same amount of data it would cost $1800/year and $3600/2-years. And this doesn’t even include the data transfer costs.

Consider the alternative, with colocation the hardware cost of storing 1TB of data on two machines (for redundancy) would be around $1500/year. But this is fixed. And increasing the storage capacity on each machine can be done at the price of $0.1/GB. Which means that a RAID-1+redundant copies of data on multiple servers for 4TB of data could be achieved at $3000/year and $6000/2-years in a colocation facility. Whereas on S3 the same would cost $7200/year and $14,400/2-years.

Also, adding bandwidth+power+h/w replacement costs at a colocation facility would still keep the costs significantly lower than Amazon S3.

Given this math, what is the rationale behind going with Amazon S3? The Smugmug case study of 600TB of data stored on S3 seems misleading.

I do see several services that offer unlimited storage which is actually hosted on S3. For example, Smugmug, Carbonite etc. all offer unlimited storage for a fixed annual fee. Wouldn’t this send the costs out of the roof on Amazon S3?

If your startup is using Amazon S3 for its storage needs, for the benefit of the startup community, can you please elaborate your rationale for choosing this service?

Source: http://www.nytimes.com/…is-amazon-ready-for-the-enterprise-26615.html

Author: ALISTAIR CROLL

Copyright: GigaOm
With a flurry of announcements in recent weeks, Amazon has extended its cloud computing lead. The beta label’s gone. It can run Windows applications. By investing in firms like Elastra, it’s tackling enterprise deployment. And there’s a 99.95 percent uptime guarantee.

Much of this is a pre-emptive strike at Microsoft’s upcoming cloud offering. Microsoft has a huge advantage: It owns the stack from OS and virtual machine through to application. Amazon wants to compete on reliability and performance, rather than software suites and licensing. But there are still some things missing before enterprises will really embrace it.

Back in May, most of the people we asked were more likely to trust Amazon than Microsoft with their enterprise applications. But while enterprise customers are using Amazon already, in many cases that use is limited to a department or a short-term project. If Amazon wants to capture entire IT departments, it needs to prove it’s as good or better than in-house infrastructure. And that means delivering responsive, highly available applications, not just an SLA.

To accomplish this, Amazon needs to tackle performance and availability at an architectural level. When companies build their own applications, they rely on building blocks like load-balancing, WAN acceleration, managed DNS and redundant data centers. Fortunately, this is where much of Amazon’s roadmap leads.

• Network performance: Amazon’s CDN will get static content closer to users. With availability zones, Amazon can also get computation near the edge. All of this reduces the time it takes to deliver bits to users. But it can be faster still: Modern enterprises squeeze every millisecond out of the network. Amazon should also add route optimization, HTTP and TCP optimization to really address network delay.

Amazon’s plans for integrated scaling, monitoring, and load balancing in EC2

• Processing performance: Internet architects improve server performance with load-balancing. First send the request to the fastest data center, then send it to the fastest machine in that data center. If there aren’t any fast machines, the newly announced dynamic scaling will make new ones. All that’s missing (though hinted at) is the ability to measure user experience so EC2 knows when to add new servers. Amazon needs a complete load balancing/monitoring/scaling strategy — with proper controls so IT staff can manage it — to make elastic computing a reality. While they’re at it, a performance SLA would be great, too.
• Network availability: Those same load balancing technologies improve uptime, using DNS or BGP to bypass unreachable data centers. Amazon needs to launch a SimpleDNS service, tied to availability zones and performance, that gives operators more control. It’s going to have to deal with DNS when it launches its CDN anyway. This looks less like managed DNS (Amazon uses UltraDNS already) and more like products from F5, Citrix or others. Amazon also needs to open up about its carriers and peering arrangements for enterprises to feel comfortable.
• Processing availability: Big Internet sites don’t achieve high uptime with machines that always work. Instead, they monitor for failure and then have the load balancers take out bad servers. That way, overall availability can be high, even when individual components are broken. Amazon should add load testing and profiling capabilities – particularly since EC2 doesn’t give users deep visibility into the platform — to ensure that applications work worldwide under stress.

As Amazon CTO Werner Vogels pointed out, enterprises like cloud computing for its economics, its elastic capacity and its ability to deliver high reliability. With this roadmap, Amazon goes after Microsoft’s weak spots. But it’s not there yet.